Jump to content

Bmp Files


dead_name
 Share

Recommended Posts

dead_name

Pretty sure he just used TGA textures, by the way.

Au contraire, I used BMPs, I just used the non-compressed variant.

Link to comment
Share on other sites

Pretty sure he just used TGA textures, by the way.

Au contraire, I used BMPs, I just used the non-compressed variant.

Plain, 16bit BMPs? What made you think if that?

Link to comment
Share on other sites

lol username

Ok, thanks. And the non-compressed BMP files still use a custom format, correct?

Link to comment
Share on other sites

dead_name

Pretty sure he just used TGA textures, by the way.

Au contraire, I used BMPs, I just used the non-compressed variant.

Plain, 16bit BMPs? What made you think if that?

*sigh* please forgive me, but my patience is being pushed here.

Aside from the audio and a couple of TGA files, LEGO Racers 1 uses COMPLETELY CUSTOM FORMATS. Stop thinking that it uses standard formats because I guarantee you it does not. BMP is just a file extension, it doesn't mean anything. I could create a file with the .exe extension, doesn't mean it's actually executable code. File extension and internal data format, while usually linked, are not technically dependent on each other.

The BMP format LR1 uses has 2 different variants; Paletted and RGB.

The first byte of a paletted bitmap will always be 0x04 or 0x08 (denoting the number of bits per index). The first byte of a RGB bitmap will always be 0x98.

The paletted bitmaps contain a color palette and an index map. The palette is always uncompressed. The index map is divided into blocks (of no more than 1000 bytes each). Each block may be compressed but not all of them are. The compression algorithm used is still a mystery, but uncompressed blocks can be read/written. A BMP where all the blocks are uncompressed can be completely extracted. As such, it's also possible to create a BMP where the data is all uncompressed and insert it into the game. This is what I did for the awesomeface experiments.

The RGB bitmaps do not contain a palette; the data seems to be RGB pixel data. However, said data is compressed, and without the algorithm there's nothing we can do with these.

Also, please stop posting my videos. I'm perfectly capable of doing that myself.

Ok, thanks. And the non-compressed BMP files still use a custom format, correct?

As explained above, yes.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

Any more information out there on how to create those custom BMP files? I'd like to recreate the original textures in updated HD sizes. Here's two sample textures I've created already;

l8rQ8.jpg

Link to comment
Share on other sites

Any more information out there on how to create those custom BMP files? I'd like to recreate the original textures in updated HD sizes. Here's two sample textures I've created alread

Yes and no. No, in the fact that origamiguy has been busy with school and other stuff, so he may have not had time to do any more work on the BMPs. Yes, in the fact that you can use plan 32-bit BMP files and put them in-game.

Anyway, good luck with your project. The BMP's can't be viewed in a normal image viewer, and until the format is completely broken, swapping textures are blindly done. Combine the fact the all files in the JAM must be under 12 characters, they are in no way descriptive.

So, good luck with that, and let me know if you finish it.

Link to comment
Share on other sites

lol username

Yes, in the fact that you can use plan 32-bit BMP files and put them in-game.

Aside from the audio and a couple of TGA files, LEGO Racers 1 uses COMPLETELY CUSTOM FORMATS. Stop thinking that it uses standard formats because I guarantee you it does not.

Ok, am I missing something here?

Link to comment
Share on other sites

Ok, am I missing something here?

Yes.

origamiguy' timestamp='1336209485' post='72249']

Au contraire, I used BMPs, I just used the non-compressed variant.

And it does work. I have screenshots of it. They aren't uploade anywhere though, and I'm not @ home, so I don't have access to the laptop. But, it is possible. 16 & 32-bit uncompressed BMP files work. It's the original files that are compressed. I'm pretty sure the audio is the same way, but I neeed to do some research to finalize my theory.

EDIT: I modded the main menu, if you care to know that fact. I used a texture from LU, as well as the LEGO logo (RR was drowning in the LEGO logo.)

Edited by le717
Link to comment
Share on other sites

Hm, alright. Well it's going to be a problem to recreate the textures in HD when you can't view the original files :) I've used N64 version textures in my above sample. Well, I'll stay updated once BMP files are readable.

Link to comment
Share on other sites

lol username

Ok, am I missing something here?

Yes.

origamiguy' timestamp='1336209485' post='72249']

Au contraire, I used BMPs, I just used the non-compressed variant.

And then...

BMP is just a file extension, it doesn't mean anything. I could create a file with the .exe extension, doesn't mean it's actually executable code.

So, define BMP. Up unto this point, from what I had heard, LEGO Racers itself used two different and custom formats both with .bmp extensions, as well as some TGA textures, and that we had figured out one of the two "BMP" formats to the point where we could create custom textures in said format by not compressing any of the blocks, as the compression has not yet been figured out. Additionally, from what I've heard, it is possible to make standard TGA textures work so long as they're actually applied to geometry and not for the GUI. So, we can create textures for LEGO Racers in one of the two custom "BMP" formats and as standard TGA textures, and until you mentioned it now I hadn't heard anything about standard BMP format textures working in the game.

