EMI .til backgrounds. Help needed.

[Benny]

I've been making an EMI tile viewer/creator 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 there is additional (masking?) data in that third tile. When I compile the .til with that present I end up with this. 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.

[Benny]

This is John's original specs. Its probably easier to read than the specs in my post above.

[Benny]

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.

[Benny]

Works now, just need to sort out the masking stuff. So that the door image or whatever can be replaced.

 

1

2

[john_doe]

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.