At 13:56 26.08.98 -0000, you wrote:
>at this bin. It should be UUEncoded. Please lemme know if it ain't.
Would it be possible to send the binaries as MIME attachments?
At least for me they are easier to handle, since I don't have to run
an extra decoder program for them.
>So what can I do to keep my sprite from jumping up a scan line between
>x-positions 44 and 53? I tried VDEL, hoping everything would get itself
>together during the line, but no luck.
I disassembled your program and had a quick look at it. If you really
want to do single scanline resolution, I would suggest some major
rewrites.
Your indirect-y-indexed pointers all seem to be pointing to the end
of a page. Reading through them will always cross a page boundary
and therefore take one cycle longer than nessessary. They should
point to the beginning of a page like $FF00.
You seem to have the data for PF1 and PF2 interwooven into one list,
which you address with the same pointer. Increasing the index register
between the reads for PF1 and PF2 is another unnessessary time waster.
You should use two lists and two pointers. I'd even suggest to use
normal y-indexed adressing instead of indirect y-indexed addressing
like:
ldy counter
lda PF1list,y
sta PF1
lda PF2list,y
sta PF2
iny
sty counter
Instead of resetting COUNTER to zero between two frames, you can
reset it to a multiple of 6 (or whatever the number of stages per
level is). This would be a lot faster and you would only need
one byte in RAM to store the reset value, instead of two for the
pointer. With 6 stages per level you can still have 42 levels in
in the game (6*42=252bytes, which fits nicely into one page).
All the checks for what to display when should be done at the
end of the scanline instead of the beginning. You have only 22
cycles before the display starts (28, when you don't use the PF0
area). When the display starts you must have set up everything,
that can be displayed at the far left, like GRP0 and PF1, or
you'll encounter problems, like the ones you mentioned. In the
second half of the screen the display does not change, so that
you have enough time for the checks. I'd suggest that you take
out the STA WSYNC before the different checks and instead hve the
checks branch to a STA WSYNC line.
Since your player seems to move vertically in steps of two scanlines,
it might be a good idea to have the display routines do two lines
between the checks for the player to be displayed. That way you
could for example draw the steps of the ladders without calculating
the value for PF1.
That are all the changes I can think of now, without using a
completely different display routine.
Ciao, Eckhard Stolberg
P.S. Some days ago I sent you a modyfied version of the DASM source
code, which I thought might work with your C-compiler on the MAC. Did
you get it or did the internet eat it?
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
