Difference between revisions of "Renegade"
From CPCWiki - THE Amstrad CPC encyclopedia!
(→Technical) |
(→Technical) |
||
| Line 14: | Line 14: | ||
== Technical == | == Technical == | ||
| + | |||
| + | === General === | ||
| + | * The game is designed to run in 64KB of memory. Therefore they made decisions to make this possible. Even so, the game is one of the best on CPC | ||
| + | * With 64KB one level at a time is loaded. With 128KB all 4 levels are loaded. | ||
| + | * The game doesn't use hardware scrolling and uses a reduced screen and heavily uses the invisible areas of both screens to store code and data. | ||
| + | |||
| + | === Sprites === | ||
* Sprites are stored upside down in memory. | * Sprites are stored upside down in memory. | ||
* Sprites are stored as mode 0 with pen 0 as transparent. | * Sprites are stored as mode 0 with pen 0 as transparent. | ||
| − | * Sprites are flipped by code in realtime (e.g. the facing | + | * Sprites are stored facing right only and flipped by code in realtime (e.g. the facing left sprite is a mirror of the facing right sprite.). |
| − | * | + | * Characters are stored as multiple sprite parts and are composed during drawing. Each part has a signed x and y offset relative to the base x,y position of the feet on screen and a width and height. Therefore heads, bodies and legs are separate. This allows re-use for all characters and enemies. |
| − | * | + | * Sprite pixel data is stored as follows: |
| − | 1 byte normal ( | + | 1 byte like normal (same as mode 0 screen bytes), followed by 1 byte with pixels swapped, this repeats. |
| − | It is believed this is done so that drawing a sprite facing left, and drawing a sprite facing right will take the same cpu time and so that the frame rate | + | It is believed this is done so that drawing a sprite facing left, and drawing a sprite facing right will take the same cpu time and so that the frame rate is more consistent. |
| − | * | + | * Characters are sorted by their y position each frame. They are then draw in increasing y coordinate order. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | * | + | === Levels === |
| − | * | + | * Each level takes &1000 bytes. There are 4 stored in 1 16KB page. The data is copied to &3000->&3fff before then being copied to other locations in RAM. |
| + | * Each level's data is prefixed with "JCB Overlay xxxx" where x is the level number. e.g. "JCB Overlay 0000". | ||
| + | * Map is 128 tiles wide and 18 tiles tall. But not all map space is used. The remainder is garbage. In reality, Level 1,2,3 are 80 tiles wide. Level 4 is 112 tiles wide. | ||
| + | * Each level has it's own palette of 16 colours. The palette for level 1 is at &87b3, level 2 is &87c3, level 3 is &87d3, level 4 is at &87e3. The palette is stored backwards with pen 15 first, then 14 all the way down to 0. | ||
| + | * "Macro tile map" uses 64 bytes. It is stored at offset +0x01a0 from the start of the level's data. Each byte is a macro tile id. Each macro tile is 4 tiles wide and 9 tiles tall. The data is copied to &BF90 and this is where the runtime uses it from. | ||
| + | * The tile ids per macro block are stored at offset +0x09e0 from the start of the level's data. The data is encoded as 7 bits per tile all put together. It is decoded to &31a0 overwriting the level data. This is copied to &9600-&9720,&9e00-&9f20,&a600-&a720,&ae00-&af20. The runtime uses the data from &9600. The ids are stored pre-multiplied by 2. | ||
| − | |||
| − | * | + | === Tiles === |
| + | * 2048 bytes for tile graphics. These are defined per-level. These are stored at +&1e0 from the level data. They are copied from &31e0 in 4 parts. There are 128 possible tiles. Runtime ranges: &e600-&e800, &ee00-&f000, &f600-&f800, &fe00-&ffff. | ||
| + | * Tile graphics are 4 pixels wide and 8 pixels tall. Each tile's graphics uses 16 bytes. Tiles are stored uncompressed, left-right and top to bottom. | ||
| + | |||
| + | === Sprites === | ||
| + | * Sprites for all levels are loaded at once and use ~13KB. They are located at &4a80-&7fff in main ram. | ||
== Video == | == Video == | ||
Revision as of 08:33, 17 February 2019
Renegade is a 1987 game programmed by the same programmer as Gryzor.
Contents
Pictures
|
|
Technical
General
- The game is designed to run in 64KB of memory. Therefore they made decisions to make this possible. Even so, the game is one of the best on CPC
- With 64KB one level at a time is loaded. With 128KB all 4 levels are loaded.
- The game doesn't use hardware scrolling and uses a reduced screen and heavily uses the invisible areas of both screens to store code and data.
Sprites
- Sprites are stored upside down in memory.
- Sprites are stored as mode 0 with pen 0 as transparent.
- Sprites are stored facing right only and flipped by code in realtime (e.g. the facing left sprite is a mirror of the facing right sprite.).
- Characters are stored as multiple sprite parts and are composed during drawing. Each part has a signed x and y offset relative to the base x,y position of the feet on screen and a width and height. Therefore heads, bodies and legs are separate. This allows re-use for all characters and enemies.
- Sprite pixel data is stored as follows:
1 byte like normal (same as mode 0 screen bytes), followed by 1 byte with pixels swapped, this repeats.
It is believed this is done so that drawing a sprite facing left, and drawing a sprite facing right will take the same cpu time and so that the frame rate is more consistent.
- Characters are sorted by their y position each frame. They are then draw in increasing y coordinate order.
Levels
- Each level takes &1000 bytes. There are 4 stored in 1 16KB page. The data is copied to &3000->&3fff before then being copied to other locations in RAM.
- Each level's data is prefixed with "JCB Overlay xxxx" where x is the level number. e.g. "JCB Overlay 0000".
- Map is 128 tiles wide and 18 tiles tall. But not all map space is used. The remainder is garbage. In reality, Level 1,2,3 are 80 tiles wide. Level 4 is 112 tiles wide.
- Each level has it's own palette of 16 colours. The palette for level 1 is at &87b3, level 2 is &87c3, level 3 is &87d3, level 4 is at &87e3. The palette is stored backwards with pen 15 first, then 14 all the way down to 0.
- "Macro tile map" uses 64 bytes. It is stored at offset +0x01a0 from the start of the level's data. Each byte is a macro tile id. Each macro tile is 4 tiles wide and 9 tiles tall. The data is copied to &BF90 and this is where the runtime uses it from.
- The tile ids per macro block are stored at offset +0x09e0 from the start of the level's data. The data is encoded as 7 bits per tile all put together. It is decoded to &31a0 overwriting the level data. This is copied to &9600-&9720,&9e00-&9f20,&a600-&a720,&ae00-&af20. The runtime uses the data from &9600. The ids are stored pre-multiplied by 2.
Tiles
- 2048 bytes for tile graphics. These are defined per-level. These are stored at +&1e0 from the level data. They are copied from &31e0 in 4 parts. There are 128 possible tiles. Runtime ranges: &e600-&e800, &ee00-&f000, &f600-&f800, &fe00-&ffff.
- Tile graphics are 4 pixels wide and 8 pixels tall. Each tile's graphics uses 16 bytes. Tiles are stored uncompressed, left-right and top to bottom.
Sprites
- Sprites for all levels are loaded at once and use ~13KB. They are located at &4a80-&7fff in main ram.
Video
{{#ev:youtube|Fc8GDlw2nys|450}}
