Resource.spr and Animated Terrain

[Catfish]

I'm currently compiling a graphics overhaul for the Original game as a favour to someone. It includes minor edits on some animated terrain sprites. I want to avoid having the animated terrain appear in scenario games without renaming resource.spr in the Original directory. Terrain animation lockout never works. Is enough known about the .spr file format to be able to create a dummy (blank) resource.spr file which can then be dropped into every scenario folder?

[Mercator]

Originally posted by Catfish
Terrain animation lockout never works.

Yes it does, but no-one seems to understand it. The two lockout options do NOT disable animation, they simply lock the value you had set in the game menu.

If you had animation turned on, and then do the lockout, animation will always be on. If you have animations turned off, and then do the lockout, animation will always be off.

I've never had any problems with it.

But if you do insist on a blank one, yes, enough is known about the format. You should be able to hex-edit it. See this thread:
http://apolyton.net/forums/showthrea...threadid=61778
In particular, get the text file I attached in the last post. That pretty much describes everything.

But you could also try creating a completely blank resource.spr file (zero bytes). I don't know if that works, but it's worth a shot. It's certainly a lot easier than hex-editing.

[Catfish]

Originally posted by Mercator
Yes it does, but no-one seems to understand it. The two lockout options do NOT disable animation, they simply lock the value you had set in the game menu.

If you had animation turned on, and then do the lockout, animation will always be on. If you have animations turned off, and then do the lockout, animation will always be off.

Thanks Mercator. That clarifies things. Lockout simply disables the Animated Units/Terrain options in the Graphic Options menu. Given that these settings are universal, the lockout options are about as useful as a *** on a bull.

Originally posted by Mercator
I've never had any problems with it.

It works for me too… well, mostly. Lockout works as described above. However, when I disable animated terrain in the Graphic Options menu I keep getting the oil resource from the Original game in my scenario games. It's not animated, but it's there and it's definitely from resource.spr (it's the last of 4 frames).

Originally posted by Mercator
But if you do insist on a blank one, yes, enough is known about the format. You should be able to hex-edit it. See this thread:
http://apolyton.net/forums/showthrea...threadid=61778
In particular, get the text file I attached in the last post. That pretty much describes everything.

I visited that thread yesterday, but couldn't download any of the attachments. In fact, I now find that I can no longer download any text attachments from Apolyton. I'll try stuffing around with my firewall and ad-blocking software.

Edit: Nope. No luck. Hell, I'm even having trouble editing this post - getting the all-too-frequent "too many users, must log in" message when I hit Save Changes.

Originally posted by Mercator
But you could also try creating a completely blank resource.spr file (zero bytes). I don't know if that works, but it's worth a shot. It's certainly a lot easier than hex-editing.

It doesn't. It crashes the game.

[Mercator]

Originally posted by Catfish
Thanks Mercator. That clarifies things. Lockout simply disables the Animated Units/Terrain options in the Graphic Options menu. Given that these settings are universal, the lockout options are about as useful as a *** on a bull.

Um, no... The settings aren't universal. The lockout settings are saved in the scenario file, so they force the animation settings for that scenario.

It works for me too… well, mostly. Lockout works as described above. However, when I disable animated terrain in the Graphic Options menu I keep getting the oil resource from the Original game in my scenario games. It's not animated, but it's there and it's definitely from resource.spr (it's the last of 4 frames).

Well, here are the contents of that text file:

STATIC.SPR

FILE HEADER
           bytes: value
----------------------------------------
HEADER
 1       4 bytes: 0, due to absence of animation header section
 2       4 bytes: 12, offset for the "image offsets" section
 3       4 bytes: offset for the image section
IMAGE OFFSETS
   406 x 4 bytes: image offsets (from start of image section), the last one of
                  these offsets points to the end of the file.

IMAGES
ID         bytes: value
----------------------------------------
IMAGE HEADER
 1      16 bytes: 0 (?), changing it doesn't seem to have any effect
 2       4 bytes: image width
 3       4 bytes: image height
 4       4 bytes: nr. of starting empty columns
 5       4 bytes: nr. of starting empty rows
 6       4 bytes: nr. of columns (= width up to the last non-empty pixel)
 7       4 bytes: nr. of rows (= height up to the last non-empty pixel)
 8       1 byte : always 0xFD, seems to have something to do with the
                  transparent pixels (only those that are actually present in
                  the image encoding, not the "assumed" transparent pixels at
                  the start/end of the rows/columns of the image)
 9       4 bytes: image body size
IMAGE BODY ([img header value 7] - [img header value 5] rows)
 1       4 bytes: nr. of empty bytes~~
 2       4 bytes: row data size (= N)
 3       N bytes: row image data**
IMAGE FOOTER
 1      10 bytes: 0 (?)

~~ This number of bytes corresponds with half this number of transparent pixels
(since the image is 16-bit, or 2 bytes per pixel).

