More about EPF

[DDeokk]

short tile_count (2 bytes)
short height (2 bytes)
short width (2 bytes)
short unknown (2 bytes)
int pixel_data_length (4 bytes)
byte[pixel_data_length] pixel_data (pixel_data_length bytes)

stencil_data goes here

tile_entry[tile_count] tile_entries (tile_count * 16 bytes)

typedef struct {
short pad_top (2 bytes)
short pad_left (2 bytes)
short height (2 bytes)
short width (2 bytes)
int pixel_data_offset (4 bytes)

int stencil_data_offset (4 bytes)

} tile_entry (16 bytes)

In case of tile.epf
stencil data of an image are
98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00 98 00

There are 24 '98 00's. The number(24) of them means # of rows in an image.
Each number of them contains information about how many pixels are to be drawn or ignored.

'98' can be represented as 10011000 in binary number.
First bit '1' means 'they are to be drawn'. Otherwise, 'they are to be ignored'
The other 7 bits indicates the number of pixels.

So, one can figure out that '98 00' means
draw 24 pixels
ignore 0 pixels which says 'no more to specify'

[DizzyThermal]

@DDeokk, thanks for providing this info!

If I understand your explanation correctly, the stencil_data could indicate which areas of a tile/object are transparent? When applying a Static Object (with transparency) on top of a Tile (A or B - without transparency), I could determine the transparency of the object using this stencil data? Does that sound right?

Either way. I will look into this more tonight and see where I get with it.

Also, "stencil_data_offset" would be the "unknown_offset" in the "tile_entry" structure, correct?

Thanks again!

[DDeokk]

@DizzyThermal

Yes, that's correct.
Happy implementing

[wattostudios]

Hi Dizzy,

I added some info about other EPF archives at http://forum.xentax.com/viewtopic.php?f=18&t=16943&start=15 if you're so interested. Not really sure if you're wanting to take your tool this way or not, but thought I'd provide the info anyway.

watto

[DizzyThermal]

Thank you for the DSC/FRM/DNA file structures @wattostudios

The tool's file_reader module is intended to handle all TK file formats, so these are great additions!

As for where/how to present all the different image formats/types in the QT5 GUI is another question. I'm open to suggestions/contributions on GUI/layout structure - as this is not my forte.

Thanks again!

[DizzyThermal]

@wattostudios I was successful in reading in the DSC file (ignoring chunks and blocks, for now).

When I try to read the EPF image, my width values are incorrect (i.e., -65514)
I'm not sure if the problem is the calculation of EPF width and height (right-left, top-bottom), or the actual dimensions have offsets. You did mention Width = Width + (0-X-Position), but I'm afraid I'm not sure how to apply it.

My EPF File definition has slightly changed, but it does take the right-left, top-bottom approach to determining width and height:
https://github.com/DizzyThermal/TKViewer/blob/master/file_reader.py#L99

Any help would be appreciated. Thanks!

[DDeokk]

The right-left, top-bottom approach is perfect. I wonder the data type or acquisition of values in your code might matter.

[DizzyThermal]

@DDeokk, thanks for the clarification.

I think the remaining question I have is how to interpret the stencil_data..

I have been trying to understand your explanation in the first post, but am struggling to implement it correctly

[DizzyThermal]

Stencil implemented to fix transparency issues