6 replies to this topic

[jrok]

I've been searching for an explanation of pixel positions for the copies produced by NUSIZx registers, specifically when it comes to NUSIZx=x3.

From what I can gather, the copies produced are as follows, at 8 pixels per character:
X.X.X.....

In the above, which of the three "X" characters represents the true registration point of playerx? How would I go about determining the registration point of the rightmost copy? Is there a forum thread I've missed that discusses the Number property of NUSIZx in detail?

Thanks in advance,
Jarod.

[cd-w]

jrok, on Mon Jan 19, 2009 2:56 PM, said:

I've been searching for an explanation of pixel positions for the copies produced by NUSIZx registers, specifically when it comes to NUSIZx=x3.

From what I can gather, the copies produced are as follows, at 8 pixels per character:
X.X.X.....

In the above, which of the three "X" characters represents the true registration point of playerx? How would I go about determining the registration point of the rightmost copy? Is there a forum thread I've missed that discusses the Number property of NUSIZx in detail?

Thanks in advance,
Jarod.

It is explained in the Stella programmers guide. Each square in the table is 8 clocks (i.e. 8 pixels), so with NUSIZ=3 the rightmost copy will start 32 pixels to the right of the initial sprite position.

Horizontal sprite positioning is always performed with respect to the left most sprite (when there are multiple copies). There is a good tutorial on horizontal sprite positioning, and there are some additional gotchasto look out for. In particular, there is a delay between hitting RESx and the actual sprite position. This delay is 4 pixels for missiles and the ball, 5 pixels for single-width players, and 6 pixels for double- and quadruple-width players.

Chris

Edited by cd-w, Thu Feb 12, 2009 7:44 AM.

[SeaGtGruff]

As supercat pointed out to me, the three lowest bits of NUSIZx correspond to the different copies of a player:

bit 0 = the copy closest to the player
bit 1 = the copy in the middle
bit 2 = the copy farthest from the player

In other words:

aaaaaaaa		bbbbbbbb		cccccccc		dddddddd		eeeeeeee

where aaaaaaaa, bbbbbbbb, cccccccc, dddddddd, and eeeeeeee are 8 color clocks wide, with 8 color clocks between them.

aaaaaaaa is the player, which is always "on" (unless you set all of its bits to 0 in the GRPx register).
bbbbbbbb is the copy that's closest to the player, which can be turned on or off by setting bit 0 of NUSIZx to 1 or 0.
cccccccc is the middle copy, which can be turned on or off by setting bit 1 of NUSIZx to 1 or 0.
dddddddd isn't a copy-- I just put it there as a kind of "place holder," to help show the spacing between the copies.
eeeeeeee is the copy that's farthest from the player, which can be turned on or off by setting bit 2 of NUSIZx to 1 or 0.

This makes it easy to remember which values to use to get the results you want, as follows:

%00000000 = no copies, just the player by itself (aaaaaaaa).
%00000001 = 1 copy, placed closest to the player (aaaaaaaa and bbbbbbbb).
%00000010 = 1 copy, placed midway from the player (aaaaaaaa and cccccccc).
%00000100 = 1 copy, placed farthest from the player (aaaaaaaa and eeeeeeee).
%00000011 = 2 copies, at the "near" spacing from the player (aaaaaaaa, bbbbbbbb, and cccccccc).
%00000110 = 2 copies, at the "middle" spacing from the player (aaaaaaaa, cccccccc, and eeeeeeee).

These are the legal combinations that give you a normal-sized player, with or without any copies of the player. But there are 8 possible values for a 3-bit number. The other two values are as follows:

%00000101
%00000111

If %00000101 were "legal" for turning the copies on and off, it should turn on the bbbbbbbb and eeeeeeee copies. But the player and any copies need to be equally spaced. Since aaaaaaaa, bbbbbbbb, and eeeeeeee aren't equally spaced, that's an "illegal" value as far as getting multiple copies of a player are concerned.

Likewise, if %00000111 were "legal" for this purpose, it should turn on the bbbbbbbb, cccccccc, and eeeeeeee copies. But again, aaaaaaaa, bbbbbbbb, cccccccc, and eeeeeeee aren't equally spaced, so that's another "illegal" value for getting multiple copies of a player.

Fortunately, rather than "waste" these two "illegal" values, Atari gave them a different sort of meaning:

%00000101 = no copies, just the player by itself, but it's twice as wide as usual.
%00000111 = no copies, just the player by itself, but it's four times as wide as usual.

Michael

[grafixbmp]

In games like space invaders, what exactly is done to properly know one sprite( missle or ball) has correctly made contact with, not the original p0 or p1 but either copy 1 or copy 2 of either one? Is this a case of where contact is always made no matter what and the postion of the missle or ball is what distinguishes which player has been hit?

[Nukey Shay]

A common misconception is that Space Invaders is using the missile sprites. It's not. All 4 are made by using the ball on alternating frames. So all that needs to be done is to check the framecounter for which of the "missiles" we are dealing with at the time...and the kernel is less complicated because it only needs to track 1 object as opposed to 2 or 4.

Anyway to answer your question, it's math. Subtract the hit object by the ball's horizontal, then divide by the number of pixels between objects to produce the invader hit. Or more exactly, it does less than the full spacing to get the bit position of the invader hit IIRC (Space Invaders could only ever have 6 invaders per row, which fits in nicely into a single byte)...when all invaders are shot from the left column, all other columns move over to eliminate it from the equasion by ROLing their corresponding bits higher).

Edited by Nukey Shay, Fri Feb 13, 2009 12:12 PM.

[supercat]

Nukey Shay, on Fri Feb 13, 2009 12:04 PM, said:

...when all invaders are shot from the left column, all other columns move over to eliminate it from the equasion by ROLing their corresponding bits higher).

BTW, one of my peeves with Space Invaders for many years (long before I had any clue how the 2600 actually worked) that the last invader on a row produces no explosion. I wonder why the row is skipped, rather than drawn with blank invaders plus an explosion?

[Nukey Shay]

It actually depends on which line is involved. If it's the lowest one that has all the invaders shot, the line is no longer being dealt with - for anything. All bits are zero, so the byte is zero (and subsequently skipped in the display). It's tricky, but you can get invaders to move into your shots to see an example of this. An empty line (the last shot invader) above a non-empty line will still produce the explosion effect.

Additionally, the animation frames are not kept track of. Just the framecounter itself. So it has a 1 in 4 chance of being the correct one from the start...sometimes missed entirely regardless of where it is.