Jump to content
IGNORED

Displaying Two Six Digit Scores


 Share

Recommended Posts

Easiest would be to use flicker and draw the scores on alternating frames. You can see that done in Pleiades.

 

Left frame:

post-3056-0-68120300-1468709112_thumb.png

 

Right frame:

post-3056-0-35515800-1468709117_thumb.png

 

with phosphor on:

post-3056-0-52218200-1468709120_thumb.png

Omegamatrix created the awesome method that I used in Space Rocks, you can read about it in this topic. While I implemented it using DPC+, his original example is a stock 4K ROM.

Link to comment
Share on other sites

So..

 

I didn't see any flicker in Pleiades so that looked good. Interesting game. It reminded me of the old LED handheld games the way the enemies moved.

 

The Omegamatrix version looked even better to me. I envisioned having the scores being displayed on a scoreboard at the top of the screen so I think that presents two problems- first- I'd have to insert the positioning code in the kernal, after the score, for the players. I think that is easy to overcome by skipping one or two lines of kernal update. But secondly, the scoreboard graphics. It looks like there won't be room for anything like that.

 

So is his Two Scores.zip code usable as is? It looks like it will only display eights and then other code might be used to mask out parts. Is that correct?

Link to comment
Share on other sites

Pleiades uses quite a bit of flicker. Stella has the game it's in database, so knows to turn on phosphor mode to suppress it. It's noticeable on real hardware, but not annoyingly so.

 

 

Right, the routine always shows 8 for the digits. The playfield needs to be set with priority over the players, then you need to add logic to figure out which playfield pixels need to be turned on so they hid the segments that should not be displayed. Once you get that working you need to set the playfield to the same color as the background so you don't see it anymore.

 

You can see that in action in Space Rocks:

post-3056-0-23745400-1468771167_thumb.png

 

by turning on the debug colors:

post-3056-0-32723600-1468771172_thumb.png

  • Like 1
Link to comment
Share on other sites

Thanks..

 

I think I figured out a way to work it in.. So I'm going through the code now. I've never seen a:

 

nop $EA

 

I know nop, but not nop $EA

 

I did find: The official NOP ($EA) and six unofficial NOPs do nothing, but they are useful for watermarking your binary (or, with some debugger+assembler combinations, defining breakpoints). You can have a preprocessor insert a randomly chosen NOP at random points in a non-time-sensitive subroutine.

 

Hmm. What is it doing here? Just a watermark? What for?

Link to comment
Share on other sites

Execution of NOP takes two clock cycles. It is done to keep in sync with the beam. Best seen if you run the code in the debugger of stella and single-step through it.

 

Sure.. nop. But what about nop #$EA? What's the difference?

 

By the way. I've seen your Ultimate Talk on YouTube. Its Excellent.

Link to comment
Share on other sites

Thanks!

 

If it's NOP $EA and not NOP #$EA, then it's about wasting three cycles, not two. I'd prefer BIT $EA. If it's really NOP #$EA, I can only guess: maybe it's about wasting an extra byte of rom.

 

If you want to read about "creative" wasting of clock cycles, I suggest looking at this article, I once wrote.

  • Like 1
Link to comment
Share on other sites

Hmm. The score is not showing up. Looking at the debugger, my score code seems to be showing up in the wrong place.

 

Well I guess I was compiling incorrectly. The symbol? file wasn't getting updated.

 

So I finally got it to work. I left out:

 

lda #3 ; 3 copies close

sta NUSIZ0

sta NUSIZ1

 

Though I am surprised that absolutely nothing showed up as a result. According to the debugger, RESP0 and RESP1 were happening on visible part of the scanlines.

Link to comment
Share on other sites

Pleiades uses quite a bit of flicker. Stella has the game it's in database, so knows to turn on phosphor mode to suppress it. It's noticeable on real hardware, but not annoyingly so.

 

 

Right, the routine always shows 8 for the digits. The playfield needs to be set with priority over the players, then you need to add logic to figure out which playfield pixels need to be turned on so they hid the segments that should not be displayed. Once you get that working you need to set the playfield to the same color as the background so you don't see it anymore.

 

