![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Oct. 7th, 2006 03:46 pmAdding the playfield was a nightmare.
I had thought up ways of trying to impliment it but not only could I not get them to work at first - I also saw the glaring problem of excessive ram usage that really wasn't necessary. As a result, versions 0.002 and 0.003 are dead. I could have just named this as version 0.002 but given this version does reuse some of the
code I wrote in both versions 0.002 and 0.003...
The playfield has a similar, but greater, resolution as Atari's Adventure. Adventure divides the screen up into 7 zones. the middle 5 being twice as big as the top and bottom zones. Using some simple math on 192 scanlines for a visible picture, you see that it uses a 16/32/32/32/32/32/16 zone approach. This is ok, but since I'm planning on bankswitching this rom later on, I can afford to use up the extra rom to have equal sized zones. In this version, I drew the yellow castle as the playfield. It has nothing to do with the game idea I'm heading towards, but does show some of the possibilities.
Additionally, I'm surprised I've still managed to keep in the background changing code so far. There was almost not enough time to do everything I wanted however so when I go ahead to adding a few more things it'll probably have to go, or get limited somehow.
Two problems I had with this code - not updating things fast enough in instances where I had to update the player AND the playfield at the same time. I was just barely late in updating the Playfield registers. As a result it gave me an odd looking error in the form of "playfield bleeding" onto the next line. Because I forgot that P1 is arranged differently than P0 and P2, it took me a while to figure out exactly what was going on. It was only affecting the left side however so I knew it had to be a timing issue. ^^;; To fix it, I moved some things with the background color around, pushing the update of the variable to after the playfield was updated (5 cycles freed) then moved the loading of the bgcolor variable just before the line's WSYNC instead of right after it. (3 cycles)
There was also a case where the screen would roll whenever the player crossed over a zone boundary. (the top line of the player only) The problem was with how I had added the code to set PlayerSize into Y to determine how long to keep displaying the player before we turned it (the missiles) off again.
dec LineCounter
ldy PlayerSize
bne .SomeLabelI'mForgettingTheNameOf ^^;;
Basically that's what I did. I shoved the ldy right between a DEC that was trying to count down the lines remaining in the current zone, and the bne that was waiting to test for the Zero Flag that the dec would at one point set and signal a new zone.
Because PlayerSize is always non-zero....
Anyway, moving it fixed the problem.
My next goal is to play with the collision latches and to start in on the collision detection between the player (missiles) and the playfield. This should be a simple update compared to adding the playfield. X_X
For screenshots/attachments, refer to my Atari Age Blog with the title "Action RPG".
I had thought up ways of trying to impliment it but not only could I not get them to work at first - I also saw the glaring problem of excessive ram usage that really wasn't necessary. As a result, versions 0.002 and 0.003 are dead. I could have just named this as version 0.002 but given this version does reuse some of the
code I wrote in both versions 0.002 and 0.003...
The playfield has a similar, but greater, resolution as Atari's Adventure. Adventure divides the screen up into 7 zones. the middle 5 being twice as big as the top and bottom zones. Using some simple math on 192 scanlines for a visible picture, you see that it uses a 16/32/32/32/32/32/16 zone approach. This is ok, but since I'm planning on bankswitching this rom later on, I can afford to use up the extra rom to have equal sized zones. In this version, I drew the yellow castle as the playfield. It has nothing to do with the game idea I'm heading towards, but does show some of the possibilities.
Additionally, I'm surprised I've still managed to keep in the background changing code so far. There was almost not enough time to do everything I wanted however so when I go ahead to adding a few more things it'll probably have to go, or get limited somehow.
Two problems I had with this code - not updating things fast enough in instances where I had to update the player AND the playfield at the same time. I was just barely late in updating the Playfield registers. As a result it gave me an odd looking error in the form of "playfield bleeding" onto the next line. Because I forgot that P1 is arranged differently than P0 and P2, it took me a while to figure out exactly what was going on. It was only affecting the left side however so I knew it had to be a timing issue. ^^;; To fix it, I moved some things with the background color around, pushing the update of the variable to after the playfield was updated (5 cycles freed) then moved the loading of the bgcolor variable just before the line's WSYNC instead of right after it. (3 cycles)
There was also a case where the screen would roll whenever the player crossed over a zone boundary. (the top line of the player only) The problem was with how I had added the code to set PlayerSize into Y to determine how long to keep displaying the player before we turned it (the missiles) off again.
dec LineCounter
ldy PlayerSize
bne .SomeLabelI'mForgettingTheNameOf ^^;;
Basically that's what I did. I shoved the ldy right between a DEC that was trying to count down the lines remaining in the current zone, and the bne that was waiting to test for the Zero Flag that the dec would at one point set and signal a new zone.
Because PlayerSize is always non-zero....
Anyway, moving it fixed the problem.
My next goal is to play with the collision latches and to start in on the collision detection between the player (missiles) and the playfield. This should be a simple update compared to adding the playfield. X_X
For screenshots/attachments, refer to my Atari Age Blog with the title "Action RPG".
