Maptapper Tutorial Part 1 - Introduction & The Basics

CodyJarrett · 24 June 2013, 09:23

Here's the first part of my tutorial about using Codetapper's new tool Maptapper to create maps. This part is intended to introduce the beginner to some concepts. Corrections and comments are welcome!

Introduction

Hint - This section may be skipped if you are comfortable with the basics. You can go directly to Maptapper Tutorial Part 2 - Kid Gloves II

In Amiga games with 2D scrolling, such as Turrican, R-Type, Alien Breed or Ultima VI, the visible play area is but a small section of the overall level. The player may have a general idea of the level layout but usually won't see the whole level map in its entirety, unless the game features some sort of crude radar or a magic item that reveals it. If we want to see the whole map there are several ways to do it.

One method of producing maps is to capture screenshots during gameplay and to paste them all together. There is a site called The Video Game Atlas (http://www.vgmaps.com) which uses this method for mostly non-Amiga systems. Computer magazines used this approach to create level maps for game guides. However, there are significant drawbacks to this approach:

It's a tedious and lengthy process.
Screenshots include the player and enemy characters as well as special effects such as bullets, which need to be removed.
Amiga games often have multiple layers of parallax scrolling backgrounds which move at a different speed to the foreground, which causes difficulties in stitching screenshots together.
Some parts of levels aren't accessible in normal gameplay although sometimes they may be reached with a cheat.
There may be invisible elements in the map which aren't displayed, such as enemy generators or bonus producing areas.

Most of the Hall of Light (http://hol.abime.net) website level maps have been created using a different method, which can be summarised as:

Find the level map tiles
Find the level map data
Reconstruct the level using the tiles and the data

In effect, this is mimicking how games show their levels. However, where a game will display only the telescopic screen-sized view we will instead display the whole level.

How Game Maps Work

If Amiga developers had tried to store an entire Turrican level (level 1 is 4384x1632 pixels in size, for example) as a single graphical element it wouldn't have fitted on a 880K Amiga floppy disk or in the Amiga's RAM. The solution used by most games is to store a set of tiles and to build a map by referring to each tile. Tiles can be reused many times. On the Amiga individual tiles are most commonly 16 pixels wide and 16 pixels high so a set of 256 tiles represents a big saving in space over storing a map as a single picture.

If each tile is assigned a number (00, 01, 02, 03, 04, 05 etc.) then a game can build a map by referencing each tile by this number and storing it in memory as level data.

00 00 00 02 04 00 00 01 02...

To reconstruct a level map we have to combine the tiles and the data. In order to do this it's necessary to understand some fundamentals of computing.

Counting Systems

Let's go back to the basics. We use a counting system called decimal which has 10 digits, like the 10 digits of our hands.

0 1 2 3 4 5 6 7 8 9

After we count from 0 to 9 we run out of digits and so have to add another digit to the left side and so on:

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 etc.

Another counting system, called hexadecimal (or just hex), works in a similar way except that there are 16 digits:

0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F

As with decimal, we reuse digits when we run out. Here's a sequence of hex numbers with the decimal equivalents for comparison:

Hex: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C etc.
Dec: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 etc.

So, hex 10 is actually equivalent to decimal 16.

A further numbering system is called binary and it uses just two digits:

0 1

Even though there are only two digits, the counting system works in a similar way to decimal and hexadecimal:

Bin: 0000 0001 0010 0011 0100 0101 0110 0111 1000 etc.
Hex: 0000 0001 0002 0003 0004 0005 0006 0007 0008 etc.
Dec: 0000 0001 0002 0003 0004 0005 0006 0007 0008 etc.

Computer Storage Basics

Certain names are given to groups of bits:

A bit is a single Binary digIT: 0 or 1
8 bits are called a byte
16 bits are called a word
32 bits are called a long word

1024 bytes form a kilobyte
1024 kilobytes form a megabyte
1024 megabytes form a gigabyte and so on.

It is more convenient to talk about a byte rather than individual bits. How are bytes stored in the Amiga's RAM? When you look at the Amiga's memory in a debugger (WinUAE's, for example) you'll see something like this:

00012345 0A02 01FE 1A2C 4D1F 0000 0000 00FD FEFF
00012355 01A2 3334 0000 0000 0000 DAD2 555F 0000

Hint - to access WinUAE's debugger use Shift+F12

This is a view of the Amiga's memory which shows the values at certain addresses. Each byte is stored in a container which is referenced by an address. The number at the start (e.g. 00012345) is the memory address of the first value in the row - the first two digits.

The memory address 12345 contains the value hex 0A, which is decimal 10 and binary 00001010.

This memory address can hold a maximum value of hex FF, decimal 255 or binary 11111111. Since 11111111 is an eight bit number the address holds a byte of data.

What happens if a larger number than decimal 255, such as a game score, needs to be stored? The preceding addresses are used. For example hex 0F0A would use two bytes and store a decimal value of 3850.

Amiga Displays

A computer display is made up of individual pixels, each of which can have a specific colour. A two colour display needs only two numbers to record each possible colour in memory; 0 and 1, where 0 might represent black and 1 might represent white (or any other two colours).

For two colours, only 1 bit of memory is required to store each pixel's colour. The more colours that are used the more memory is required for each pixel. For example, 16 colours can be stored in 4 bits: binary 0000 (decimal 0) to binary 1111 (decimal 15). 256 colours could be stored in 8 bits (1 byte): binary 00000000 (decimal 0) to 11111111 (decimal 255).

How are graphics stored in memory? One possible graphical storage system would be to store the value (colour) of each pixel sequentially. For example, in order to store an image with up to 256 colours the following values could be placed in each consecutive memory address:

00000000 (colour no. 0) 10010000 (colour no. 144) 00010110 (colour no. 22) 00010110 (colour no. 22)
etc.

In the above examples there are four pixels with colours 0, 144, 22 and 22. This is a "Chunky" graphics system and is the method used by the Doom-era PC.

The Amiga uses a different system; "Planar" graphics. The bits for each pixel are displayed in different locations ("bitplanes") in memory and must be combined in order to find the colour of a pixel that is to be displayed. For example, an eight colour Planar system would use the following bytes:

Bitplane 1 - 0 0 1 1
Bitplane 2 - 1 1 0 0
Bitplane 3 - 0 1 1 1
Bitplane 4 - 0 0 0 0

To find the colour of the first pixel above you have to read all four bits in the first column so that all four bits in each bitplane are read. The pixel colours are therefore 0100, 0110, 1010, 1010

In the Chunky system each colour is displayed one after the other. In the Planar system each Bitplane row is stored at a different location in memory. In order to find the first colour the Chunky system needs only to make one read operation: 0100. The Planar system needs to go to bitplane 1 then read 0, go to bitplane 2 then read 1, go to bitplane 3 then read 0 and finally to bitplane 4 and read 0.

A 256 colour display would need eight reads since eight bits are required to store up to 256 numbers e.g. this is one pixel:

Bitplane 1 0...
Bitplane 2 0...
Bitplane 3 1...
Bitplane 4 0...
Bitplane 5 0...
Bitplane 6 1...
Bitplane 7 0...
Bitplane 8 0...

The Chunky system is clearly faster than Planar since only one memory read is required per pixel rather than up to 8 reads. This is one reason why Doom clones on the Amiga are quite slow compared to the PC.

Planar, on the other hand, is supposedly better for scrolling, parallax type games. Less memory is also used by the Planar system to display low numbers of colours. This is because it doesn't require a full memory address for a small number. For example, a sixteen colour Planar pixel needs 4 bits whereas Chunky would probably use the whole byte (8 bits).

In order to work out how many colours can be displayed using the Amiga’s bitplanes the calculation is:

2 to the power of y where y is the number of bitplanes

Bitplanes
1 = 2 colours
2 = 4 colours
3 = 8 colours
4 = 16 colours
5 = 32 colours
6 = 64 colours
7 = 128 colours
8 = 256 colours

The number of bitplanes most commonly used on the Amiga are 4 (16 colours), 5 (32 colours) and 8 (256 colours e.g. AGA).

24 June 2013, 09:23	#1
CodyJarrett Global Moderator Join Date: Mar 2001 Location: UK Age: 46 Posts: 6,160	Maptapper Tutorial Part 1 - Introduction & The Basics Here's the first part of my tutorial about using Codetapper's new tool Maptapper to create maps. This part is intended to introduce the beginner to some concepts. Corrections and comments are welcome! Introduction Hint - This section may be skipped if you are comfortable with the basics. You can go directly to Maptapper Tutorial Part 2 - Kid Gloves II In Amiga games with 2D scrolling, such as Turrican, R-Type, Alien Breed or Ultima VI, the visible play area is but a small section of the overall level. The player may have a general idea of the level layout but usually won't see the whole level map in its entirety, unless the game features some sort of crude radar or a magic item that reveals it. If we want to see the whole map there are several ways to do it. One method of producing maps is to capture screenshots during gameplay and to paste them all together. There is a site called The Video Game Atlas (http://www.vgmaps.com) which uses this method for mostly non-Amiga systems. Computer magazines used this approach to create level maps for game guides. However, there are significant drawbacks to this approach: It's a tedious and lengthy process. Screenshots include the player and enemy characters as well as special effects such as bullets, which need to be removed. Amiga games often have multiple layers of parallax scrolling backgrounds which move at a different speed to the foreground, which causes difficulties in stitching screenshots together. Some parts of levels aren't accessible in normal gameplay although sometimes they may be reached with a cheat. There may be invisible elements in the map which aren't displayed, such as enemy generators or bonus producing areas. Most of the Hall of Light (http://hol.abime.net) website level maps have been created using a different method, which can be summarised as: Find the level map tiles Find the level map data Reconstruct the level using the tiles and the data In effect, this is mimicking how games show their levels. However, where a game will display only the telescopic screen-sized view we will instead display the whole level. How Game Maps Work If Amiga developers had tried to store an entire Turrican level (level 1 is 4384x1632 pixels in size, for example) as a single graphical element it wouldn't have fitted on a 880K Amiga floppy disk or in the Amiga's RAM. The solution used by most games is to store a set of tiles and to build a map by referring to each tile. Tiles can be reused many times. On the Amiga individual tiles are most commonly 16 pixels wide and 16 pixels high so a set of 256 tiles represents a big saving in space over storing a map as a single picture. If each tile is assigned a number (00, 01, 02, 03, 04, 05 etc.) then a game can build a map by referencing each tile by this number and storing it in memory as level data. 00 00 00 02 04 00 00 01 02... To reconstruct a level map we have to combine the tiles and the data. In order to do this it's necessary to understand some fundamentals of computing. Counting Systems Let's go back to the basics. We use a counting system called decimal which has 10 digits, like the 10 digits of our hands. 0 1 2 3 4 5 6 7 8 9 After we count from 0 to 9 we run out of digits and so have to add another digit to the left side and so on: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 etc. Another counting system, called hexadecimal (or just hex), works in a similar way except that there are 16 digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F As with decimal, we reuse digits when we run out. Here's a sequence of hex numbers with the decimal equivalents for comparison: Hex: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C etc. Dec: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 etc. So, hex 10 is actually equivalent to decimal 16. A further numbering system is called binary and it uses just two digits: 0 1 Even though there are only two digits, the counting system works in a similar way to decimal and hexadecimal: Bin: 0000 0001 0010 0011 0100 0101 0110 0111 1000 etc. Hex: 0000 0001 0002 0003 0004 0005 0006 0007 0008 etc. Dec: 0000 0001 0002 0003 0004 0005 0006 0007 0008 etc. Computer Storage Basics Certain names are given to groups of bits: A bit is a single Binary digIT: 0 or 1 8 bits are called a byte 16 bits are called a word 32 bits are called a long word 1024 bytes form a kilobyte 1024 kilobytes form a megabyte 1024 megabytes form a gigabyte and so on. It is more convenient to talk about a byte rather than individual bits. How are bytes stored in the Amiga's RAM? When you look at the Amiga's memory in a debugger (WinUAE's, for example) you'll see something like this: 00012345 0A02 01FE 1A2C 4D1F 0000 0000 00FD FEFF 00012355 01A2 3334 0000 0000 0000 DAD2 555F 0000 Hint - to access WinUAE's debugger use Shift+F12 This is a view of the Amiga's memory which shows the values at certain addresses. Each byte is stored in a container which is referenced by an address. The number at the start (e.g. 00012345) is the memory address of the first value in the row - the first two digits. The memory address 12345 contains the value hex 0A, which is decimal 10 and binary 00001010. This memory address can hold a maximum value of hex FF, decimal 255 or binary 11111111. Since 11111111 is an eight bit number the address holds a byte of data. What happens if a larger number than decimal 255, such as a game score, needs to be stored? The preceding addresses are used. For example hex 0F0A would use two bytes and store a decimal value of 3850. Amiga Displays A computer display is made up of individual pixels, each of which can have a specific colour. A two colour display needs only two numbers to record each possible colour in memory; 0 and 1, where 0 might represent black and 1 might represent white (or any other two colours). For two colours, only 1 bit of memory is required to store each pixel's colour. The more colours that are used the more memory is required for each pixel. For example, 16 colours can be stored in 4 bits: binary 0000 (decimal 0) to binary 1111 (decimal 15). 256 colours could be stored in 8 bits (1 byte): binary 00000000 (decimal 0) to 11111111 (decimal 255). How are graphics stored in memory? One possible graphical storage system would be to store the value (colour) of each pixel sequentially. For example, in order to store an image with up to 256 colours the following values could be placed in each consecutive memory address: 00000000 (colour no. 0) 10010000 (colour no. 144) 00010110 (colour no. 22) 00010110 (colour no. 22) etc. In the above examples there are four pixels with colours 0, 144, 22 and 22. This is a "Chunky" graphics system and is the method used by the Doom-era PC. The Amiga uses a different system; "Planar" graphics. The bits for each pixel are displayed in different locations ("bitplanes") in memory and must be combined in order to find the colour of a pixel that is to be displayed. For example, an eight colour Planar system would use the following bytes: Bitplane 1 - 0 0 1 1 Bitplane 2 - 1 1 0 0 Bitplane 3 - 0 1 1 1 Bitplane 4 - 0 0 0 0 To find the colour of the first pixel above you have to read all four bits in the first column so that all four bits in each bitplane are read. The pixel colours are therefore 0100, 0110, 1010, 1010 In the Chunky system each colour is displayed one after the other. In the Planar system each Bitplane row is stored at a different location in memory. In order to find the first colour the Chunky system needs only to make one read operation: 0100. The Planar system needs to go to bitplane 1 then read 0, go to bitplane 2 then read 1, go to bitplane 3 then read 0 and finally to bitplane 4 and read 0. A 256 colour display would need eight reads since eight bits are required to store up to 256 numbers e.g. this is one pixel: Bitplane 1 0... Bitplane 2 0... Bitplane 3 1... Bitplane 4 0... Bitplane 5 0... Bitplane 6 1... Bitplane 7 0... Bitplane 8 0... The Chunky system is clearly faster than Planar since only one memory read is required per pixel rather than up to 8 reads. This is one reason why Doom clones on the Amiga are quite slow compared to the PC. Planar, on the other hand, is supposedly better for scrolling, parallax type games. Less memory is also used by the Planar system to display low numbers of colours. This is because it doesn't require a full memory address for a small number. For example, a sixteen colour Planar pixel needs 4 bits whereas Chunky would probably use the whole byte (8 bits). In order to work out how many colours can be displayed using the Amiga’s bitplanes the calculation is: 2 to the power of y where y is the number of bitplanes Bitplanes 1 = 2 colours 2 = 4 colours 3 = 8 colours 4 = 16 colours 5 = 32 colours 6 = 64 colours 7 = 128 colours 8 = 256 colours The number of bitplanes most commonly used on the Amiga are 4 (16 colours), 5 (32 colours) and 8 (256 colours e.g. AGA). Last edited by CodyJarrett; 06 December 2014 at 11:27.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
List the Maptapper rips you are working on	Codetapper	project.Maptapper	22	25 February 2017 23:26
Maptapper released!	Codetapper	project.Maptapper	73	02 June 2016 16:23
Maptapper Tutorial Part 2 - Kid Gloves II	CodyJarrett	project.Maptapper	15	25 June 2013 03:22
Confused with part of Flashtro tutorial	MethodGit	Coders. General	36	11 November 2010 04:09
some basics	diamond	request.UAE Wishlist	1	26 March 2005 03:03

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)