LOCO Unreadable BMP files

[noghiri]

Yesterday (for me), I saw a Le717 and a few others discussing the strange .BMP files in Lego LOCO. I asked for a file to try to open, and it was sent. I spent some time poking it, and came up with some interesting info.

Here's the header stack of a normal .bmp, when viewed with a hex editor:

424D365707000000000036040000280000002003000058020000010008000000000000000000C40E0000C40E0000000100

Here's the headers from a mysterious file, found in /trains/carriage1/car.bmp:

36AC0700FD01000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

This isn't all I've found. I took a look at duck.bmp, which is one of the openable files. It shows several views of the duck sprite. It has the normal headers (which is why I could open it) Each .BMP, readable or otherwise, has an accompanying .DAT file. The trains follow one format, while the animals follow another. Here's duck.dat's filtered hex for reference (the animal .dats are the most complex, and show how the file works)

sex fwalk_speed 1 9PickUpSoundID 22004-9button offset 0 0 0Name Duckhotspot -3 1total_number_of_frames 12number_of_frame_sets 8cursor_frame_set 0 0walk-left4 0 4 00 0 0	 0 0 1walk-down9 11 4 00 1 0	 0 0 0walk-right0 4 4 00 2 0	 0 0 0walk-up 5 8 4 00 3 0	 0 0 0normal 0 0 9 0 0 4 0	 0 0 0angry9 11 3 00 5 0	 0 0 0sad 10 10 8 6	 0 6 0	 0 0 0extactic9 11 5 00 7 0	 0 0 0-9// frameset name, start frame, end frame, animation delay, split frames? 1 = TRUE, 0 = FALSE

QUESTIONS I HAVE:

What happens when we add a header to the unopenable .BMPs?

Can we substitute a readable .BMP for an unreadable .BMP, and still have it work?

ON A SEMI-RELATED NOTE:

http://en.wikipedia....telligent_Games

I tracked down the devs. Matthew Stibbe, the founder, was the developer on LOCO. Maybe something that can open their in-house files can help? Maybe a tool for opening the Stunt Rally textures can help here, or a tool for Dune 2000 (same dev, same year as LOCO)?

UPDATE ON SEMI-RELATED NOTE:

I found Matthew Stibbe. He's alive. He admits to working on Loco as head designer. http://www.stibbe.net/contact/

HERE IS MY COPY OF THE FILES:

https://www.dropbox....bles_527809.zip

[Phoenyx]

As I was saying in the chat, the formats are similar to files used with a fighting game engine known as MUGEN. The tools used for that game may be able to open the files. The .bmp files likely contain multiple images that are referenced in the .dat files.

[Lair]

So, it might be like a sprite set/sheet of sorts for the things with animations?

[noghiri]

So, it might be like a sprite set/sheet of sorts for the things with animations?

Maybe. Or, it could be a relabeled image of a different format.

[Sonic322]

Are there any readable image formats anywhere else in the game? In any of the compressed files or anything?

[noghiri]

Are there any readable image formats anywhere else in the game? In any of the compressed files or anything?

There are a few openable bmp files, specifically duck.bmp and duck2.bmp

[Lair]

I thought some of the buildings had sprites with pink backgrounds that we could read.

[noghiri]

I thought some of the buildings had sprites with pink backgrounds that we could read.

I don't have those. I just have animals and trains.

My cousin is sending me his old copy of Loco, so I'll have it within the week.

[lu9]

I found a Dead End road that I can't find in the game, may that be some beta element?

ON: I can't wait to see when we all discover how to open the Unreadable BMPs :D

[lol username]

I found a Dead End road that I can't find in the game, may that be some beta element?

ON: I can't wait to see when we all discover how to open the Unreadable BMPs

I know there is a dead end road tile in-game, you sure it's unused? Or is it an unused variation or something?

[McJobless]

Can you post it so we can see?

[noghiri]

Can you post it so we can see?

Post which?

[McJobless]

That was directed at lu9 who says he's got a deleted image.

[Tauka Usanake]

I found a Dead End road that I can't find in the game, may that be some beta element?

ON: I can't wait to see when we all discover how to open the Unreadable BMPs

Late, but I bet I know which one he is talking about. There is a dead end that is literally a "dead" end. It's one that has a skull and crossbones on it and you get it on Halloween. You don't notice it because it doesn't really matter. If not though, then I don't know what he means.

[le717]

I found a Dead End road that I can't find in the game, may that be some beta element?

ON: I can't wait to see when we all discover how to open the Unreadable BMPs

Late, but I bet I know which one he is talking about. There is a dead end that is literally a "dead" end. It's one that has a skull and crossbones on it and you get it on Halloween. You don't notice it because it doesn't really matter. If not though, then I don't know what he means.

Would you perhaps to know the filename of this sprite? Someone could look it up and see if it is the one lu9 is talking about.

[lu9]

Actually is ingame, when I went on halloween mode it appeared... nothing special...

[shinyquagsire23]

