Renegade - Revision history

Arnoldemu at 08:52, 18 February 2019

2019-02-18T08:52:19Z

← Older revision		Revision as of 08:52, 18 February 2019
Line 15:		Line 15:
	\|[[Image:RenegadeLevel4.png\|left\|thumb\|200px\|Renegade Level 4]]		\|[[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.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]]		\|[[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.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]]		\|[[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;"/>		<br style="clear:both;"/>
	\|}		\|}

Arnoldemu at 08:51, 18 February 2019

2019-02-18T08:51:26Z

← Older revision		Revision as of 08:51, 18 February 2019
Line 1:		Line 1:
	'''''Renegade''''' is a 1987 game published by Imagine, written by [[John Brandwood]] ~~who~~ is the ~~same programmer as~~ [[Gryzor]].		'''''Renegade''''' is a 1987 game published by Imagine. It was written by [[John Brandwood]] with graphics by [[Mark K Jones]].
			It is one of the best CPC games.

			John also wrote [[Gryzor]] which is another top CPC game.

	~~Renegade is one of the best CPC games.~~

	== Pictures ==		== Pictures ==
Line 26:		Line 28:
	* 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.		* 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.

	=== Characters ===		=== Characters and Enemies ===

	* 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~~. There is no clear separation between heads, bodies and legs.		* Characters and Enemies are stored as multiple sprite parts and are composed during drawing. Each part has a width, height, and 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 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 parts. This can be seen in the walk and punch animation frames.

	* Characters are sorted by their y position each frame~~. They are then~~ draw in ~~increasing y coordinate order~~.		* 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 ===		=== Sprites ===

	* Sprite pixels are stored upside down in memory.		* 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 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 facing right only and flipped by code in realtime (e.g. the facing left sprite is a mirror of the facing right sprite.).
Line 59:		Line 61:
	* 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.		* 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.		* 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 ==

Arnoldemu at 08:45, 18 February 2019

2019-02-18T08:45:34Z

← Older revision		Revision as of 08:45, 18 February 2019
Line 1:		Line 1:
	'''''Renegade''''' is a 1987 game published by Imagine, written by [[John Brandwood]] who is the same programmer as [[Gryzor]].		'''''Renegade''''' is a 1987 game published by Imagine, written by [[John Brandwood]] who is the same programmer as [[Gryzor]].

	It is ~~considered~~ one of the best CPC games ~~and the best version out of the CPC, C64 and Spectrum~~.		Renegade is one of the best CPC games.

	== Pictures ==		== Pictures ==

Arnoldemu at 08:44, 18 February 2019

2019-02-18T08:44:54Z

← Older revision		Revision as of 08:44, 18 February 2019
Line 1:		Line 1:
	'''''Renegade''''' is a 1987 game ~~programmed~~ by the same programmer as Gryzor.		'''''Renegade''''' is a 1987 game published by Imagine, written by [[John Brandwood]] who is the same programmer as [[Gryzor]].

			It is considered one of the best CPC games and the best version out of the CPC, C64 and Spectrum.

	== Pictures ==		== Pictures ==
Line 44:		Line 46:

	=== Levels ===		=== 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.		* 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".		* Each level's data is prefixed with "JCB Overlay xxxx" where x is the level number. e.g. "JCB Overlay 0000".

Arnoldemu at 08:42, 18 February 2019

2019-02-18T08:42:44Z

← Older revision		Revision as of 08:42, 18 February 2019
Line 12:		Line 12:
	\|[[Image:Renegade_walk_anim.png\|left\|thumb\|200px\|Renegade Main Character Walk Animation frames]]		\|[[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]]		\|[[Image:Renegade_walk_anim_areas.png\|left\|thumb\|200px\|Renegade Main Character Walk Animation frames coloured by sprite part]]
			\|[[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]]
	<br style="clear:both;"/>		<br style="clear:both;"/>
	\|}		\|}

Arnoldemu: /* Pictures */

2019-02-18T08:40:32Z

Pictures

← Older revision		Revision as of 08:40, 18 February 2019
Line 10:		Line 10:
	\|[[Image:RenegadeLevel3.png\|left\|thumb\|200px\|Renegade Level 3]]		\|[[Image:RenegadeLevel3.png\|left\|thumb\|200px\|Renegade Level 3]]
	\|[[Image:RenegadeLevel4.png\|left\|thumb\|200px\|Renegade Level 4]]		\|[[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]]
	<br style="clear:both;"/>		<br style="clear:both;"/>
	\|}		\|}

Arnoldemu: /* Sprites */

2019-02-17T17:05:24Z

Sprites

