At 11:14 AM 11/11/2001 +0100, you wrote:
should work, if you simply swap DEY, TYA. That way, A get's the previous
Y value, which in result will delay your row-blocks by one line.
Okay, that fixed it after some fiddling.
90 cycles sound's a bit to low for me. How are the other 62 used? (PF +
HMOVE + loop = max. 55)
After changing the STX Temp/LDX Temp to TXS/TSX (which sacrifices more ROM
in the process by having to save/restore the stack) I get one extra
cycle. So we've got 91 ;)
In order to issue an HMOVE at the beginning, I needed to throw a single NOP
in after the STA HMOVE. If I can get away with doing an HMOVE a little
late, then we can have 93 free cycles with the first 2 cycles of the
playfield scanline being the last operation of the sprite
scanline... Assuming that isn't done, though, here is the breakdown:
HMOVE = 5 (with the NOP)
TombstoneIndexer routine = 15 (includes end-of screen logic and X
restore from stack)
LoadTombstones = 30 (includes saving X to stack)
BlankTombstones = 9 (includes a .W to keep the cyclecount even,
which can
ultimately be removed when more
code is added)
JMP TombstoneScanline = 2
TOTAL USED = 61 out of 152 avaialble
yields 91 left in two chunks.
28 available after the playfield writes, and 63 after tombstones are blanked.
With 26 cycles (which is my count), you'd gain 8 more cycles here, the
optimal player drawing routine need 18 cycles, so 38 cycles are enough.
Both player writes can't be squeezed into the playfield scanline as the
code is currently aligned.
Best case 38 cycles for the players and 52 for both missiles yields 90
cycles, which means we have 1 cycle left to spare!!! BTW, the current
VDEL-style sprite code I have is 20 cycles long. So I'm assuming you are
referring to the illegal opcode variation of that? I haven't used that yet
because I'm not too sure how to do it in .BYTE syntax. (I'm still waiting
for a DASM binary, official or otherwise, with illegal opcode support)
That isn't taking into account avoidance of the tearing effect or how to
achieve single-scanline precision with at least the cars...
It looks like I can't just group all the car sprite stuff on one scanline
because VDEL only drops down one sprite or the other, but not both.
It will be pretty tricky to get both cars to start on the playfield lines
without tearing.
I guess the next step is to tackle that problem and wait on the missiles
until later.
Since I think I've posted a bit too much sourcecode to the list in a short
span of time, I will post URLs for now in case anyone wants to look at it:
http://www.gamedevelopers.net/deathderby/code/dd_0013_experiment_02.asm
I'll wait until more of a major milestone to post code again.
BTW, I do encourage people to use the VCS.H I put up there. It's a
combination of Ekhard's and Nick's.
Glenn Saunders - Producer - Cyberpunks Entertainment
Personal homepage: http://www.geocities.com/Hollywood/1698
Cyberpunks Entertainment: http://cyberpunks.uni.cc
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
