8/22/2001 6:53:32 AM, "Thomas Jentzsch" <tjentzsch@xxxxxx> wrote:
>Erik Mooney wrote:
>> The Kernel# labels vary the position of the STA RESP0 by equal to
>> or less than 15 pixels between them, so you can use HMOVE to get
>> the object to any position on the screen.
>
>> So you've positioned your object by using lots and lots of ROM, but
>> only 28 cycles all told (including the last HMOVE). Much less than using
>> a full 76 cycle scanline.
>
>If think, you will either need more than 11 routines for that or need some
>extra cycles, because the writes to RESP0 will not automatically fit into the
>other code.
Or fewer, if your object is limited to less than the width of the screen. It would
have to be tailored for any game that uses this idea, of course. But even if you
have more routines, all you use is ROM, not any more cycles. Do you have
to be careful about indirect-jumping across a page boundary on the 6502?
>Another approach to save cycles, that I learned from Bob's code (used in River
>Raid too), is to divide the positioning into 2 (or more) parts (left or right positioning,
>used in Thrust of course:), but that won't help here.
Yup, I've done that too. This is just the logical extension of that.
>> Is this feasible? Has it already been done anywhere?
>
>It sounds possible to me, but not a simple task, because of the synchronization with
>the playfield writes. I haven't heard of that solution before, maybe it turns out to be
>to sophisticated. Good luck!
I think it's close to the theoretically fastest way to position an object. Why couldn't
the 2600 simply have had X coordinate registers for the sprites, like the C-64 or
something... :)
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