And it does work. I have screenshots of it. They aren't uploade anywhere though, and I'm not @ home, so I don't have access to the laptop. But, it is possible. 16 & 32-bit uncompressed BMP files work. It's the original files that are compressed. I'm pretty sure the audio is the same way, but I neeed to do some research to finalize my theory.

Yes, some proof of this would be nice.

Link to comment
Share on other sites

16 & 32-bit uncompressed BMP files work.

Yes, some proof of this would be nice.

I just replaced FFROAD6.BMP and TSTROAD.BMP in GAMEDATATEST with 24 bit bitmaps, and it worked!

LRR_24BMP_PROOF.png

I didn't use the same texture for both. TSTROAD.BMP is grey so I could tell the difference.

EDIT: 8 bit bitmaps also work. I'm assuming 16 bit bitmaps work as well.

  • Like 1
Link to comment
Share on other sites

lol username

Heh heh... Oh the possibilities... I'll toy with this today and post the results. I have maaaany ideas.

Link to comment
Share on other sites

Heh heh... Oh the possibilities... I'll toy with this today and post the results. I have maaaany ideas.

I hate to say it but I told ya so. :P

Jamesster, have I ever told you about a mod to any game and the mod wasnt even real? No. If you couldn't trust me on this small thing, how can I believe you'll trust me when I say that someone in LR was not originally planed to be in-game? :(

JK. But still... ;P

Link to comment
Share on other sites

lol username

I hate to say it but I told ya so. :P

Jamesster, have I ever told you about a mod to any game and the mod wasnt even real? No. If you couldn't trust me on this small thing, how can I believe you'll trust me when I say that someone in LR was not originally planed to be in-game? :(

JK. But still... ;P

Because everybody else I've talked to regarding LEGO Racers modding (including Will and Cirevam) haven't mentioned it, and you seemed a tad confused on texture formats in your previous posts in this topic, so I asked for some proof of it as it sounded unlikely, especially considering it seems to flat-out contradict what Will said in his texture explanation mini-rant. Not so sure why you're so concerned about showing you're right, as all I asked for was an explanation of what you meant and some examples of how you knew it. 0_o

Link to comment
Share on other sites

Because everybody else I've talked to regarding LEGO Racers modding (including Will and Cirevam) haven't mentioned it, and you seemed a tad confused on texture formats in your previous posts in this topic, so I asked for some proof of it as it sounded unlikely, especially considering it seems to flat-out contradict what Will said in his texture explanation mini-rant. Not so sure why you're so concerned about showing you're right, as all I asked for was an explanation of what you meant and some examples of how you knew it. 0_o

Yes, I was a little confused in the earlier posts on this topic.That happens to everyone. It happened to me because I had not read the posts as well as I should have.

I'm not concerned about showing that I'm right. That was the last thing on my mind.

Yes, it does flat-out constrict Will's mini-rant there. But I'm an analytical thinker, and because of that, I can pull stuff out that other people may not see.

As for how I knew, I've told you already. But, I'll expand it a bit more.

When the videos were posted, I was miles from home at an event. All I had was Dad's iTouch, and his laptop with LR 1999 and the JAM extractor. When Will said:

Au contraire, I used BMPs, I just used the non-compressed variant.

I knew precisely what he had done.

BMP files are not compressed. They pack a bunch of pixels into them, and they duplicate the pixels like crazy, making a large size, but also for the fact that, when they are shrunk, they don't loose too much of their original quality. On the way home, I loaded up the laptop, got some test images, and converted them to 16, 24 and 32-bit BMP files via Photoshop. I loaded them in, and it worked. RR was floating in the LEGO logo, and the YouReeka ground tile looked awesome in-game.

Will's mini-rant clearly states that all formats, aside from the audio and a few TGA files, are custom formats. And I will not dispute that.

But let me sidetrack here for a moment and explain something I learned from my audio modding experience.

bartvbl did indeed say that the audio was VOX, and when I came along, I took his research and made a tutorial for creating them. But as you know, the tutorials is far from perfect. The raw audio is distorted, and we have to manipulate our audio so much to get it in game that it may because unrecognizable. This is because, as much as I dislike it, the audio is a custom format too.

The headers of the game (raw) audio say ALP ADPCM, while files created by SoX and Audacity do not have this header. Then why does it work in-game? The raw audio is indeed VOX, but it's been modified every so much that we cannot extract it correctly, and we cannot create it perfectly. If we really know the format, and how much different it is from true VOX, we could pull it out like it sounds it game, and out audio would sound like it was there the whole time.

The same thing is happening here. The BMP files are changed (compressed) every so much that we cannot view them, but they are similar enough to normal BMPs that we can insert normal (uncompressed) BMP files and it will read them.

Thus when I said that normal BMP files would load, I had already tested it and I already knew they would. If I had not tested it, I would have said something like "They might work, but I'm not sure" instead of

Yes, in the fact that you can use plain 32-bit BMP files and put them in-game.

That is how I knew they would work.

I wasn't kidding about the racer who was not to be in game, you know. It's true, and I have solid, indisputable truth and facts to prove it.

Link to comment
Share on other sites

lol username

I'm not concerned about showing that I'm right. That was the last thing on my mind.

Then why was it the first thing you said? :P

<long explanation>

Except, as far as I know, the two custom texture formats in LEGO Racers have little to do with the common BMP format, they just happen to have a ".bmp" extension tacked on. Obviously, we can't do much with the completely compressed "BMP" files in LEGO Racers, but as for the other format, we can read the blocks out of the image that aren't compressed, and create images in that format by simply not compressing any of the blocks (which, as far as I know, is what Will did for the awesomeface experiment). However, even those completely uncompressed custom "BMP" files have little to do with standard BMP files like you tried. Frankly, from what you've said here, this seems more like a stroke of luck that standard BMP files worked, rather then the LR1 BMP formats having anything to do with standard BMPs and deducing that they would work. And the reason I was hesitant to take you at your word that they worked is because none of the more experienced people here have made any mention of it, and you... erm... Haven't exactly been the most reliable source of information on stuff like this before. You seem to often rush to posting your finds before completely researching them, and your previous posts here seemed exactly like another one of these:

http://legouniverse....7/This_Is_Wacky

http://legouniverse....sster,_It_Works

http://legouniverse....39;s_a_Wookiee!

I wasn't kidding about the racer who was not to be in game, you know. It's true, and I have solid, indisputable truth and facts to prove it.

Why do I get the feeling this has to do with that comment you left on the LEGO Racers test animation video? >_> Also, see above.

Link to comment
Share on other sites

JrMasterModelBuilder

What?!? Regular bitmaps work in game? That's surprising.

I'm not concerned about showing that I'm right. That was the last thing on my mind.

Then why was it the first thing you said? :P

<long explanation>

Except, as far as I know, the two custom texture formats in LEGO Racers have little to do with the common BMP format, they just happen to have a ".bmp" extension tacked on. Obviously, we can't do much with the completely compressed "BMP" files in LEGO Racers, but as for the other format, we can read the blocks out of the image that aren't compressed, and create images in that format by simply not compressing any of the blocks (which, as far as I know, is what Will did for the awesomeface experiment). However, even those completely uncompressed custom "BMP" files have little to do with standard BMP files like you tried. Frankly, from what you've said here, this seems more like a stroke of luck that standard BMP files worked, rather then the LR1 BMP formats having anything to do with standard BMPs and deducing that they would work. And the reason I was hesitant to take you at your word that they worked is because none of the more experienced people here have made any mention of it, and you... erm... Haven't exactly been the most reliable source of information on stuff like this before. You seem to often rush to posting your finds before completely researching them, and your previous posts here seemed exactly like another one of these:

http://legouniverse....7/This_Is_Wacky

http://legouniverse....sster,_It_Works

http://legouniverse....39;s_a_Wookiee!

I wasn't kidding about the racer who was not to be in game, you know. It's true, and I have solid, indisputable truth and facts to prove it.

Why do I get the feeling this has to do with that comment you left on the LEGO Racers test animation video? >_> Also, see above.

jamesster is correct. The custom bitmap format LEGO Racers uses is nothing like a real bitmap. Also, each version of normal bitmaps isn't very much like the other. 24 bit bitmaps are just straight BGR (in that order) values stored in sequential 3 byte blocks (plus a header). 32 bit bitmaps are like 24 bit bitmaps, but are 4 byte chunks for an alpha channel. Lower bit bitmaps are reduced in color depth and lower still are pallet based (if I remember correctly). If the game is using non-custom bitmaps, the engine must have been set up to use them (it would make it easier to test).

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Allow me to come out of my cave and clarify my earlier statements. When I said that LR1 used completely custom formats, what I meant was this: the assets packaged with a vanilla install of the game are in custom formats. I was unaware that the game engine supports loading of conventional formats, and I appreciate that this has been pointed out. The fact still remains, however, that we cannot /extract/ textures from the game fully since we haven't wrapped our heads around the compression.

  • Like 1
Link to comment
Share on other sites

  • 3 months later...
  • 4 weeks later...
  • 2 years later...

The fact still remains, however, that we cannot /extract/ textures from the game fully since we haven't wrapped our heads around the compression.

I have wrapped my head around the compression. And it was a hell of research for me. But I made first progress. I am able to decompress the smaler files. For now I only get the color indices. I still have to surround them by a classic file format.

 

Obviously, we can't do much with the completely compressed "BMP" files in LEGO Racers, but as for the other format, we can read the blocks out of the image that aren't compressed, and create images in that format by simply not compressing any of the blocks (which, as far as I know, is what Will did for the awesomeface experiment). However, even those completely uncompressed custom "BMP" files have little to do with standard BMP files like you tried.

Did anyone created an 'real' image out of an uncompressed block?

 

I will show you an simple example (MENUDATAPIECEDBSQUAREZ2.BMP):

04 04 10 00 10 00 FF 00 00 00 FF 00 00 FF FF 00 
00 FF FF FF FF 80 00 24 00 44 80 0B 01 41 11 11 
14 43 33 33 70 34 00 08 16 0A 38 0A 05 40 00 00 
04 0E 42 22 22 24 00 08 16 0A 3D 00 00          
04          - BitDepth
04          - NumberOfColors
10 00       - Width
10 00       - Height
FF 00 00    - Color0
00 FF 00    - Color1
00 FF FF    - Color2
00 00 FF    - Color3
FF FF FF    - Color4
80 00       - UncompressedSize
24 00       - CompressedSize
44          - First two ColorIndices
80          - BlockHeader (0x10000000; 0 -> direct values, 1 -> RLE definition)
The BlockHeader[0] is 1 -> RLE
0B 01       - RLE (go 0x01 byte back and copy the next (0x12 - 0x0B = 0x07) bytes): 
44 44 44 44 44 44 44
The BlockHeader[1] is 0 -> direct value
41 
The BlockHeader[2] is 0 -> direct value
11 
The BlockHeader[3] is 0 -> direct value
11 
The BlockHeader[4] is 0 -> direct value
14 
The BlockHeader[5] is 0 -> direct value
43 
The BlockHeader[6] is 0 -> direct value
33 
The BlockHeader[7] is 0 -> direct value
33
70 - BlockHeader (0x01110000; 0 -> direct values, 1 -> RLE definition)
The BlockHeader[0] is 0 -> direct value
34
The BlockHeader[1] is 1 -> RLE
00 08 16    - RLE (go 0x08 byte back and copy the next (0x16 + 0x12 = 0x28) bytes): 
41 11 11 14 43 33 33 34
41 11 11 14 43 33 33 34
41 11 11 14 43 33 33 34
41 11 11 14 43 33 33 34
41 11 11 14 43 33 33 34
The BlockHeader[2] is 1 -> RLE
0A 38       - RLE (go 0x38 bytes back and copy the next (0x12 - 0x0A = 0x08) bytes): 
44 44 44 44 44 44 44 44
The BlockHeader[3] is 1 -> RLE
0A 05       - RLE (go 0x05 bytes back and copy the next (0x12 - 0x0A = 0x08) bytes): 
44 44 44 44 44 44 44 44
The BlockHeader[4] is 0 -> direct value
40 
The BlockHeader[5] is 0 -> direct value
00 
The BlockHeader[6] is 0 -> direct value
00 
The BlockHeader[7] is 0 -> direct value
04
0E - BlockHeader (0x00001110; 0 -> direct values, 1 -> RLE definition)
The BlockHeader[0] is 0 -> direct value
42 
The BlockHeader[1] is 0 -> direct value
22 
The BlockHeader[2] is 0 -> direct value
22 
The BlockHeader[3] is 0 -> direct value
24
The BlockHeader[4] is 1 -> RLE
00 08 16 - RLE (go 0x08 byte back and copy the next (0x16 + 0x12 = 0x28) bytes): 
40 00 00 04 42 22 22 24
40 00 00 04 42 22 22 24
40 00 00 04 42 22 22 24
40 00 00 04 42 22 22 24
40 00 00 04 42 22 22 24
The BlockHeader[5] is 1 -> RLE
0A 3D - RLE (go 0x3D bytes back and copy the next (0x12 - 0x0A = 0x08) bytes):
44 44 44 44 44 44 44 44
We reached UncompressedSize

By this we get:

44 44 44 44 44 44 44 44 
41 11 11 14 43 33 33 34 
41 11 11 14 43 33 33 34 
41 11 11 14 43 33 33 34 
41 11 11 14 43 33 33 34 
41 11 11 14 43 33 33 34 
41 11 11 14 43 33 33 34 
44 44 44 44 44 44 44 44 
44 44 44 44 44 44 44 44 
40 00 00 04 42 22 22 24 
40 00 00 04 42 22 22 24 
40 00 00 04 42 22 22 24 
40 00 00 04 42 22 22 24 
40 00 00 04 42 22 22 24 
40 00 00 04 42 22 22 24 
44 44 44 44 44 44 44 44 

That is it for now.

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.