Tweet
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?
-
Re: Resource.spr and Animated Terrain
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.Originally posted by Catfish
Terrain animation lockout never works.
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:
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. -
Re: Re: Resource.spr and Animated Terrain
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.
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
I've never had any problems with it.
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.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:
In particular, get the text file I attached in the last post. That pretty much describes everything.
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.
It doesn't. It crashes the game.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.Last edited by Catfish; July 15, 2004, 20:32.Comment
-
Re: Re: Re: Resource.spr and Animated Terrain
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.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.
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:
Code: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.Comment
-
Re: Re: Re: Re: Resource.spr and Animated Terrain
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.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.
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.
Comment
-
Re: Re: Re: Re: Re: Resource.spr and Animated Terrain
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...
Comment
-
Wait a minute...
How does this work?
Comment
Comment