Re: [stella] Collaboration

Subject: Re: [stella] Collaboration
From: Thomas Jentzsch <tjentzsch@xxxxxx>
Date: Tue, 14 Jan 2003 11:13:13 +0100
Glenn wrote:
> Let's just go ahead and enforce a hard limit on the safe zones because 
> otherwise it pretty much defeats the purpose of a safe zone, ...

Ok, that might make it a bit easier.

> but at the 
> very least you can definitely wrap at the top and bottom although even 
> there you bump the boundary and then wrap around slowly.  

That shouldn't be a big problem. It just requires a the top some extra initialization for the objects. Not possible would be, to see the objects partially at the top *and* the bottom at the same time.

> We can even cheat the boundary inward an extra playfield pixel on 
> each end if we really need the time.

Won't be necessary (I hope).

> It looks like the best way to avoid this problem is to just not let the 
> cars pass horizontally at all.  Let's just finalize that constraint.


Should they be able to move (slowly) through the safe zones?

> Could we enforce vertical separation?  Then the green gremlin could drop a 
> red grenade if the red gremlin is not on those scanlines and for the 
> lifetime of the grenade, the red gremlin could avoid it, and vice 
> versa?  This could actually have some cool exploitable effects as it would 
> hinder the gremlin's ability to evade cars depending on circumstances.

Vertical separation might be possible. But at least we'll need some repositioning inside the kernel then. I think this could be achieved by adding blank lines between the tombstone rows.

> It would be better to have the ghost wave use both missiles and not have 
> gremlins on screen at that time.  That way the ghost can have free reign of 
> the screen.

Ok, that's easy fo the kernel. :-)

> Maybe if the tombstones had just 1 extra scanline (that would normally be a 
> tombstone line--lots of CPU available) between them we could get the ball 
> positioned in there?   That way I could have the gremlins drop grenades 
> when they are within the vertical range of the grenade line, and they'd be 
> able to drop it anywhere horizontally on that line.

I think we would need 2 extra scanlines for that and with multiple grenades we would have to reposition them inside the kernel too. Or they had to flicker.

> Now, if the cars KNEW that grenades could only occur on those lines they'd 
> be too easy to evade but if it were somehow possible to get multiple 
> grenades (light up 1 grenade for each possible grenade zone) then it would 
> be more treacherous.  If they weren't grenades but something I could 
> rationalize horizontal animation for, then that would help.  Can't think of 
> what that would be off-hand, though.

I think I need to play the original game to understand every detail your are talking about. AFAIK DD isn't emulated by M.A.M.E, any other chance to play it?

> The other approach would be to drop out the rest of the tombstone line so 
> that the grenade could be positioned with more accuracy, but this wouldn't 
> look as good once lots of tombstones are on the same line because it would 
> be apparent that the line is being blanked to make room for the 
> grenade.  Since the tombstones are already semi-opaque because of the 
> interlacing, this wouldn't be a good thing.


> The grenade gameplay idea might not be that necessary, actually.  But I 
> just wanted to know how much headroom is left with the current kernel 

Not much, that's sure.

> I just like the ideal of 
> making use of all 5 sprites for something meaningful in the game.  I don't 
> think many games do that, at least not many games that feature a playfield 
> bitmap.

Utilizing the ball won't be easy. And doing this only for the challeng IMO doesnt make too much sense.

> If you mean some form of flickering or chronocolor, I'd like to avoid 
> that--aside from maybe the ghost, where it makes artistic sense.  

You won't notice *any* flicker if the colors are chosen right. Or does the Robot City helicopter flicker?

> Also 
> because of the rotational nature of the sprites, color register changes 
> don't make much sense, otherwise the missile gremlins could have been given 
> more of a pitfall harry look.  

Sorry, but I don't understand this sentence.

> When purposefully avoiding flicker there is only so much you can fill up 
> the screen.  I know Super Challenge Football used vertical separation to do 
> the rest, and I'm thinking as a final challenge (no pun intended) you could 
> try to redraw the zombies further down the screen like that so we could 
> have pairs or triplets of zombies moving as a linked set in the latter 
> waves.  

That will only be possible by doubling the kernel(s) for each additional zombie.

> If you HMOVED them inbetween you could even get them staggered out 
> a bit instead of perfectly lined up without having to completely reset 
> their horizontal position.  But I realize the current kernel couldn't do 
> this.  It would have to be some kind of new trick.  That would just be 
> icing on the cake.

HMOVEing wouldn't be the big promblem, but enabling/disabling the zombies would. Therefore we would need the replicated kernels.

> If there is time to make the tombstones have a subtle fade-out gradient 
> from white to dark grey, that would look good, I think.  It might give them 
> a rough illusion of depth--like they are standing up, although doing this 
> would also shade the "alley".  It's worth trying out if possible.

Actually I just tried that yesterday. I used the 3 free cycles for "sta COLUPF" and calculated the value for A from Y. There I used the two nops at the start of the loop. This gives quite a lot of possibilities. E.g. red tombstones, each line with new brightness, ranging from $2..$e:
  ora #$40
  sta  COLUPF

> You made the tombstones gray but I actually wanted them to be white, so the 
> ball/playfield color would work.  

Now I am confused! Gray is just a "fade-out gradient" of white. 

> One finishing touch I was hoping for was to get a solid white horizontal 
> boundary line above and below the active playfield.  I was having trouble 
> doing this without some kind of glitch somewhere on the edge of the top 
> boundary because I'm setting up the playfield rewrites and such.

That shouldn't be a big problem. Should the cars or zombies be able to move over that border?


Virenschutz inklusive: Bei WEB.DE FreeMail können Sie jeden
Dateianhang auf Viren prüfen

Archives (includes files) at
Unsub & more at

Current Thread