Re: [stella] GunFight 2600: Limit broken again! Now help needed! :-)

Subject: Re: [stella] GunFight 2600: Limit broken again! Now help needed! :-)
From: Manuel Polik <manuel.polik@xxxxxxxxxxx>
Date: Thu, 15 Feb 2001 18:57:25 +0100
Manuel Polik wrote:

> Hehe, you're right. At the moment it's just: If I don't do the two CLCs,
> the sprites start to jump. Maybe it's worth to investigate WHY :-)

Ok... the carry needs a defined state, that's all. Both the addition &
the subtraction mess around with the carry, so when the sprites overlap
vertically like this...:

*****	 1		0
*****    1		0
*****	 1	*****	1
*****	 1	*****   1
	 0	*****   1
	 0	*****   1

SP1 	 C	 SP2    C

... the bottom of SP1 would clear the carry while SP2 is drawed and the
top of SP2 would clear it for SP1. On these two positions I'd lose a
line of the sprite, because of the jump.

Now I just made a SEC replace a NOP in my skipdraw routines. The four
won cycles now provide black 'guns' :-)

It's now single again, since in a 2LK I'd have to do the color writes in
the second line too, or? 

ARGH!!! ... with 4 color-writes per line, I win next to nothing in a
2LK. Any ideas around that problem? (I mean - besides buffering the
player colors in the RAM and/or TXS&TSX... :-))

And: can someone give me a crash course in clever missile programming? I
mean, do I really have to tweak ENAMx all the time? what about just
making the missile invisible with the background color? 

I just thought I wouldn't need to determine _where_ the missile is,
since it is aligned with the player, but with ENAMx I fear I need to
know _exactly_ where it is...

And another question: What all is delayed with VDEL? Just STA GRPx? What
about STA NUSIZx?


P.S.: Just the binary this time, the delta in the source is < 5 lines
and described in the mail.

Attachment: gunfight.bin
Description: Binary data

Current Thread