Re: [stella] Grid demo

Subject: Re: [stella] Grid demo
From: John Saeger <john@xxxxxxxxxxx>
Date: Wed, 28 Oct 1998 15:03:29 -0800

Eckhard Stolberg wrote:

> >Generally speaking, this is true for the second and later hits of RESPx
> >on a line.  The first hit on a line generally gives you all of the
> >copies including the first.  But there are some subtleties having to do
> 
> I don't think this is how it works. 

Yes, I think you're right.  Wrong theory.  It's been a while since I've
thought about this stuff and I was in a hurry to explain to Erik that
it's really not so simple. :-)

> Look at trick18 or extra18.
> The last hits to RESP0/RESP1 both generate three copies.

Hmmm.... I don't think so.  I don't think it's possible for a RESPx
other than the first one on a line to generate three copies.  Check out
the attached latehit.bin.  It has two groups of three sprites and I
don't think either of them overlap.  Yet only two sprites per group show
up.

> I think it has to do with wether you hit RESPx when a sprite is
> currently displayed or not. Hitting RESPx when a sprite is
> displayed, gets you all copies, hitting RESPx during the gap
> or after the first sprite has been drawn omits the first copy.

I think the rule on whether three sprites can show up is that there must
not have been more than one RESPx on the prior line, and it must be the
first RESPx of the current line.  Check out evenodd.bin.  The second set
of RESPx is done on alternate lines.  So alternately you see three
sprites in the first group, then two sets of two sprites.

> The pixel at which you hit RESPx, the screen position, at which
> the sprite is currently positioned and of course the value in
> NUSIZx might be factors for the outcome of this trick too.
> 
> Also the resulting screen position for the additional sprites
> is a complete mystery to me. For example in the grid demo the
> last two copies of the sprites are overlaping into the next
> scanline, where they are hit by the initializing accesses to
> RESPx. As a result to this all following sprites will be
> positioned at a different screen position than during the
> initial scanline.

I don't think I understand positioning either.  I think that maybe
there's an additional delay for the positioning if the RESPx is the
second one on the line or there were multiple RESPx on the prior line. 
Like maybe 6 instead of the normal 5 clocks.  Not sure about this
though...

> Everytime I came up with a theory about how this trick works and
> did some tests to verify this theory, I got some strange results,
> that just wouldn't fit in.

I know what you mean!!!

> >P.S. I've been running unstable.bin for around 10-15 minutes, and the E
> >letters are beginning to fade to completion!  So they DO show up.
> 
> That is strange! I have unstable.bin running on my PAL VCS jr.
> for 40 minutes now and there is absolutely nothing fading in.

I guess I'm not surprised.  So I guess what you can see is 17 sprites. 
What unstable is demonstrating is that sometimes instead of generating
just two trailing sprites, a RESPx can generate a blank sprite in the
first position overwriting the trailing sprite from a prior RESPx.  This
happens when you try to get two sprites of the same color too close
together by doing a RESPx to the same color too soon following a prior
RESPx.

Glarg! My head is spinning!

BTW, I hope you forgive me for constantly hacking apart your program!

John

Attachment: Latehit.bin
Description: Binary data

Attachment: evenodd.bin
Description: Binary data

Current Thread