SNES programming tutorial. Example 9.
This time we are going to make a collision map, and make a sprite collide with the background. The actual graphics are not that important.
I took some pictures of some blocks (and a sketch of a cube with eyes) and Photoshopped them (GIMP) into 16×16 sized PNG (indexed 16 colors) and converted them to SNES .chr files with Superfamiconv. Actually, I expanded them to 32×16, with the left just filled with black. I thought that would give us a consistent zero index color of black, and it seems to have worked. Then I loaded everything into my M1TE tool.
I made the BG map in M1TE. It would have been nice if it supported 16×16 tiles, (all of our blocks are 16×16) but I didn’t program in 16×16 tile mode yet. I can load this into the game, no problem, but there is no easy way to make a collision map out of this. I could type one by hand. It would be an array of numbers 16×14 (224 total). Zero for blank, 1 for wall. Each number would represent a 16×16 square area of the screen.
This time I used Tiled Map Editor to make a collision map. I loaded a picture of my 3 tiles as the tileset (see right side), and recreated the BG map that I had made in M1TE. The entire purpose of this is to export a .csv file of our collision map… which is that collision array I was talking about.
The CSV file exported from Tiled.
I added some .byte directives so it can be loaded as a byte array into the asm code. 0 is blank, 1 is red wall, 2 is the yellow square. Maybe in the future I will program some clever app or tool to speed this up. This time I just copy and pasted the word “.byte” to each line and resaved it.
Our code calculates where our guy is on the map, and prevents movements if it’s over a 1 (wall). We now collide with the red walls.
How does it do that? Let’s go over the code. So our byte array has each block 16×16. We need to divide x and y pixel coordinates by 16 (the same as shift right 4x). But we also need to multiply the y by 16 to get to the correct row in our array, which cancels out the divide 16. So the algorithm is (Y & 0xf0) + (X >> 4). If we look at that index in the byte array, it will tell us if a point is in a wall or not. This is the code, with X and Y registers holding the X and Y coordinates…
tya and #$f0 sta temp1 txa lsr a lsr a lsr a lsr a ora temp1 tax lda HIT_MAP, x rts
I handled each direction separately. First do the X move, then see if any of the corners of our sprite are inside a wall. If yes, revert to previous X position. Then do the Y move, see if any of the corners of our sprite are inside a wall. If yes, revert to previous Y position.
This code would need to be a little more complex if we move more than 1 pixel per frame. If we are moving 2-3 pixels per frame, and the distance to the wall is 1 pixel, we should allow 1 pixel movement toward the wall… and not be stuck 1 pixel away from the wall. So, this code will need to be improved.
Touching the yellow square will darken the screen. We are just looking if 1 point (the middle of our guy) is over a 2 in the collision map, and changing the screen brightness variable. Remember that the $2100 register is the screen brightness. I am writing to it every frame, during v-blank. Full brightness is $0f. Half brightness is $07.
If we were scrolling in a larger world, the collision map would have to be the size of the world. You could have it compressed, and decompress it to the WRAM. You would have to keep track of X and Y movements with 2 byte variables. One thing I would not recommend is trying to read from the VRAM to see what kind of tile you are standing over. The visuals of the level should probably be separate from the collision map.
One more thing. It wouldn’t be too much trouble to turn this simple example into a platformer. You would just need to add gravity, which is adding a little bit to the Y speed every frame, and then cancelling that if your feet touch the floor. Jumping would be a sudden negative Y speed.
This is a really cool page that explains collision maps in more detail.