Displaying A TileMap

In this article we will take a closer look at one of the included sources examples and examine what it does.

Open the source folders and go into the “Chicken” folder and load the “Tiles.bas”

#include <nextlib.bas>			
NextReg($7,2)				

BORDER 1				

dim maploadaddress as uinteger=64256	
DIM x as ubyte=0

CLS256(0)																	



' Load SD filename, load address, lengthm, offset 

LoadSD("tiles.spr",$C000,$4000,0)
LoadSD("level1.bin",maploadaddress,768,0)

border 6



TileMap(maploadaddress,0,768,0,0,32,1)	

BORDER 0		
pause 0

Let’s examine the lines :
```
#include <nextlib.bas>
NextReg($7,2)

BORDER 1
```
Line 1 instructs that we include the nextlib; line 2 that we set Next Register 7 which is the peripheral register and a setting of 2 switches the Next to 14mhz.
Line 4 sets the border to blue, why not. Actually using the border for debugging is super helpful. If you have code that is crashing you can use border changes to see what parts are running and which are not. Anyway we continue.

The following two lines define some variables. maploadaddress is defined as an unsigned integer (0-65535) and set to 64256 – we will use this to load our map into.
We also define x as an unsigned byte (0-255) and make it zero. Always make sure you define your variables as this has a can have a big impact on speed. For instance, why have x as a uinteger when it only needs to count up a few numbers?
```
DIM maploadaddress as uinteger=64256
DIM x as ubyte=0
```
The next line clears the Layer2 256 colour screen with a colour – well rather a palette index, 0 happens to be black on boot up.
```
CLS256(0)
```
The next two lines load code from the SD card in the current folder. In NextBuild this is simulated inside the data folder of the source directory. So if you want to load anything while running, make sure you place them in the data folder.
```
LoadSD("tiles.spr",$C000,$4000,0)
LoadSD("level1.bin",maploadaddress,768,0)
```
Line 15 loads “tiles.spr” to address $c000 for a length of $4000 at a file offset of 0. In human terms we are loading 16kb to 49152. We then load the “level1.bin” to maploadaddress which we defined earlier, and we load 768 bytes at 0 file offset. Easy so far.

We will ignore the border and go to line 22
```
TileMap(maploadaddress,0,768,0,0,32,1)
```
This is the one that does the magic. TileMap will always look at $c000 for its tile bitmap data so we send the following arguments.

sub TileMap(byval address as uinteger, byval blkoff as ubyte, byval numberoftiles as uinteger,byval x as ubyte,byval y as ubyte, byval width as ubyte, byval mapwidth as uinteger)

mapadaddress (as that is where or map data is),
0 is the block offset we want to draw from
768 is the amount of blocks we will draw to screen, 768 being a full 32×24
0 is the X start
0 is the Y start, so top left
32 is the width of box we will draw with tiles
1 is the mapwidth, 1 mapwidth is 32 tiles – this will become useful if you have a two screen map but for now we only need 1.

And that’s it! The map is displayed. We also have the tile in ram to do collision against.
We can take a look at the structure of the level1.bin tilemap in a hexeditor:
We can see the outline of our map!

Now one could think that I did that by hand but that isn’t the case. I hate doing repetitive tasks that can be done with code, my old IT teacher used to say “Don’t work on computers, make them work for you!”. So with that in mind I wrote a small conversion tool that not only would it make the map data but also the block data that I can use for the tiles.

I drew some basic blocks in an art package then imported them into “Tiled”, once in there I draw a basic map :

Once I had drawn the map, I did an export as image and saved a png. I then used my own tool to load the image I had just exported. It looks through the image and stores unique blocks and removes any duplicates, spits of mapdata and image data:

Importer, red squares indicate the first time it sees that block.

So as you can see on the left is what we saw in the hexeditor number wise (well actually its a bit different because I couldn’t find the exact sources while writing this but it’s close enough) and on the right the block data we need. I click the “Save” icon and it spits our level.bin and level.spr, this is ready to use with the TileMap command in NextBuild. Told you it was easy!

We also have the mapdata in ram at the mapadaddress we can use for collision detection.

Hope that helps! 🙂