 |
| |
|
|
Catfish
|
|
Wollongong, Australia
Aug 2000
time: 14:36
|
|
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
|
 |
Sorekara no Nanimo
Jan 1970
time: 06:36
|
|
quote:
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/showthre...&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
|
|
Wollongong, Australia
Aug 2000
time: 14:36
|
|
quote:
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.
quote:
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).
quote:
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/showthre...&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.
quote:
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.
Last edited by Catfish on 16-07-2004 at 05:32
|
|
| |
|
|
|
Mercator
|
|
Sorekara no Nanimo
Jan 1970
time: 06:36
|
|
quote:
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.
quote:
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.
|
|
| |
|
| |
|
| |
All times are GMT. The time now is 05:36.
Apolyton Time is 00:36. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
15-07-2004 07:08
Attachment: 
|