Playfield Score Mode - effect on ball

[Devin]

Hey, I have a quick question regarding the "score" flag in CTRLPF. If I set the D1 bit to 1, the left side of the playfield will use the player 0 color, the right side will use player 1.

 

Will the ball color be affected? Or will is still use the COLUPF color?

[+Random Terrain]

Hey, I have a quick question regarding the "score" flag in CTRLPF. If I set the D1 bit to 1, the left side of the playfield will use the player 0 color, the right side will use player 1.

 

Will the ball color be affected? Or will is still use the COLUPF color?

If it works the same as batari Basic, the ball isn't affected:

 

devin_ball_test_2010y_07m_17d_1210t.bin

[+SpiceWare]

on actual hardware:

[Devin]

Hey, I have a quick question regarding the "score" flag in CTRLPF. If I set the D1 bit to 1, the left side of the playfield will use the player 0 color, the right side will use player 1.

 

Will the ball color be affected? Or will is still use the COLUPF color?

If it works the same as batari Basic, the ball isn't affected:

 

devin_ball_test_2010y_07m_17d_1210t.bin

 

Excellent. Thank you!

[Omegamatrix]

Yeah, the Stella Programmers Guide doesn't explicitly tell you this, but when you enable score mode the color of the ball is still controlled with COLUPF, while the playfield takes it's colors from COLUP0 and COLUP1.

 

 

You can do some fancy tricks with this. One that springs to mind is doing a highlight during a six byte display kernel. Just fill in the PF around the display, enable score and reflect, and invert your graphics (before hand) so that the background is the area that draws the digits. You then hmove the ball every line and you get a nice little shine effect! I believe this is how Supercat worked his magic in Strat-O-Gems. I'd have to take a look in Stella's debugger to be sure though.

[doppel]

But which one has priority, the playfield or the ball?

[Omegamatrix]

But which one has priority, the playfield or the ball?

The playfield has priority over the ball in score mode.

[+batari]

One warning is that score mode has a glitch at the center of the screen on real hardware if you use the centermost pixels on either side.

 

Try RT's demo on real hardware to see what I mean (I haven't tried his demo but I've seen the glitch in similar situations.)

[+batari]

I tried in real hardware and although I saw it, the glitch is very subtle because of the light colors. I think what is happening is a thin line between the two halves of the playfield is affected by the COLUPF in a strange way.

 

I did find a binary that exhibits the behavior in a more obvious way, however - a WIP version of "Matchie" by Supercat, found here:

http://www.atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=76008

[supercat]

The playfield has priority over the ball in score mode.

 

To be hyper-precise, Score Mode causes the player 0/1 color circuits to be activated anyplace the playfield is active. When sprites have priority over playfield, this "covers up" the playfield color there. If playfield priority is enabled, the activated 0/1 colors get overruled by the playfield color, rendering score mode ineffective. Note that in score mode, the left half of the playfield has priority over the player/missile 1 sprites.

[supercat]

I tried in real hardware and although I saw it, the glitch is very subtle because of the light colors. I think what is happening is a thin line between the two halves of the playfield is affected by the COLUPF in a strange way.

 

What's happening is a race condition between disabling the player 0 color and enabling the player 1 color. Normally, race conditions are avoided by having a color latch which holds the previous pixel's color while the present pixel's color is determined. The signal which determines whether to use the left- or right-side color, however, changes state on the opposite clock edge from everything else, when the output latch is transparent.