PDA

View Full Version : EMI .til backgrounds. Help needed.


bgbennyboy
08-31-2003, 12:33 PM
I've been making an EMI tile viewer/creator (http://www.gorman.btinternet.co.uk/tile1.jpg) so that (together with my lab creator/dumper) you can change the backgrounds in EMI.

This is the .til format as set out by John_Doe in 2000:


Header:
id: 4 bytes 'TIL0'
bmoffset 4 bytes Start offset of the bitmap data
rects 4 bytes number of rects
something 4 bytes ??
something 4 bytes ??

Then <rects> times a rectangle:
x single x
y single y
x2 single x2
y2 single y2

Then the bitmap data:
Bitmap Header:
id 4 bytes 'BM '
something 3 * 4 bytes 4 unknown longs
notiles 4 bytes number of tiles
something 27 * 4 bytes 27 unknown longs

Repeat for each tile:
Width 4 bytes Tile width
Height 4 bytes Tile height
Tile data = width * height *4

The tile data consists of 4 bytes for each pixel. Red, Green, Blue and another.

"Draw one tile after another as if it was a sprite. There are (always?) three tiles in a row.
If you've put three tiles, you increase the 'put position' (the y coordinate) by 256
(seems all tiles are 256*256, that's good for 3D cards).

Because the lower-right part of the background is in the third tile
(what looks strange, and what wouldn't be saved in the 640*480 image anyway),
you'll have to copy that 128*223 big strip to where it should be.
The x/y position of the strip is 640/0, the destination x/y position is 512/256."


Right:
As you can see here (http://www.gorman.btinternet.co.uk/tile1.jpg) there is additional (masking?) data in that third tile. When I compile the .til with that present I end up with this (http://www.gorman.btinternet.co.uk/new2.jpg). So it seems like there is still further masking or transparency data within the file.

Can anyone fill in the gaps in the specs or speculate on what they might be? Specifically:
The extra byte in the colour data
The 27 unknown longs in the bitmap header.
Currently, the values that are unknown I copy out of the original file, but this still produces the graphical problem shown.

I'm also not sure about the repeating <rects> * a tile. This leaves a 128 byte gap between the end of the rects data and the start of the bitmap offset in mel_scushot.til (the attached file).

This is a long and probably confusing post, but if anyone can help, even just with speculation it would be great.

bgbennyboy
08-31-2003, 01:12 PM
This (http://gamefileformats.netfirms.com/files/lec/emi-tile-specs.zip) is John's original specs. Its probably easier to read than the specs in my post above.

bgbennyboy
08-31-2003, 08:31 PM
Update #2, I just noticed more masking data in the tile's. Bah, that should make it work fine. If anyone can fill in any holes in the specs though, please do.

bgbennyboy
09-01-2003, 03:05 PM
Works now, just need to sort out the masking stuff. So that the door image or whatever can be replaced.

1 (http://www.gorman.btinternet.co.uk/Fixored.jpg)
2 (http://www.gorman.btinternet.co.uk/Fixored2.jpg)

john_doe
09-01-2003, 06:22 PM
Seems the "rectangle" stuff in the tils is the coordinate information. I didn't figure out how it works yet and there are also negative numbers which is strange (could be that the origin is not in the upper-left but in the middle of the image at width/2, height/2).

The longint at 0x019C stores how many rectangles there are. Each rectangle is made up of 16 bytes: One Single (4 bytes) for X,Y,Width,Height. (Width and Height might also be abolute coordinates).

This then fits until you reach the gap you mentioned.
I couldn't find out where it's size/number of entries or something is stored.