 |
STARQUAKE DATA FORMAT this document contains the data format for starquake, it is not complete but gives a good start and understanding. should you find any errors with this document or indeed have any information to add, please send me an email. |
|
STARQUAKE DATA FORMAT this document contains the data format for starquake, it is not complete but gives a good start and understanding. should you find any errors with this document or indeed have any information to add, please send me an email. |
| type | offset | description | |||||||||||||||||
| word | 0 | offset | |||||||||||||||||
| type | offset | description | |||||||||||||||||
| byte | -1... | attributes -
standard spectrum colours
|
|||||||||||||||||
| byte | 0...5 | character on/off bits | |||||||||||||||||
| byte | 6 | graphics pixels | |||||||||||||||||
| the platform gfx are stored in an odd way. The first 6 bytes are a bit mask to say which 8x8 block is available in the data. The data is stored in a 1x6 array so the maximum size of a graphic is 8x6 blocks or 64*48 pixels. Basically for each row read the byte and if the x bit is set, reading left to right, there is a 8 bytes of data to follow to draw this 8x8 square. The attributes start -ve from the original data and follow the same fashion. If you have decided to draw the 8x8 block, then an attribute block is available. The attribute is calculated like this; ( where data points to the curren attribute ) a = *data ; a &= 0x3f; if ( a==0x36 ) { a=(*data&0xc0)|_ea63; } else if ( a!=0 ) a=*data; else { a=(*data&0xf8)|_ea62; } a&=~0x40; |
|||||||||||||||||||
| NOTE: The attributes have an affect on platforms and collison. the Bright bit (6) is used to determine if a block is solid or not. You can pass through dull blocks but not bright ones. You can see this in the design of the green anti-gravity tubes, and also the doors of teleporters (which are dull white). - Thanks to Simon Owen for this information | |||||||||||||||||||
| address | 0xd03b | teleport information |
|
|
||
| type | offset | description | |
| word | 0 | destination screen no | |
| byte | 2-6 | ascii name |
| address | 0x7530 | screen data |
| the screen is a fixed 4x3 of big platforms so the data is a straight run of big platform numbers. locate the required screen by 12 to get the offset from this address. the map is made up in a 16x32 grid. | ||
| type | offset | description | |
| byte | 0...3 | top row | |
| byte | 4...7 | middle row | |
| byte | 8...11 | bottom row | |
| address | 0x9840 | big platforms |
| this is a 4 byte record table. the 4 bytes are each a small platform graphic that make up the big platform in a 2x2 graphic. The graphic is draw from bottom right to top left. locate the big platform byte multiplying by 4 | ||
| type | offset | description | |
| byte | 0 | bottom right platform | |
| byte | 1 | bottom left platform | |
| byte | 2 | top right platform | |
| byte | 3 | top left platform | |
| address | 0x9740 | Platform type information |
| this is accessed by platform no. it seems to have something to do with colour/behavious of the platforms. if the number is less than 0x50 then this is an attribute value that is stored in variable _ea63 and used for drawing platform graphics | ||
| type | offset | description | |
| byte | 0 | attribute/behaviour | |
| attrib | |||
| 0x5n | upward transport tubes | ||
| 0x6n | contain an area which kills on contact | ||
| 0x7n | ray effect | ||
| 0xCn | pick up flying pod thing | ||
| 0xDn | teleport | ||
| additional information on behaviours thanks to Matthew Wilson | |||
| miscellaneous addresses |
| this table points to the actual graphic data of the platform sprites |
| address | description | |
| 0xe074 | blob sprites The blob sprite is stored as a standard 3x2 graphic. |
|
| 0xe8b4 | laser sprite | |
| 0xadd4 | font | |
| 0xdf40 | blank graphic | |
| 0x6661 | border corners |