Sorry to bring up a dead thread like this but I recently had the inspiration to recreate LEGO LOCO using the original game files (as opposed to manually ripping textures and stuff). So I did some research, got the RFD and RFH sorted out and now I'm stuck on getting these pesky BMPs to open. Luckily I happen to have some experience in reverse engineering (specifically Pokemon games for the GBA) so opening up a hex editor to take a peek at the files is nothing new.

 

So first off, these files are definitely compressed in some sort of form. If you open the files as a raw image using GIMP you'll see something similar to this:

 

Whereas if it were just a bitmap stripped of it's header it would look a bit like this guy from the Yoda Stories data file that I happened to open which comes from around the same time (1990's):

 

I'll keep looking but it seems that we're going to have to keep looking. It does seem to have some sort of a header, I believe it's about 8 bytes long since everything else in the file is shifted by 8 bytes. Some notable offsets after looking through some files:

• 0x0 - Some sort of header
• 0x408 - Some sort of data, perhaps a palette? The openable files are indexed bitmaps with a 256 color palette, making the images 8bpp images as opposed to something like 4bpp.
• 0x808 - Compressed (maybe) data. Still need to find compression format. I'm placing my bets on Huffman, LZ77, or ZIP. If we're not so lucky it could be a home-made compression format which might take time to decipher.

Also, I found an interesting file in the buildings folder. It's in reguards to the telephone: Instead of the usual BMP and DAT files, this one has a BMP, DAT, and a BUT file. The BUT file is in the exact same format as the BMP, so this might aid in finding the original format which we already have found to not be BMP. Also, if anyone has anything interesting to contribute I would appreciate it. Hopefully I can figure out this format soon so I can make a data extractor for my game so that I can use the original resources without having to resort to blatantly stealing IG's work. But, if needs be, I will end up ripping the sprites manually and maybe throw in a check for a valid installation of LOCO.

 

EDIT: Also while going through in IDA I found a debug string that says "Error while loading db bitmap" and one that says "LOCOBITMAP Convert - failed to create surface". Perhaps another clue as to what the file format does? It does appear to be converting something so I might be able to identify the compression.

 

EDIT again: Another small breakthrough, but it seems that the developers did in fact implement a function that would open files uncompressed, which will help debugging immesely. Since LOCO was (for the time) quite large I'd imagine that they would have it default to the uncompressed files, and if they couldn't be found it would try and open the compressed files.

It's cut off but the full file path is C:Program FilesLEGO MediaConstructiveLEGO LOCOART-restoyboxnewtoyhandle.bmp, which is definately not inside it's compressed file. This code might not fully work though so I'll test it by removing the archives and seeing how it goes.

 

