Changes

'''''Renegade''''' is a 1987 game programmed published by Imagine. It was written by [[John Brandwood]] with graphics by [[Mark K Jones]].It is one of the same programmer as best CPC games. John also wrote [[Gryzor]] which is another top CPC game. 

 {||-|[Media:[Image:RenegadeLevel1.png|left|thumb|200px|Renegade Level 1]]|[Media:[Image:RenegadeLevel2.png|left|thumb|200px|Renegade Level 2]]|[Media:[Image:RenegadeLevel3.png|left|thumb|200px|Renegade Level 3]]|[Media:[Image:RenegadeLevel4.png|left|thumb|200px|Renegade Level 4]]|[[Image:Renegade_walk_anim.png|left|thumb|200px|Renegade Main Character Walk Animation frames]]|[[Image:Renegade_walk_anim_areas.png|left|thumb|200px|Renegade Main Character Walk Animation frames coloured by sprite part draw order]]|[[Image:Renegade_punch_anim.png|left|thumb|200px|Renegade Main Character Punch Animation frames]]|[[Image:Renegade_punch_anim_areas.png|left|thumb|200px|Renegade Main Character Punch Animation frames coloured by sprite part draw order]]<br style="clear:both;"/>|}

=== General ===* Sprites are stored upside down The game is designed to run in 64KB of memory.* Sprites are stored as mode 0 with pen 0 as transparent.* Sprites are flipped by code in realtime (e.gTherefore they made decisions to make this possible. Even so, the facing right sprite game is a flip one of the facing left sprite).best on CPC * Sprites With 64KB one level at a time is loaded. With 128KB all 4 levels are stored in multiple parts and are composed during drawingloaded. Each part has an x,y offset, width * The game doesn't use hardware scrolling and height based on uses a reduced screen and heavily uses the sprite's coordinates. Therefore heads, bodies invisible areas of both screens to store code and legs are separatedata. This allows re-use for all characters and enemies.* Sprites are stored as follows:

It is believed this is done so that drawing a * Characters and Enemies are stored as multiple sprite facing left, parts and are composed during drawing . Each part has a sprite facing right will take the same cpu time width, height, and so that signed x and y offset relative to the character's base x,y position. The base x,y position's origin is at the bottom of the frame rate will remain and in the middle on the x axis. There is no clear separation between heads, bodies and legs. Some character frames are made of 4 or more constantparts. This can be seen in the walk and punch animation frames.

* Supports 128K Characters and Enemies are sorted by their base y position each frame so that the draw correctly when walking in front of each other and to give a 3d look. === Sprites === * Sprite pixels are stored upside down in memory. Therefore left to right, bottom to top.* Sprite pixels are stored as mode 0 with pen 0 as transparent.* Sprite pixels 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.).* Sprite pixels are 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 storage is done so that drawing a sprite facing left, and drawing a sprite facing right will take the same cpu time and this means a more stable frame rate regardless of the direction each sprite is facing. * There is a list of sprites per level. The start address of this is stored at &e00 from the start of the level data. This takes the form of width, height and pixel data location. With 128KB there is 1 extra ram page per level for level specific sprites. Sprites common to each level are stored in main RAM. All levels There are loaded around 223 sprites (including common sprites). During the game the level page is mapped into RAM at once&4000.  === Levels ===* Each level has it's own music. * 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.* 2048 bytes for tile graphics. These are defined per-Each level's data is prefixed with "JCB Overlay xxxx" where x is the levelnumber. These are copied from &31e0 in 4 partse.g. There are "JCB Overlay 0000".* Map is 128 possible tileswide and 18 tiles tall. Runtime ranges: &e600-&e800But not all map space is used. The remainder is garbage. In reality, &ee00-&f000Level 1, &f600-&f8002, &fe00-&ffff.* Tiles 3 are 80 tiles wide. Level 4 pixels is 112 tiles wide and 8 pixels tall. * Each tilelevel has it's graphics uses own palette of 16 bytescolours. Tiles are 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 uncompressedbackwards with pen 15 first, left-right and top then 14 all the way down to bottom0.* "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. Macro The data is copied to &BF90 and this is where the runtime uses it from.* The tile mapids per macro block are stored at offset +0x09e0 from the start of the level's runtime location data. The data is at encoded as 7 bits per tile all put together. It is decoded to &BF9031a0 overwriting the level data. Data at 9600 defines actual tiles This is copied to use&9600-&9720,&9e00-&9f20,&a600-&a720,&ae00-&af20. The runtime uses the data from &9600. The ids are stored pre-multiplied by 2.

=== Tiles ===* Map is 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 wide and 18 tiles tall, but not all map space is used. Level 1Runtime ranges: &e600-&e800,2&ee00-&f000,3 are 80 tiles wide&f600-&f800, &fe00-&ffff. Level * Tile graphics are 4 is 112 tiles pixels wideand 8 pixels tall. Each tile's graphics uses 16 bytes. Tiles are stored uncompressed, left-right and top to bottom.