Understanding Tot Sprite File Format

[St Leo]

I wouldn't mind getting my grubby hands on that utility.

[Daftpanzer]

I found out some more (attached)... And more importantly, I've made a little utility. So far it can only export all images in the Static.spr files to 24-bit bitmaps though (the info from Zarion was more than enough to figure out how to "decode" the images )...

Sounds like a sprite editor to me!

If the bitmaps can be put back into a SPR.....

[Mercator]

Not yet...

[William Keenan]

I wonder if the sprite files are in PPM format?

http://astronomy.swin.edu.au/~pbourke/dataformats/ppm/

[Mercator]

Nope

They're in some custom "compressed" 15/16-bit bitmap format. I don't think it's a pre-existing format, because the "compression" is done to reduce all the superfluous transparent "pink" surrounding the images. I don't think many would really need such compression (except game designers).

I have figured out the exact details of the single images in the sprite, I'm not too sure about all the file header details, though...

In any case, I'm working on a sprite editor, which will be able to export sprites to a pair of bitmaps, and import them again. A pair of bitmaps, since one bitmap holds the "normal" image, the other holds the civilization-color mask.

I now have procedures ready that can convert between bitmaps/sprites, but no procedures yet to retrieve the images from the sprite file (I started over since last time, to be able to support the unitXX.spr and resource.spr)...

It all depends on how busy I'm gonna be with other things how long it will take me from here.

[techumseh]

Can't wait..... !

[curtsibling]

This is a breakthru that may just refresh interest in ToT,
Also it will be a stunning discovery for we ToT scenario makers!

Good luck, gentlemen!!!

[Mercator]

It's probably going to take a while yet... I have to do some serious thinking on what the interface is gonna look like.
Some better news: I found out a bunch more about the animation information in the resource/units sprite files:
- You can specify whether you want to loop an animation or not (or even, say, only loop the latter half of an animation, after an initial first half).
- You can make animations semi-transparent, like the die animation fade-out. Since you can specify the transparency level for each frame, you can do quite some more complicated things with it (say, have an entirely semi-transparent "Ghost" unit).
- Frames can be mirrored, saving you from making unnecessary additional frames.

There are quite a few more technical intricacies, which are especially challenging to program correctly: animations aren't saved in full, one after the other. Instead, the header specifies which animation to use, and for each animation which of the images in the file to use. That means you could reuse both animations and frames indefinitely while only one instance is actually saved in file.

For the static unit images, only 5 directions are stored: North, Northeast, East, Southeast and South. The remaining 3 are created by mirroring on of the above.
For the animated unit images, all 8 directions are stored, but, as stated earlier, you can reuse and mirror individual frames.

I'll post the new file format description soon...

(and the eager creators will have to wait a little longer )

[Mercator]

Here's the text file I promised...
No progress since my last post though (well, my planning on paper has come a little further).