[A83] Re: Tilemap

[Prev][Next][Index][Thread]

[A83] Re: Tilemap


Olle's suggestion is, of course, how you want to handle collisions.  I hate
to keep mentioning Zelda 86, but these techniques are very old, and are out
there for anyone willing to look.  I started doing z80 for the 86 in April,
a few years ago.  That summer, I got together online with Matt Johnson (who
had the cool 86 Central site) to make a game.  We wanted to make the
greatest game ever for a calc.  It was going to be Metroid.  Well, we had
each done programming before, but neither of us had a lot of experience
doing large assembly projects.  I could write assembly, but I was a newbie,
and while I could code just about anything, the resulting code sucked.  We
needed to know how to make a side scroller, and make it fast.  So what did
we do?  We looked at Sqrxz.  It was there, it worked, and since Mardell
wrote it, it must be good.  We studied every part of that program, and used
a lot of the ideas in ours.  We just kept hacking on the code, until it had
what we wanted.  We started with map scrolling routines, got them working,
added a player, added collisions, add bullets, and a bunch of other stuff.
The code was a mess, and eventually fell over under it's own weight, but we
learned a lot.  Now that I think about it, I have no idea what happened to
that code.  I think I would have a good laugh looking at it now.  But the
important thing is that we learned a lot, and we didn't do it by asking a
bunch of questions and trying to get people to write code for us.

Anyway, if enough people bug me, and I have time, I will spend an evening or
two and put together a page about how Zelda 86 works.  The code is large and
hard to follow, but if you look at some of the files (especially
movement.asm), you'll find a lot of useful stuff.

It's important to abstract stuff, and make things as reusable as possible.
The start of the routine quoted below should be broken up into several
routines, as they will be used throughout the program for many different
purposes.

For checking if tiles are solid or not, pick a number, like 64.  Everything
above that will be solid.  Then you can use a very simple routine:

; de = address of tile to check
; returns: carry = tile is solid
CheckSolid:
 ld a,(de)              ; load the tile
 cp SOLID               ; is it clear?
 ccf                    ; reverse check
 ret                    ; return

Where do you get this address?  Possibly from several different places.  You
never know where you will be working with tiles, so you want one single
routine to modify if you ever need to change how you are doing it.  It is
very common to need a tile from the map at certain coordinate, so make a
routine:

; bc = coords to get (x, y)
; returns: de = pointer to map tile
GetTile:
 ex de,hl               ; hl will be saved in de
 push bc                ; save bc
 srl b                  ; divide x by 2
 srl b                  ; / 4
 srl b                  ; / 8
 ld a,c                 ; get y coord
 and %11111000          ; clear lower 3 bits
 add a,a                ; * 2
 add a,b                ; calc offset
 ld l,a                 ; load into low byte
 ld h,0                 ; clear high byte
 ld bc,Map              ; get tile from the current map
 add hl,bc              ; compute offset in map
 ex de,hl               ; need to return in de
 pop bc                 ; restore bc
 ret                    ; return

When you write everything using little routines like this, building more
complex stuff suddenly isn't so complicated.  And the code gets a lot
smaller.

> collission_check:
>  ;inputs: e = x co-ordinate, d = y co-ordinate of sprite. (in tiles)
>  ; pixel checking requires to check the TopL,TopR,BotL and BotR bits of
the
>  ; sprite for being in a "wrong" part of the map, and I don't have time to
>  ; work that out now...
References: