saga20101116 - simondotm/stardot-wiki GitHub Wiki
First up: I realised that the extra lda
workbuffer
above is superfluous (though not the cmp). I could have saved the flags register to stack, but I gain nothing by doing this.
This time I've been doing the code to manage objects. This is a bit more complicated than just searching through for present objects. As objects can be moved during the lifetime of the adventure they need to be stored in the save area, along with other data used by the engine (e.g. flags, counters, current room etc). So, I've reserved a page to keep this information in and set it up at gameinit. The routine's quite simple: blank out the main area, then copy object locations and information from the game header (player start room, light length).
The advantage of keeping this contiguous is that when I implement SAVE GAME and LOAD GAME, all I need to do is save and load to this page of memory!
Finally I added the code to print out present objects. As the text is in the standard tokenised format, this was easy enough (code reuse is really useful).
One potential problem that I'm seeing is the amount of 16 bit updates I'm doing. This is leading to a lot of code of the style:
{.objectloop lda objectlocs,x
cmp currentroom
beq printobject
.nextobject inx
cpx nitems
bne objectloop
jmp leave
.printobject stx xstore
txa
jsr findobject
lda foundptr
clc
adc #2
sta foundptr
bcc prtobj
inc foundptr+1
.prtobj jsr copymessage
ldx #workbuffer MOD 256
ldy #workbuffer DIV 256
jsr printbuf
ldx xstore
jmp nextobject
}
There must be an easier way to manage a 16-bit number than just doing inc loc(or adc); bne (or bcc); inc loc+1. I'm starting to wish I was doing this on a Z80 now!
A quick update ere the day ends. To test the exits code I added a very quick way of navigating around the adventure (i.e. a hack - I just read N, S, E, W, U, D from the keyboard and move in that direction).