Re: [stella] Two triple-copy sprites for 48 horiz. pixels hi-res?

Subject: Re: [stella] Two triple-copy sprites for 48 horiz. pixels hi-res?
From: Nick S Bensema <nickb@xxxxxxxxxxxx>
Date: Sat, 8 Mar 1997 02:18:20 -0700 (MST)
>	p0 p1 p0 p1 p0 p1
>
>	0  1  2  3  4  3 
>		      (dang, it went too quick for me to read then write a new bit
>pattern in the last spot--I could also have put a four or a two in
>there, but not a 5--just gimme *one* more register...)

This requires a more intricate system of timing than I've been able to
provide.  Yet.

>The fastest way I've figure so far is to absond with the stack pointer
>and hide away byte 6 long before the time critical stuff:
>
>	ldx byte6
>	txs
>	..
>	sta GRP0
>	stx GRP1
>	sty GRP0
>	tsx		;2 freaking cycles, and I need it yesterday!
>	stx GRP1
>
>But that's still too slow...

Try moving your players to the right a little more.  Perhaps your aim
is off, so to speak.  The question is, if I have a copy of player N at 
position X, how soon (in CPU cycles) do I need to modify it to make
the change clearly visible?  I'm going to modify my cycle counting
texts to AT LEAST account for the fact that STA's to a register take
place at the LAST cycle, whereas it currently says to put asterisks
around the first cycle.

It is this way in which the 12-column text from games like Stellar
Track are actually easier timing-wise, because players are spaced
apart further away and you have 16 pixels (5.3333 CPU cycles) between
each copy.

It is just so incredibly possible.  Consult the Defender source code.
In fact, I think I'll look at it tomorrow and add cycle counts.


--
To unsubscribe, send the word UNSUBSCRIBE in the body of a message to
stella-request@xxxxxxxxxxx

Current Thread