Re: [stella] 'Look Ma No Flicker' revisited

Subject: Re: [stella] 'Look Ma No Flicker' revisited
From: "Glenn Saunders" <cybpunks@xxxxxxxxxxx>
Date: Wed, 29 Aug 2001 20:10:05 -0700
SC Football already definitively does it, so you aren't really doing
anything strictly new technically.  More so the challenge here is to create

I tried disassembling SC Football and didn't get that far. Huge chunks of "data" which I knew had to be code and not knowing what to do with it.


believable sprite shapes within the constraints of the missile objects.

I already attempted as much that in the mockup images. I thought it looked somewhat Berzerk-like and acceptable.


Well, you'll have to apply a fine-control adjustment (even if it's just an empty
HMOVE after an HMCLR) on every scanline unless you want an ugly
"comb" effect like Missile Command.

I'm content with the comb effect given that the left side is in the "safe zone" where only one pedestrian will be in when spawned, and the background color will be black most of the time.


Just off the cuff, this I think would be fairly ugly. I could never stand the
striped paddles in Video Olympics or striped scores in several games. With
optimization to hang on to playfield bytes after fetching them (TXS / TSX
being the obvious), I think you can do it.

Originally I wanted to do color register changes to make the top scanline grey to give it some shading for a 3D effect but I don't think that's at all possible, and even if it were, it would color the border lines in the safe-zones which I wouldn't want.


There is no avoiding the fact that they will be relatively undefined blocks.

But then again, Piero didnt think he could stripe the playfield pearls at one point either.

And of course if you're using reflected-playfield, the PF2 rewrite must be timed
exactly.

That's one thing I've been having trouble with in my early kernel attempts. I'm not so sure where "exactly" is, cyclewise, or how to insert any sort of conditional logic ahead of the rewrites because that would involve variable delays depending on the branch taken.


This is a real newbie question, but what's the best approach in the middle of the kernel to answer all these scanline-state questions, namely:

Am I on a scanline that requires P0, if so, which address offset from the top of P0 do I pull the graphics from?

Am I on a scanline that requires P1, if so, which address offset from the top of P0 do I pull the graphics from?

Am I on a scanline that requires M0, if so, which address offset from the top of P0 do I pull the fine-control adjust and width setting from?

Am I on a scanline that requires M1, if so, which address offset from the top of P0 do I pull the fine-control adjust and width setting from?

I have a hard time figuring out how I can write the above code in the tiny amount of time one is given between WSYNC and the first playfield rewrite. Once the playfield starts rewriting there isn't going to be any time to do anything else until after PF1 on the right side is stored, which only leaves a little time left before you've reached cycle76.

Since I'm only doing double-line res, I can unroll the kernel into a line-pair and only ask relevant questions about one player at a time, since even if they are supposed to appear on the same scanline, VDEL will make the adjustment to line them back up. But even then, it seems like there isn't enough time to do all this processing.

Once I can get beyond this critical-section of the code, I think the rest is going to be a piece of cake in comparison.



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


- Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/

Current Thread