STAND.RES
Vertical objects resource.

STAND.RES can be found within GAME_SCHEMEx.SUE along with it's palette file STAND.PL. EDIT_SCHEMEx.SUE contains STAND.EDT.

STAND.PL
It contains 8 palettes (standard 512-byte). In the editor, vertical objects are arranged in the 8 groups after which palette they use. Palette 5 are currently the only unused palette.

STAND.RES
Contains a number of RLE encoded graphic and additional properties for each vertical object in this file.

FILE STRUCTURE:
32bit integer: Number of registered table entries in STAND.RES
Table of absolute pointers, each entry is a 32bit integer pointing to a vertical object record
32bit integer: Pointer to end of file (filesize)
1..n Vertical object records
STRUCTURE OF VERTICAL OBJECT RECORD:
32bit integer: Palette index
32bit boolean: Remain
1 byte: Hardness
196 bytes block structure
6 * 32bit integers: Table of relative pointers to SS2 graphics
between 0 and 6 SS2 graphic pictures
Palette index informs you which palette from STAND.PL that should be used to draw the SS2 graphics. Remain is either true or false and informs you if the Block structure should remain after the object is destroyed. Hardness defines how much damage the building can take before changing to destroyed state. 0 means indestructable, 1..255 is hardness, with 1 as hardest to destroy.

Block structure consists of 14x14 subcells making up a 7x7 cell matrix, where each cell contains 4 subcells and each subcell is represented by one byte, giving a total of 196 bytes for the structure.

STRUCTURE OF SUBCELL: (1 byte)
1 bit: blocked if set
2 bit: somtimes used, but with no visible effect for vertical objects
bit 3-8 is unused for vertical objects
TABLE OF RELATIVE POINTERS:
pointer to image data ($A1) of the undamaged object
pointer to image data ($A1) of the destroyed object
pointer to image shadow data ($A3) of the undamaged object
pointer to image shadow data ($A3) of the destroyed object
pointer to image data ($A2) of the undamaged object
pointer to image data ($A2) of the destroyed object
The Table of pointers are relative to the Vertical object record start. So to get an absolute file offset for a pointer you just add the offset of the current record. If a pointer in the table is 0 then there is no graphics to decode for that entry.

These pictures are combined into two states, undamaged and destroyed.
undamaged pointers: 1,3,5
destroyed pointers: 2,4,6
The $A2 semitransparent bitmaps are usually used for the ground surrounding the object, allowing for some blending with the surrounding textures. When drawing a visible representation, the $A2 image is drawn first, then the $A3 shadow image and last the object itself.

Fireglow's way of storing two sampled pictures is:
undamaged $A1, undamaged $A3, undamaged $A2
damaged $A1, damaged $A3, damaged $A2
However, the meaning of the pointers, as I named them below, never changes.
undamaged $A1, damaged $A1
undamaged $A3, damaged $A3
undamaged $A2, damaged $A2
As a result of this, the second pointer damaged $A1 will have a higher offset than the third pointer undamaged $A3, as Fireglow writes the undamaged $A3 before the damaged $A1 and so on.

STAND.EDT
It mainly contains minimap representation of the objects contained in STAND.RES. Each 7x7 pixels minimap tile represents 7x7 cells in the editor. So if you scale your object down to 3.125% of its original size, you should have a correct minitile representation.

FILE STRUCTURE:
32bit integer: Number of categories to display in the editor
1..n Minitile records, 196 bytes each
STRUCTURE OF MINITILE RECORD
Minitile of the undamaged vertical object, 98 bytes
Minitile of the destroyed vertical object, 98 bytes
The 98 bytes that makes up a minitile is 16-bit colors entries (2 byte), which gives a tilesize of 49 pixels. These pixels should be placed and read as shown below:

Each line consists of 7 pixels. Just start at 1, follow the read line - while reading the pixels color information from STAND.EDT - towards 7, then goto 8 and so forth.

A decoding algorithm could look like this:


CODE
for i = 0 to 6 do
for j = 0 to 6 do begin
x = 6+j-i
y = (j+integer(Odd(i))) div 2+i div 2
Read(Pixel[x,y],2)
end

And it should be painted to a 16-bit image, 13 pixels in width and 7 pixels in height. Magenta (16-bit: $1FF8, RGB: 248,0,248), is used to indicate background (pixels not drawn).

This concludes vertical objects for now. Hope it'll be put to good use!

This post has been edited by mzach: Dec 2 2005, 11:11 AM