Before tackling the thing we want, namely limiting the player's movement, let's change the map size. There's no real reason why we wouldn't just use the whole screen as the map, and we can fit 16x12 tiles on the screen, so let's do that.
map: db 2,2,6,3,5,2,2,2,2,2,2,2,2,2,2,2 db 2,5,6,3,2,2,6,2,2,2,2,2,2,2,2,2 db 2,2,2,3,2,6,2,2,2,2,2,2,2,2,2,2 db 3,2,3,3,2,2,2,6,2,2,2,2,2,2,2,2 db 2,2,2,6,2,2,2,2,2,2,2,2,2,2,2,2 db 2,2,0,2,2,2,6,2,2,2,2,2,2,2,2,2 db 0,1,0,2,6,2,2,7,2,2,2,2,2,2,2,2 db 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 db 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 db 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 db 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2 db 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2
The map grows to that size, which is pretty huge compared to our earlier 8x8 map. But it will allow for more interesting levels. We have the space, so why not use it. If we want smaller levels, we can just surround them with brick walls.
After fixing every place that cares about map size (dirtymap, map drawing loop, player movement), the full screen map is there. But wait..?
We're using a lot more time now, much more than we'd expect by growing the map. After all, we're not drawing anything more, we're just scanning through it. Maybe it's just that slow. But let's see if we can figure things out a bit and give different border color for the drawtile from the rest of the main loop.
ld a, 1 out (0xfe), a call drawtile ld a, 2 out (0xfe), a
Here we set the border color to 1 (blue) and back to 2 (red) after the drawtile. The result shows how much time (and where) the drawtile takes.
Moving around the map also changes where the blue stripe happens - the higher you are on the map, the lower the blue stripe appears. So, just scanning the whole map takes quite a bit of time.
We could solve this by making a live list of tiles that need updating - so we wouldn't need to scan through the map - but I don't think this is a problem for now. Let's march on.
We need to limit the player's movement in a few ways: the player shouldn't be able to move outside the screen, and the legal tiles to move into are empty, ground, diamond and open exit. Anything else is forbidden: brick walls, stones, closed exit and goo.
Starting with the map edges, the moveplayer function gets a lot of changes, so let's start off the top.
moveplayer: ld hl, (playerpos) ld bc, map add hl, bc ld (hl), 0x80 ld hl, (playerpos) ; Trying to move up, check if we're not on the top row ld a, l cp 16 jr c, notup ld a, (movekey) bit 0, a jr z, notup ld bc, 65536 - 16 add hl, bc notup:
Before trying to move up, we add a few lines to check if we're in the top row, and if we are, we skip the whole movement key check. We do this by loading the tile offset to the A register and using the CP instruction. CP is practically the same as SUB, but doesn't store the result. In this case it doesn't matter which we use as we don't care about the contents of the register afterwards, but if we were to chain several comparisons, it would be helpful.
Subtracting 16 from, say, 5 will overflow and set the carry flag, so we know we're in the top row and can skip the up movement.
; Moving down, check if we're not on the bottom row ld a, l cp 16*11 jr nc, notdown ld a, (movekey) bit 1, a jr z, notdown ld bc, 16 add hl, bc
Same thing for the bottom row. Here we just check that the carry flag isn't set.
notdown: ; Moving left, x coordinate may not be zero ld a, l and 0xf jr z, notleft ld a, (movekey) bit 2, a jr z, notleft dec hl
We won't allow movement to the left if the x coordinate is zero. This is done by separating the x coordinate bits off the tile index, which conveniently also sets the flags, so we don't need a separate comparison operator.
notleft: ; moving right, x coordinate may not be 15 ld a, l and 0xf cp 15 jr z, notright ld a, (movekey) bit 3, a jr z, notright inc hl notright: ld a, 0 ld (movekey), a
And moving right, we skip if the X coordinate is 15. We need the CP instruction here as we're comparing with a specific value, and subtracting 15 from 15 will be zero, so the zero flag is set if we're on the rightmost column.
Now we have the potential target coordinate, next we need to check if the movement is to a legal tile.
; Now that we have a *potential* new position in hl, we need to ; figure out if it's legal. ld bc, hl ld de, map add hl, de ld a, (hl) ld hl, bc
To see if the tile is legal, we do the register gymnastics to get the target tile. Then we can check if it's fine to move to that tile, and act accordingly.
cp 0 jr z, moveok ; Empty tile is always fine cp 2 jr z, moveok ; Ground is fine cp 5 jr z, moveok ; Gems are fine cp 8 jr z, moveok ; Open exit is fine jr movedone
This is where the CP instruction comes handy; we don't need to re-load the register all the time. Alternatively we could check for the tiles that block movement, but there are just as many of those. Additionally some of the tiles have a special meaning, like collecting gems or moving to the exit; we'll get back to those eventually. We also want to make it so that rocks can be pushed if there's empty space to move to.. which will need its own handler.
moveok: ld (playerpos), hl movedone: ld hl, (playerpos) ld bc, map add hl, bc ld (hl), 0x81 ret
And in the end we either update the player's position or don't, but in any case update the player's sprite in the map.
This chapter's version of the source is available here.
The raw binary is now up to 1603 bytes, up from 1396 of the last version. Still plenty of space.
Any comments etc. can be emailed to me.