help with sprite Priority bit?

[eddhell]

Does the priority bit on sprites work differently in Color Stack mode from FG/BG mode?   Or (more than likely) am I misunderstanding how "priority" works on the Inty?

I want to put four player sprites (1 through 4) BEHIND sprite # 6, with the foreground of #6 covering the others and the background transparent so the exposed parts of the player sprites show through...

I thought all I had to do was set the PRIORITY bit on the last argument of SPRITE 6 (hence the 2 bit in '$28F0').  I've also tried many variations, can't come up with anything that works...I'm sure it's something simple that i'm doing wrong, or just not possible how i want it....

 

    SPRITE 1, $0200 + table_x(plyloc(0)), $0100 + table_y(plyloc(0)), $0868 + plycol(0)
    SPRITE 2, $0200 + table_x(plyloc(1)), $0500 + table_y(plyloc(1)), $0868 + plycol(1)
    SPRITE 3, $0200 + table_x(plyloc(2)), $0100 + table_y(plyloc(2)), $0870 + plycol(2)
    SPRITE 4, $0200 + table_x(plyloc(3)), $0500 + table_y(plyloc(3)), $0870 + plycol(3)
    SPRITE 6, $0600 + (table_x(62)-4), $0100 + table_y(62), $28F0

 

...and all 4 player sprites are on TOP of foreground of #6....Does order matter?  doesn't seem to...

 

(I know someone will probably point out that all four player sprites overlap anyway, but each one is just a different 4x4 corner of each 8x8 sprite, so they all show when stacked on same coordinates)

Edited December 11, 2019 by eddhell

[mr_me]

My understanding is that turning the priority bit on puts the sprite behind the background pixels.

[skywaffle]

The sprite "priority" over other sprites is determined by the sprite number.  Sprite 0 stays on top of all other sprites, sprite 3 will overlap 4-7, etc.

[intvnut]

10 hours ago, skywaffle said:

The sprite "priority" over other sprites is determined by the sprite number.  Sprite 0 stays on top of all other sprites, sprite 3 will overlap 4-7, etc.

That's correct.

 

The priority bit is a little odd:  It determines if a given sprite is in front of or behind the background pixels.  But, it does not change its ordering with respect to the other sprites.  You might be wondering how that works.

 

First, the sprites are stacked on top of each other with 0 in front, 7 in back.  Then, for each given pixel of the result, that pixel either goes in front of or behind the background based on whichever sprite was "front-most" in the stackup of sprites.

 

This can lead to weird paradoxes.  For example, suppose MOB #0 is a horizontal bar, and MOB #1 is a vertical bar, and they overlap like this:

   111
   111
   111
00000000
00000000
   111
   111

 

All fine and dandy.  Now suppose I set both #0 and #1 to be "behind" the background, and I overlap the bottom right corner with background pixels 'b':

   111
   111
   111
00000000
0000bbbb
   1bbbb
   1bbbb
    bbbb

So far, so good.  Now let's say I change #1 to be "in front of" the background.  The image becomes:

   111
   111
   111
00000000
0000bbbb
   111bb
   111bb
    bbbb

Weird, huh?

[eddhell]

16 hours ago, skywaffle said:

The sprite "priority" over other sprites is determined by the sprite number.  Sprite 0 stays on top of all other sprites, sprite 3 will overlap 4-7, etc.

I actually thought that might be the case, but wasn't around today to try it...

so if I just switch from sprite #6 and make it sprite #0, all should be well!!

[+Lathe26]

Minor: If you want to play around with the priority bit, check out Color Stack Fiddler at

 

[Walter Ives]

On 12/11/2019 at 5:14 PM, intvnut said:

The priority bit is a little odd:  It determines if a given sprite is in front of or behind the background pixels.  But, it does not change its ordering with respect to the other sprites.  You might be wondering how that works.

    You've got the how, here's the why. The pixels being shifted out of the eight moving object shift registers are fed into a priority encoder to produce a three-bit value that corresponds to the object number of the highest priority object appearing at that bit position. That value is used as the address bits for a four-bit-wide multiplexor which selects the object color to be used. However, if the highest priority object's background priority bit is set and the background pixel being displayed is a one then the background color is selected instead.

    Harrower and Maine were well aware of the seemingly paradoxical behavior of this mechanism. Implementing a circuit that cascaded down to determine and display the highest priority object with a pixel at this position that had its background priority bit set wasn't near worth the number of transistors that would have been required. The only weirdness at play here was that Harrower, who was after all a Scot, was cognizant of the drumbeat heralding the approach of the delivery deadline and thus did go about, thrice and thrice and thrice again, to wind up the charm he was using to conjure up the device.

 

    WJI