One more EDIT: So apparently it does need the data files due to the fact that it will try and read from them on startup. I'll have to see which it tries to read from first and get the results back to you guys. On another topic, I found one file that has both a weird formatted file and a normal bitmap, so we might be able to use that to figure out how it's compressed. The two files are roads/tjunct-swint.bmp and (here's that extention again...) roads/tjunct-swint.but. I'm pretty sure the .but is the original file extension before they went in and renamed them to all be BMP's, so if we can figure out this file then it blows the doors wide open for modding. Maybe. That and it allows me to view all the images which is why I'm here.

[McJobless]

-an inspiring tale that made many cry, fed the ducks, saved the whales and brought Abe Lincoln back alive to say "This play is quite enjoyable, I hope I don't get sh..."-

Holllllly s***. A guy who likes Sam & Max AND knows his way around a Hex Editor. I like this very much. Keep it going, mate, you've done really well so far.

[shinyquagsire23]

OK, so I've been playing with the bitmaps (AKA flooding them with random bytes and values) and I've come to the following conclusion: These bitmaps are really really really weird.

 

I was pretty much wrong about everything in my initial analysis. However, there are some things I'm glad to be wrong about. First off, I've discovered why some of these are formatted as normal bitmaps and why some of them aren't: animations. Every one of those files has an animation. Just take a look in the buildings folder, only the ones with multiple frames will have an unreadable file.

 

Second, I found some interesting animations for the telephone. It turns out that there is also a blue and red version of it that was never used, as well as some unused easter eggs. If I can I'll try and get a pic up for you guys to see.

 

Third, these graphics are indeed bitmaps, but they are very very very weird ones at that. Instead of being like a normal bitmap they start their image from the end of the file, so the top right pixel corresponds to the last byte in the bitmap file. And to make things even weirder they put each row of animation one after another, which is why they looked so darn weird in GIMP. So just as an example, instead of having it so that you have two separate images like most games do animation, they have the two images weaved together with the corresponding rows right next to each other. Weird. But, I am very happy because this means that these are both readable and editable. It's just a matter of figuring out the rest of the file. Also, I've discovered that the preview (with the magnifying glass) image is separate from the one displayed.

 

And lastly, I found the purpose of the .but files. They are used in the toolbox as previews, because if you look carefully they are not just scaled versions (well, most aren't. The telephone is.), but in fact separate images.

 

I'll keep looking into this. I'm actually very excited now that I know that it's possible to edit these easily (ie without cracking a compression algorithm). All that's left is to find the palette inside the file as well as the other information (the number of frames and the size of the image just as an example). Once we have that we can start converting these to editable bitmaps and then just use those for the purpose of modding.

 

And since it seems like you guys didn't know this before (based on the top post here), those .dat's are just text files. They only look weird if you open them in either a

• Notepad
• or a Hex Editor

If you open them in wordpad you'll find them to be perfectly editable. I'm a bit curious to see if LOCO dynamically scans for those .dats and if they'll show up in the toolbox if you copied a building or something.

 

EDIT: Number of frames is specified in the .dat file. Also, it doesn't dynamically scan, which means there's a list of files for it to open out of the buildings folder. If I can get another building to be added this could mean a lot in terms of modding. Also, it seems that the .WAVs have the same exact header as the .BMPs, which is interesting. I'm guessing it's just raw PCM data.

[lol username]

Please keep posting. You're awesome.

[dead_name]

Third, these graphics are indeed bitmaps, but they are very very very weird ones at that. Instead of being like a normal bitmap they start their image from the end of the file, so the top right pixel corresponds to the last byte in the bitmap file.

Actually, "real" bitmaps use this raster order too.

Rather than use "standard" raster order (that being left-to-right, top-to-bottom, like words on a page), they use vertically inverted raster order. It still goes left-to-right, but the y component is flipped.

 

[shinyquagsire23]

 

Please keep posting. You're awesome.

 

Thanks, This is my first time reversing an x86 executable so this is kinda exciting for me.

 

 

 

Third, these graphics are indeed bitmaps, but they are very very very weird ones at that. Instead of being like a normal bitmap they start their image from the end of the file, so the top right pixel corresponds to the last byte in the bitmap file.

Actually, "real" bitmaps use this raster order too.
Rather than use "standard" raster order (that being left-to-right, top-to-bottom, like words on a page), they use vertically inverted raster order. It still goes left-to-right, but the y component is flipped.
 

 

Didn't know that. In the GameBoy Advance (which is what I usually mess around with) it does it from top to bottom, but in 8x8 squares. Interesting to know that this isn't anything new.

 

 

 

OK, so apparently this in-built bitmap format is a lot more complicated than I thought. Turns out it is slightly compressed, but not using a compression algorithm. Instead they have a system to minimize the number of bytes used which makes things a bit more difficult. Basically, each byte can be as little as 2 pixels to as many as 4, which complicates things since that means that somehow it's selecting other colors from the 256 color palette shown in the normal images, which also means that I have to decipher a crapton of other stuff in there.

 

Aside from that, I did figure out a way to dump images without directly decoding it. In the .dat files there is a property called total_number_of_frames that can be adjusted. So if you take a multi-framed object and set it to 1 frame it will turn up like this when you place the object down, exposing the entire image:

So I managed to dump some of the images, but unfortunately they don't exactly insert back in very well (hence the really crappy looking factory above), so we still have work do to. But they do load and animate correctly, it's just that they don't load the proper palette. So if we can figure out the proper palette we could most likely fix the issue. Not to mention that the building .but's will also have to be modified or the executable hacked to view them from a normal BMP instead of a .but. I'd personally rather do the latter because the bitmap format caused me much pain trying to figure out and I got absolutely nowhere outside of what I learned in the last post.

 

Just to give you guys an idea of what we're working with here, I'll throw up some of the ripped animations I got:

Also, this can work to our advantage in terms of other things since we can rearrange the images to rip other items that aren't buildings. So if we can figure out a way to get the palette to work correctly and to load other buildings we could have a potential modding scene here. I personally plan on using the resources to make a sort of "Open LEGO LOCO" which can recreate the game with proper networking support as well as improved modding ability and maybe a more Sim City like engine which could give purpose to the factories and restraunts while also implementing currencies and other things.

[lol username]

I want to make love to your posts here.
 

I personally plan on using the resources to make a sort of "Open LEGO LOCO" which can recreate the game with proper networking support as well as improved modding ability and maybe a more Sim City like engine which could give purpose to the factories and restraunts while also implementing currencies and other things.

Oh my goodness yes. Also, one of the things I've always wanted to be able to do in Loco is to directly control a minifigure to explore cities, both my own and others on the network. Just sayin'.

[shinyquagsire23]

So I finished ripping all the textures in the buildings folder, and I came across an unused building. I think it's rather interesting:

So apparently the house that could merge into a double house also was meant to merge into a quadruple house. And since a lot of the .dat files have the easter egg implementations I might be able to make a mod that could restore this since the texture is fully intact, although when it's placed via attaching a .but with the same name part of the texture is cut off, although I'm sure that's fixable. Once I get to ripping the paths folder I might actually find the one beta path that can go over train tracks that everyone seems to be talking about.

[Jimbob]

I doubt I can express gratitude as well as jamesster, but this is truly epic. Keep at it.

 

Anyone for a Rock Raiders version of LEGO LOCO?