** The image data is in 15+1 bit format (in Big Endian byte order that would be:
1-5-5-5). The first bit indicates whether the pixel's shade is changed to the
civ color (1) or not (0). The other 15 bits are 5 bits each in the order R-G-B.
Transparent pixels are represented by magenta (Little-Endian 0x1F7C or
Big-Endian 0111110000011111).



UNITXX.SPR

FILE HEADER
ID         bytes: value
----------------------------------------
HEADER
 1       4 bytes: 12, offset for animation header section. Since that section
                  isn't in Static.spr, it probably has to do with the animation
                  aspect. Such as telling which images belong together in an
                  animation, and how long each of those frames should be
                  displayed.
 2       4 bytes: offset for "image offset" section
 3       4 bytes: offset for image section
ANIMATION SECTION
 1  32 x 4 bytes: offsets for per animation information.
                  (8 facing directions x 4 actions = 32 animations)
                  The actions are, in order: Attack, Die, Idle, Move.
                  The directions start at North, continuing
                  clockwise to end at Northwest.
                  The offsets indicate first all directions of Attack, then the
                  animations for Die, then Idle and Move.
                  NOTE: The offsets need not necessarily be in ascending order,
                  or even different. You could let the file contain only one
                  animation, with all actions and directions using the same one.
 2   X x 4 bytes: for each frame in an animation...
                  1.    points to the Nth (zero-based) image in the file.
                        That means two things: there can't be more than 256
                        images in an animation file, and more interestingly, you
                        can reuse frames.
                  2.    This seems to be a "flag" byte:
                        ..1. ....       marks a "start loop" frame
                        .1.. ....       marks an "end loop" frame (loop back to
                                        last start)
                        1... ....       mirrors a frame (horizontally)
                        ...x xx..       these 3 bits control transparency:
                                        000 = fully visible ... 111 = fully
                                        transparent
                                        (used for fading out dying units)
                        [The remaining two bits are used in the resource file at
                        least, but I don't know for what yet.]
                  3-4.  This seems to be a short integer/word also used as a
                        flag of some sort. It is mostly 6.
                  It seems as if a fade-out animation must end with the sequence
                  0000 0001. It doesn't seem to be possible to control frame
                  rate, e.g. Die animations often have two of the same frames
                  following each other, which makes the animation twice as
                  "slow" as the others.
                        
[...]
IMAGE OFFSETS
     X x 4 bytes: image offsets (from start of image section), the last one of
                  these offsets points to the end of the file.

IMAGES
As in Static.spr



RESOURCE.SPR

This one's pretty much the same as the units sprite files. Some extra notes:
If a resource doesn't have animation, the corresponding header value points it
to an empty animation (hex sequence 0020 0001, 0001 probably means something to
the effect of "don't display me", the 20 part is the "start loop" flag).
While the unitXX.spr has the first part of the animation header nicely in
ascending order of offset, the resource.spr has that section in pretty random
order. Plus, a lot of the animations are empty, so the animation "summary"
points all of those to a final entry in the frame information part.

The first part of the animation header is obviously different from the units:
 1  88 x 4 bytes: (4 maps x 11 terrains x 2 resources)
                  In the following order: first resources of first map
                  (following regular terrain order from Desert through to
                  Ocean), second resources of first map, first resources of
                  second map etc.

[Catfish]

Originally posted by Mercator
Um, no... The settings aren't universal. The lockout settings are saved in the scenario file, so they force the animation settings for that scenario.

That's not the way it works for me. I see no indication that the animation settings are saved at all. If they are, it would appear that they are ignored, because in my case the settings are always carried over from the previous game (of any type) – even if I quit ToT entirely before loading the .sav/.scn in question. The only apparent change is a disabling of the Graphics Options.

The info from the text file was exactly what I needed. Here's the dummy resource.spr file - a colossal 369 bytes unzipped. Oil problem solved. Drop the file into any scenario folder and you'll have no interference from the Original game's animated resources, whether you have animation turned on or off.

[Mercator]

Originally posted by Catfish
That's not the way it works for me. I see no indication that the animation settings are saved at all. If they are, it would appear that they are ignored, because in my case the settings are always carried over from the previous game (of any type) – even if I quit ToT entirely before loading the .sav/.scn in question. The only apparent change is a disabling of the Graphics Options.

Yes... That does indeed seem to be the case. I usually have animations turned off, so I guess that's why I didn't notice. I guess that means the lockout forces the options in their last used state, and not the state you set when making the scenario (as it should have been). Of course, those two are one and the same when you're making your scenario.

The info from the text file was exactly what I needed. Here's the dummy resource.spr file - a colossal 369 bytes unzipped. Oil problem solved. Drop the file into any scenario folder and you'll have no interference from the Original game's animated resources, whether you have animation turned on or off.

That should come in handy...

[Mercator]

Wait a minute...

How does this work?
http://apolyton.net/forums/showthrea...threadid=15262