← Older revision		Revision as of 17:05, 17 February 2019
Line 37:		Line 37:
	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.		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. 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. There are around 223 sprites (including common sprites).		* 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. There are around 223 sprites (including common sprites). During the game the level page is mapped into RAM at &4000.

	=== Levels ===		=== Levels ===

Arnoldemu: /* Sprites */

2019-02-17T17:03:34Z

Sprites

← Older revision		Revision as of 17:03, 17 February 2019
Line 19:		Line 19:
	* With 64KB one level at a time is loaded. With 128KB all 4 levels are loaded.		* 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.		* 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.

			=== Characters ===

			* 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. There is no clear separation between heads, bodies and legs.

			* Characters are sorted by their y position each frame. They are then draw in increasing y coordinate order.

	=== Sprites ===		=== Sprites ===

	* ~~Sprites~~ are stored upside down in memory.		* Sprite pixels are stored upside down in memory.
	* ~~Sprites~~ are stored as mode 0 with pen 0 as transparent.		* Sprite pixels 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.).		* 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.).
	* 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 pixels are stored as follows:
	* 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.		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~~.		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.

	* ~~Characters~~ are ~~sorted by their y position each frame~~. ~~They~~ are ~~then draw in increasing y coordinate order~~.		* There is a list of sprites per level. 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. There are around 223 sprites (including common sprites).

	=== Levels ===		=== Levels ===

Arnoldemu: /* Technical */

2019-02-17T12:33:37Z

Technical

← Older revision		Revision as of 12:33, 17 February 2019
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 ~~right~~ sprite is a ~~flip~~ of the facing ~~left~~ sprite).		* 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.).
	* ~~Sprites~~ are stored in multiple parts and are composed during drawing. Each part has an x,y offset, width and height ~~based on the sprite's coordinates~~. Therefore heads, bodies and legs are separate. This allows re-use for all characters and enemies.		* 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.
	* ~~Sprites are~~ stored as follows:		* Sprite pixel data is stored as follows:

	1 byte normal (~~to write to~~ mode 0 screen), followed by 1 byte with pixels swapped, ~~then~~ this repeats.		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 ~~will remain~~ more ~~constant~~.		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.

	* ~~Supports 128K RAM~~. ~~All levels~~ are ~~loaded at once~~. Each level takes &1000 bytes. There are 4 stored in 1 16KB page.		* Characters are sorted by their y position each frame. They are then draw in increasing y coordinate order.
	* ~~2048 bytes for tile graphics~~. ~~These are defined per-level~~. ~~These are copied from &31e0 in 4 parts~~. ~~There are~~ 128 ~~possible~~ tiles. ~~Runtime ranges: &e600-&e800~~, ~~&ee00-&f000~~, ~~&f600-&f800~~, ~~&fe00-&ffff~~.
	* Tiles 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~~.		=== Levels ===
	* "Macro tile map" uses 64 bytes. Each byte is 4 tiles wide and 9 tiles tall. ~~Macro~~ tile ~~map~~'s ~~runtime location~~ is at &~~BF90~~. ~~Data at~~ 9600 ~~defines actual tiles to use~~.		* 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.

	* Sprites for all levels are loaded at once and use ~13KB. They are located at &4a80-&7fff in main ram.
	* 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.

	* ~~Map is~~ 128 tiles ~~wide and 18 tiles tall, but not all map width is used. The remainder is garbage~~. ~~In reality~~, ~~Level 1~~,2,3 are ~~80 tiles~~ wide. ~~Level 4 is 112 tiles wide~~.		=== 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.

	* ~~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, down to 0~~.		=== Sprites ===
			* Sprites for all levels are loaded at once and use ~13KB. They are located at &4a80-&7fff in main ram.

	== Video ==		== Video ==

Arnoldemu: /* Technical */

2019-02-16T18:13:20Z

Technical

← Older revision		Revision as of 18:13, 16 February 2019
Line 33:		Line 33:
	* 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.		* 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.

	* Map is 128 tiles wide and 18 tiles tall, but not all map ~~space~~ is used. Level 1,2,3 are 80 tiles wide. Level 4 is 112 tiles wide.		* Map is 128 tiles wide and 18 tiles tall, but not all map width 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, down to 0.

	== Video ==		== Video ==

← Older revision		Revision as of 08:52, 18 February 2019
Line 15:		Line 15:
	\|[[Image:RenegadeLevel4.png\|left\|thumb\|200px\|Renegade Level 4]]		\|[[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.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]]		\|[[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.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]]		\|[[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;"/>		<br style="clear:both;"/>
	\|}		\|}