Thanks for the colaboration Sam I'm sure people will find your recopilation very useful. (Specially when using the tool is a bit awkward cause I didn't have time to code a GUI with buttons to open files, batch convert and such things)
As I previously said frm type 68 is now known too, and before I update the tool (i'm lacking time right now) I'll explain a bit:
Header: The same as the one in frm16 type 64 with a little diferrence:
-Instead of ending at offset 36, frm16 type 68 has 4 extrabytes at the end, which represent pixel data size (repeated, as frm16 type 64 already has that entry in it's header).
The first thing we notice is the mentioned entry (pixel data size) indicating a size of 37573. If you multiply width*height you'll get 779*339= 257070 which is much more bytes than the specified by pixel data, even if pixel data is a byte per pixel it's still much less than the actual pixels of the image. So we guess this is compressed somewhat.
Then we have actual pixel data, starting at offset 40, something like this in hex:
3F0000 3F0000 3F0000 3F0000 3F0000 3F0000 3F0000 3F0000 3F0000 3F0000 3F0000 3F0000 170000
As you can see there's a pattern there, and knowing that the first pixels of the image will be in black (we guess again) and that frm16 type 64 uses 16-bit colour representation (2bytes) you see that the upper hex numbers are just 3 bytes, the first one a instruction the two second the 16-bit colour. So, what they tell is 3F = 63 decimal -> Write 63 times colour 00 00 (RGB 00 00 00 -> black)
We find the same groups of three bytes 12 times. So what we actually are doing is writing colour black 12*63 times = 756 times. Mmm. isn't that very close to the widht entry value, which is 779?
Let's see the last instruction 17 00 00: It's clear that it instructs us to write black 17hex=23dec times. Voilá! 756+23= 779. That's the image width and so we have the first line of the image.
What we have here is a manner of Run Lengh Encoding (RLE) and that's why the .txt associated to this images have RLE = 1 (on)
Of course I didn't read the full image which is very big, and the total pixel size is not divisible by 3 so sure we'll find some more instruction code, surely one which says "this part doesn't has RLE" as RLE losses compression if it's used on different pixels (there must be more than 3 equal pixels to have compression benefits from RLE) Anyway this don't worry me as now we've figured the format we can look at it knowing what he wants to do and how do you expect it to do.
I'm updating the pixel writing algorithm for this type of frms:
if( frmType == 64 ) { fseek( fichero, 36, SEEK_SET ); for( int j = 0; j < height; j++ ) { for( int i = 0; i < width; i++ ) { fread( &pixel, sizeof(pixel), 1, fichero ); fillRect.x = i; SDL_FillRect( spfcePrincipal, &fillRect, pixel ); } fillRect.y = j; } } else if( frmType == 68 ) { fseek( fichero, 40, SEEK_SET ); for( int j = 0; j < height; j++ ) { for( int i = 0; i < width; i++ ) { fread( &byte, sizeof(byte), 1, fichero ); fread( &pixel, sizeof(pixel), 1, fichero ); for( int count = i; count < i+byte; count++ ) { fillRect.x = count; SDL_FillRect( spfcePrincipal, &fillRect, pixel ); } i += byte; } fillRect.y = j; } }We'll see when I get this to work (or when I have time to actually do it, now I have to study hehe)
Edited by Balder, 24 August 2009 - 01:49 AM.
