At 06:28 PM 1/11/2002 +0100, you wrote:
Hi there!
Here's the sequel for last years Alpha Demo: The Beta Demo!
I upgraded it to 4K and managed to cramp another 7 (or 8?)
new parts into it, including early works from Eckhard Stolberg,
Rob Kudla, Ruffin Baily, Kurt Woloch and others!
Welp, this was just enough for me to download the tools onto my new-ish
iBook from my own site and start hacking a tiny bit (as that noise from
yesterday suggested). Just for the fun of it, I thought I'd post what I've
learned from Manuel's quick rewrite of my screen drawing code.
This is the key part from the rewrite, I suppose:
NextLine
STA WSYNC
LDX #$00
TYA
SBC yposP0 ; where P0 should start to appear
ADC #$10
BCC RuffinDraw1
LDX #%10100101
RuffinDraw1
STX GRP0
LDA #$00
CPY #$60 ; scan where PF1 should be filled
BCS RuffinDraw2
LDA #%11111111
RuffinDraw2
STA PF1
DEY
BNE NextLine
A long time ago (1998) in a galaxy far far away (right before my present
full-time programming gig!)
(http://www.biglist.com/lists/stella/archives/199806/msg00113.html), I'd
had a bit different screen routine that would save cycles but waste bytes
(forgetting that every bit is sacred, right?). What Manuel is doing with
TYA, SBC yposP0, ADC #$10, BCC RuffinDraw1 and then the same deal with the
RuffinDraw2 bits I was accomplishing with similar checks that would
actually branch you to different loops.
Since I knew I was really only writing to PF1 once, I figured I could
capture when Y dropped to $60 and branch into a different bit of code that
stuffed %11111111 into PF1, and then not have to mess with PF1 (so minus
the check and the LDA #$FF, STA PF1) until the end of the screen. Of
course this really only buys me extra cycles after I've started drawing to
PF1. Same basic idea with GRP0.
I like Manuel's idea better. :^) I'm afraid that I was trying way too
hard to anticipate needing every cycle to help me "compress" levels similar
to my run demo. The idea was to use as few bytes as possible to store
playfield graphics for a platform game with some convoluted screen draw
loops, and thereby allow myself to have many more levels in 2 or 4k. I'd
also wanted to keep single-scanline resolution for some egomaniacal
purpose. So even in this demo, I was erring way too far on the side of
saving random cycles.
Anyhow, the code here is very nice, and I hate to think how long it would
have taken me to figure out this route -- for some reason it was a pretty
major (though quick and painless) rethreading of my head. As Eckhard
pointed out for the run demo (iirc), and is also the case here, since I'm
moving the players two scans vertically with each frame [that they're
moved] anyhow, there's no reason not to use at least a variation of
double-scan resolution, which buys me another 76 cycles. Furthermore,
Manuel's screen drawing code only takes 34 cycles or so, so I've got plenty
of room to play for the time being even without doublescan res.
Hopefully I'll find some time to at least hack out the next demo in the
series (a very simple extension where P1 makes an appearance and P0P1
collisions are noted somehow) in the not too distant future. And hopefully
I'll also shelf the crazy platform level compression idea until I've done a
few slightly simpler bits of code that are a little easier to chew on.
So thanks Manuel (I think!) for reviving a little interest there,
Ruffin Bailey
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
