[stella] Gunfight 2600: Not mergeable with Colbert wizardry...

[Manuel Polik <cybergoth@xxxxxxxx>]

Hello!

As you know, I was playing around with some old archive code from Bob
Colbert. I was trying to reduce the flicker of my bullets with his
sprite-multiplexer.

After some toying with all this stuff, I decided to not merge both
projects. I'm not even sure, if it would be posible at all. Here's some
of the major reasons for my descission:

- Bobs routines can do a repositioning every 4th line, i.e. one would
come down to 1/4th of the vertical resolution for positioning. All my
objects would still be drawed in 2-line resolution, but they'd
vertically hop 4 pixels at once. I want something smoother here.

- It would add an enormous RAM usage. One needs to handle at least two
additional tables, one where the vertical positions are sorted, and one
where you can store several flags, like if the sprite was drawn last
frame or not.

- I don't think you could separately paint 2 sprites with two color
changes + 2 PF values _and_ doing all that repositioning business. The
only other way would be drawing _everything_ with Bobs multiplexer, but
that would obviously introduce flicker to everything, even the cowboys,
as soon as they overlap, which is most likely always the case in the
'Gunfight' scenario.

- It would add an enormous ROM usage. Now, I'm just doing a simple 2LK.
If merging both routines, I'd not only need to do 4 drawing _only_
lines, I'd have to handle a second case, with another 4 lines of drwing
_and_ repositioning. I assume that'll at least quadruple the ROM usage
just in the kernel, not counting any additional overhead, which is
another _big_ bunch.

- It's eating nearly all the time of the vertical blank _and_ the
overscan. This, plus the additional RAM usage prevent me from doing more
than 6 bullets. So I gain nothing here...

Final result: though I still think these routines in general are
brilliant, they won't help for my purpose.
All in all, I'd say that the flicker - as it is now - isn't really
_that_ bad anyway.

So I now just continued with my own code where I finally managed to find
that nasty little bug preventing me from doing two different horizontal
speeds. 
My code now needs exactly 5 Bits per bullet to decode all angles +
speeds as featured in the demo. I plan to use the remaining 3 bits as
'alive' counter of the bullets, so all in all, I need only 3 Bytes per
bullet! (There's even one bit left, D7 in the vertical position byte
:-))

Just the binary attached, next source follows when some basic shooting
is implemented :-)

Greetings,
	Manuel

Attachment: gunfight.bin
Description: Binary data