You can see that in action in Space Rocks:

attachicon.gifspacerocks20121129_NTSC.png

 

by turning on the debug colors:

attachicon.gifspacerocks20121129_NTSC_1.png

I first thought it worked by drawing the sprites first, and then RESP0 and RESP1 both over and the and then draw the other sprites. Using RESPx I did remember might not line up to the sprite update beam. But the using the priority bit and using the playfield to mask the sprites is a wonderful idea.

  • Like 1
Link to comment
Share on other sites

Wow- having this routine at the top of the screen is sure going to be a lot harder than at the bottom. I wonder if its worth it. To get the players ready, I'll have to add up the cycles of two positioning routines- one of which runs through 5 times. I have seven scan lines of repeating playfield data where I think I can make the jsr. Anybody have any better ideas?

Link to comment
Share on other sites

Alright.. Got most of the kinks worked out. I like it!

 

post-44582-0-97143400-1468895604_thumb.jpg

 

I took the positioning routine and split it in half. The vertical part runs as normal in the vertical blank. But I split the horizontal portion out into its own separate subroutine that is called from the kernel.

 

By the way Darrell, I saw your presentation on YouTube as well. Also excellent!

Link to comment
Share on other sites

But I split the horizontal portion out into its own separate subroutine that is called from the kernel.

Do note that if you're calling PosObject from inside the Kernel that it can take an extra scanline when positioning objects on the rightmost side of the screen, that'll cause the display to jitter as objects move into and out of the right side. If you're restricting the objects to stay within that "yellow box" you might be OK.

 

 

By the way Darrell, I saw your presentation on YouTube as well. Also excellent!

Thanks!
Link to comment
Share on other sites

Thanks, I have a few things going on that you can see here:

 

1. When player 0's previous move was left, the spacing of the score changes.

2. When player 0 is on the right edge of the screen, the bottom of the playfield shifts down a line.

3. Shearing of the ball.

4. I have one of those black (white here) lines on the left side of the screen. I'm kind of proud of that one- a mark of my advancing programming skill :)

 

 

post-44582-0-86754200-1468936959_thumb.jpg

Edited by BNE Jeff
Link to comment
Share on other sites

1. When player 0's previous move was left, the spacing of the score changes.

REFP0 and REFP1 need to be set to certain values for that score routine to work, your movement routine is probably changing them. If so, change your movement routine to save the value into RAM instead, then use the RAM value to update REFP0 and REFP1 after the score is displayed.

 

On that note, in case you didn't see it before, by turning REFP1 ON the score kernel can be more efficient (use less cycles).

 

2. When player 0 is on the right edge of the screen, the bottom of the playfield shifts down a line.

That would be the extra scanline I mentioned.

 

3. Shearing of the ball.

Are you using VDELBL (vertical delay) for fine-tuning the vertical position of the ball? If not, try turning it on as that'll delay the update of the ball until player1 is updated. That might may resolve the shearing, though the ball will shift down a scanline.

 

4. I have one of those black (white here) lines on the left side of the screen. I'm kind of proud of that one- a mark of my advancing programming skill :)

:thumbsup:
  • Like 1
Link to comment
Share on other sites

Alright...

 

VDELBL did the trick.

 

And you're right about reflecting the player. I just disabled it for now and the score stays where it should. As far as turning on REFP1 on to make the score kernal more efficient, I wasn't understanding that thread fully- looks like alot of LSBs and MSBs and taking out an ASL LSR.. going to take some concentration.

 

Is the extra scan line curable? That player is updated at the beginning of line 1, well before the beam reaches the end- so I'm not sure that it is.

Edited by BNE Jeff
Link to comment
Share on other sites

It looks like you're on your way! Just so you know what I posted was the just the base of routine. You need to add in the playfield writes to make it work.

 

Yup- I did realize that. So long as the playfield stuff will fit in between the existing kernal code- which I think is the case. The even more complicated code will be translating numbers into graphics I think. If I'm understanding my first read through that thread, it looks like each PF will hold three digits' vertical lines. I think Darrell was linking PF2 and PF1 together as LSB and MSB for some clever reason. I really have little idea of how to do that part yet.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...