[stella] Beta Demo lesson learned

Subject: [stella] Beta Demo lesson learned
From: Ruffin Bailey <rufbo@xxxxxxxx>
Date: Wed, 23 Jan 2002 22:42:53 -0500
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:
                    STA WSYNC
                    LDX #$00
                    SBC yposP0  ; where P0 should start to appear
                    ADC #$10
                    BCC RuffinDraw1
                    LDX #%10100101
                    STX GRP0
                    LDA #$00
                    CPY #$60    ; scan where PF1 should be filled
                    BCS RuffinDraw2
                    LDA #%11111111
                    STA PF1
                    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/

Current Thread