I've been procrastinating for some time but last night I started tinkering
around with trying to wedge in the missile code into the Death Derby Kernel
and I'm thinking that the best I can possibly do would be to generate one of
the two missiles, with code that would have to span both of the scanlines.
It doesn't look like I have enough time for even this. The problem with
using the missiles is there is too much overhead involved vs. the players.
To generate the players all you do is write to GRPx and either there is data
in there or all zeroes (blank). You don't have to fiddle with enabling or
disabling them.
With the missiles, I have to selectively enable them, set fine control, and
set width. That's six writes right there if I intend to update both of them
on the same scanline.
Not only that, but to save ROM I'm storing all the fine control and width
data in the same byte.
So when I write the width register, I need an additional AND %00110000 to
mask off the unnecessary bits otherwise I mess up the players in the
process. Since the significant bits of the width and the motion registers
are not aligned in an optimal way, I need to shift bits also. All this adds
considerable overhead!
If I store the motion stuff separate from the width stuff to avoid the
masking and shifting, then I have to do an additional load indirect Y which
sucks up an additional 5 cycles.
That's 20 cycles right there just to load those 4 bytes.
I also thought about writing the graphics to RAM ahead of time, but if I had
the stuff separate then that's 4 LDA n,X operations.
Then I thought about unrolling the entire thing so that instead of having
ROM tables I could just hardcode writes in many variations of the kernel.
If the RAM buffer for the missiles were 16 bytes each, then the unrolled
loop could do hardcoded load zeropage through all 16, or fewer depending on
how much the missiles overlapped.
N
Kernel_X0 (each kernel does the playfield and does a load to the start of
the RAM buffer + N (not Load n,X, but hardcoded pointing directly to that ZP
address for speed, then pushes it to the missile registers.)
Kernel_X1
Kernel_X2
Kernel_X3
Kernel_X4
Kernel_X5
Kernel_X6
Kernel_X..15
Example setup:
00000000 00000000 <- always start here
01000000 00000000
01000000 00100000
01000000 00100000
01000000 00100000
01000000 00100000
01000000 00100000
01000000 00100000
01000000 00100000
00000000 00100000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000<- always end here
Main kernel:
CMP MissileStartScanline
BNE .NoMissiles
JSR DoMissiles (always draws 31 scanlines)
.NoMissiles (on last iteration, finishes the last of the line-pair)
If the missiles were more separated it would breakoff twice and JMP/JSR to a
different spot:
01000000 00000000
01000000 00000000
01000000 00000000
01000000 00000000
01000000 00000000
01000000 00000000
01000000 00000000
01000000 00000000
00000000 00010000<- jump in here to just do missile 1
00000000 00010000
00000000 00010000
00000000 00010000
00000000 00010000
00000000 00010000
00000000 00010000
00000000 00000000<- always end here
Even if I were to do this, there is still precious little time inbetween the
playfield writes to handle the missiles.
I can think of LOTS of ways to do it that involve flicker. I could draw the
tombstones/pedestrians every other frame, for instance. But I really don't
want to resort to flicker under any circumstances.
Anyone have any ideas?
GLENN SAUNDERS===============================
By Day - Web Developer - http://www.eUniverse.com
==============================================
By Night - Producer - Cyberpunks Entertainment
Personal homepage: http://www.geocities.com/Hollywood/1698
Cyberpunks Entertainment: http://cyberpunks.uni.cc
_________________________________________________________________
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/
