CTRLPF Split Colors & Sprites Behind Playfield

[KevKelley]

I had been playing around with some ideas and decided to use CTRLPF=$03.  

 

I had Player0 sprite and Player1 sprite on opposite sides of the screens when I noticed that the Player1 sprite goes behind the playfield on the left.  I assume that since the playfield is split with the colors of the players, the playfield retains those properties? I noticed if I did something else, like CTRLPG=$00, Player1 would not go behind the playfield.

 

So I guess my question is if it is possible to have both sprites be capable of being above the playfield? Or am I missing something?

[CapitanClassic]

Not sure exactly what you are trying to do in bBasic. When using the virtual sprite kernel (DPC+), many of the normal sprite control registers don’t work with the virtual sprites.

The CTRLPF register should only switch the priority of the Playfield/Ball to either be before or after both player/missile sprites. It shouldn’t be possible for you to have one be in front land the other behind. Not sure what the colors have to do with anything? (Are playfield colors use the P0/P1 colors on the Left/Right side of the screen? Maybe those two registers are incompatible (on incompatible in bBasic/DPC+). Combat only keeps the player colors at the top of the screen for the scores, when it gets to the normal Arena Kernel it turns off the Pfield=player color register.

 

 

from the Stella Programs Guide.

https://cdn.hackaday.io/files/1646277043401568/stella.pdf

Quote

9.0 Object Priorities
Each object is assigned a priority so when any two objects overlap the one with the highest priority will appear to move in front of the other. To simplify hardware logic, the missiles have the same priority as their associated player, and the ball has the same priority as the playfield. The background, of course, has the lowest priority. The following table illustrates the normal (default) priority assignments.
Priority   Objects
1 P0, M0
2 P1, M1
3 BL, PF
4 BK
This priority assignment means that players and missiles will move in front of the playfield. To make the players and missiles move behind the playfield, a "1" must be written to D2 of the CTRLPF register. The following table illustrates how the priorities are affected:
Priority   Objects
1 PF, BL
2 P0, M0
3 P1, M1
4 BK
One more priority control is available to be used for displaying the score. When a "1" is written to D1 of the CTRLPF register, the left half of the playfield takes on the color of player 0, and the right half the color of player 1. The game score can now be displayed using the PF graphics register, and the score will be in the same color as its associated player.

 

[KevKelley]

I was using standard kernel. I had noticed that if I use a normal background both P0 and P1 are above the playfield. But I noticed when split, P1 is behind the playfield. I'll see if I can post a pic soon.

[KevKelley]

Here is a picture of the Playfield, Missiles, Ball, P0, and P1.  I labeled the players at the top of the picture.  As you can see, the one on the left goes behind the Playfield.

[KevKelley]

My assumptions were that in bB, when using CTRLPF=$23, since it splits the screen colors with those of the players, it also takes the priorities of the players with it.  

[alex_79]

It doesn't depend on bBasic, that's how the TIA works. In score mode (CTRLPF bit 1 set), the left half of the PF takes color and priority of P0/M0, while the right half takes color and priority of P1/M1. The ball keeps normal priority (behind both players/missiles)

Also note that if the playfield priority bit is set (CTRLPF bit 2), the score mode bit is ignored.

 

[KevKelley]

Ah. I didn't understand all that. I thought that was part of bB. I was thinking the split option was a bB thing.

 

I guess I'll have to do a work around. Thanks a lot guys! ?

Edited December 9, 2020 by KevKelley

[freshbrood]

So are either both p0 and p1 behind or in front of the playfield at the same time?

 

Is is possible to have only one in front while the other is behind?