Is a multicolored score possible?

[rollins215]

Hello all, I'm new to batari basic and am working on my first project. One thing I'd really like to do is to use the scoreboard to keep track of 2 different scores, one for each player. I was able to do this by adding a blank to score_graphics.asm, but I haven't been able to find a way to have the score digits have different colors. Is this possible to do? It doesn't appear to be looking at the online documentation so I was wondering if there is an include file or something that can be hacked to accomplish this. I'd like the score for each player be the same color as their onscreen counterpart.

 

Thanks for any help!

[SeaGtGruff]

Hello all, I'm new to batari basic and am working on my first project. One thing I'd really like to do is to use the scoreboard to keep track of 2 different scores, one for each player. I was able to do this by adding a blank to score_graphics.asm, but I haven't been able to find a way to have the score digits have different colors. Is this possible to do? It doesn't appear to be looking at the online documentation so I was wondering if there is an include file or something that can be hacked to accomplish this. I'd like the score for each player be the same color as their onscreen counterpart.

If you're going to have two blanks in the middle of the score to create two separate two-digit scores, then you might be able to create a custom kernel that changes the player0 and player1 colors while the score is being displayed. I'll look into it tonight.

 

Michael

[Nukey Shay]

Dunno about Batari Basic, because I have zero experience with it. But it's accomplished in assembly by setting bit 1 on (and bit 2 off) in CTRLPF. The playfield-score on following scanlines will use COLUP0 and COLUP1's colors on the left and right halves of the screen - regardless of what COLUPF holds.

[SeaGtGruff]

Dunno about Batari Basic, because I have zero experience with it. But it's accomplished in assembly by setting bit 1 on (and bit 2 off) in CTRLPF. The playfield-score on following scanlines will use COLUP0 and COLUP1's colors on the left and right halves of the screen - regardless of what COLUPF holds.

Yes, but that's when the playfield pixels are used to display the score, whereas bB displays the score using the players. Actually, it might be nice to make a custom kernel that displays two scores using playfield pixels, which simultaneously using the players to display the number of lives remaining.

 

Michael

[+batari]

There have been requests for two 3-digit scores before and they have been on the todo list since late 2005. I just haven't done anything about it

 

Michael, if you write a working two 3-digit score minikernel, I'll see what I can do to support it formally.

[SeaGtGruff]

There have been requests for two 3-digit scores before and they have been on the todo list since late 2005. I just haven't done anything about it

 

Michael, if you write a working two 3-digit score minikernel, I'll see what I can do to support it formally.

I had a thought a little while ago, but I don't know how well it could work, due to the score being off-center. My thought is to do the score digits with INVERSE graphics, so that the background and/or playfield shows through where the digits would be, and the scorecolor is the "background" color for the digits. Then the playfield could be displayed using "score mode," so that the left three digits are in the player0 color, and the right three digits are in the player1 color.

 

An alternative would be to let the score digits be displayed normally, but have the playfield as a background color, using the score mode.

 

Both ideas hinge on the score being centered, though. On the other hand, another alternative might be to fiddle with the background and playfield colors, so that the background color is set to the player0 color, and the playfield color is set to the player1 color (or vice versa), combined with either normal or inverse score graphics.

 

Aside from those ideas, we could try writing different types of score mini-kernels, such as two three-digit scores, but with the digits spaced apart (P0__P0__P0____________P1__P1__P1), or two or three two-digit scores (either P0P1____P0P1 or P0P1____P0P1____P0P1).

 

Michael

[supercat]

I had a thought a little while ago, but I don't know how well it could work, due to the score being off-center. My thought is to do the score digits with INVERSE graphics, so that the background and/or playfield shows through where the digits would be, and the scorecolor is the "background" color for the digits. Then the playfield could be displayed using "score mode," so that the left three digits are in the player0 color, and the right three digits are in the player1 color.

 

The 2600 doesn't really implement sprite priority, but rather color priority. The P0 color has the highest priority; then P1 color; then PF color. The BK color appears by default when nothing else does. The "playfield priority" mechanism works by blanking the P0 and P1 sprite colors anyplace the playfield or ball is present.

 

In Score mode, since the left half of the playfield is drawn with P0, it has highest priority (shared with P0). The right half of the playfield shares its priority with P1. The Ball appears behind those. Note that Z26 has not, and probably still does not, handle this correctly.

 

Incidentally, when using score mode, the playfield color of the last tiny little bit (about half of a normal pixel) of the left half of the playfield is indeterminate. Normally, pixel boundaries are generated precisely since the TIA uses a synchronizing latch. Normally, the logic that controls pixel data will only switch during the second half of a pixel time, while the final output latch will only switch in the first half. Thus, the final latch will show during each pixel time whatever the final latch held at the end of the previous pixel time. There's one exception, though: the signal that ends the left half of "score" mode happens somewhat earlier in a pixel than most other changes. Consequently, the pixel color will change just as the "latch-enable" signal is going away. Depending upon temperature, phase of the moon, etc. the latched data may be garbage.

[CurtisP]

There have been requests for two 3-digit scores before and they have been on the todo list since late 2005. I just haven't done anything about it

 

Michael, if you write a working two 3-digit score minikernel, I'll see what I can do to support it formally.

 

I would be happy with a two digit dual score minikernal. Seems this would be mush easier anyway. I'm just not comfortable with trying to write a minikernal yet.

[SeaGtGruff]

My thought is to do the score digits with INVERSE graphics, so that the background and/or playfield shows through where the digits would be, and the scorecolor is the "background" color for the digits. Then the playfield could be displayed using "score mode," so that the left three digits are in the player0 color, and the right three digits are in the player1 color.

 

The 2600 doesn't really implement sprite priority, but rather color priority.

Yes, that was one of my dumber ideas.

 

Michael

[supercat]

Yes, that was one of my dumber ideas.

 

The idea of using sprites to blank out playfield/background is a good and useful one in some circumstances, actually. If you need to do a 3x2 digit kernel with different colors for the three pairs of digits, you can set the sprite color to match the background and then have the playfield be displayed "behind" the sprites. Changing the color of a pair of digits will thus require only one write to COLUPF instead of two writes (to COLUP0 and COLUP1). Ruby Runner pushes the concept even further, using VBLANK as well to mask out the areas of the screen not covered by sprites. That technique allows it to independently make each sprite be one of two colors, set on a per-line basis (half the scan lines use blue and yellow; half use red and green).

[rollins215]

Looks like I'm not alone in wanting to change the score! Michael, any direction you can give me to modify the kernel would be great, I don't mind getting my hands dirty...that's how I learn.

 

While we're discussing things we'd like to do with the score, what would it take to move it to the top of the screen instead of the bottom?

 

-Manny

Edited May 15, 2007 by rollins215