23 replies to this topic

[Omegamatrix]

A few years ago I wrote a 7 byte score display for a game I was working on. Time went by and the game got forgotten, but recent thoughts on using TIM1T as a storage container reminded me of where I first used the trick. I decided to strip score display out of my game and make it available to everyone.


The motivation behind the display is that I always wanted to have a score go from 0 to 9,999,999 on the Atari. I wanted to have no flicker in the score, any background color, and regular sized digits. This routine accomplishes all these things, and has a small library of different fonts you can choose from for the digits. You can also custom build your own fonts and add them to the library with an included excel sheet.


The program uses a lot of rom because it doesn't loop... It could easily be made to loop with DPC+, but I don't have the time to take that on. Looping would cause some incompatibilities with a couple of the fonts in the library (two for digit 2, and one for digit 7). Still DPC+ would be good for handling this routine.


Please feel free to use code in any shape or form, modify it, make it better, and so forth. I hope you enjoy my little demo!

Cheers,
Jeff





 SevenFullSizedDigits.zip   41.86K   11 downloads

[Random Terrain]

Speaking of the score, I always wanted to have commas in the score. Has anyone ever done that?

[SpiceWare]

Nice!

I'd just posted a blog entry for score kernel suggestions, think this might be a way to get what I'm after. By using narrower digits (say 4or 5 pixels with 1 pixel spacing) I should be able to get a decent sized score, plus have some room to graphically showing lives remaining for both players.

[SpiceWare]

Random Terrain, on Sun May 20, 2012 9:17 PM, said:

Speaking of the score, I always wanted to have commas in the score. Has anyone ever done that?

Hmm. For a 6 digit score, do this:

• design the digit graphics with just 5 or 6 pixels across (instead of the usual 7)
  
• position the ball to draw the comma
  
• turn on the ball when there's just 2 scanlines left of the score to draw
  
• HMOVE the comma 1 pixel left after the last line of the score is drawn
  
• show the ball just 1 additional scanline to get a single pixel offset from the previous 2.

Using this 7 digit score you'd need an extra comma, so do this:

• do 1-5 as above, but using a missile as well as the ball
  
• draw a playfield on both sides of the score
  
• color the playfield same as the screen
  
• give playfield priority over other objects to hide the extra copies of the missile.

If you're doing leading zero blanking then an easy way to blank the commas would be to use the playfield to hide them - that would simplify the enable ball/missile logic as you'd just always enabled them when there's 2 scanlines left.

Another variation (for the 6 digit score) might be to use the usual 7-pixel digit graphics, but put the 1 pixel spacing on the right side of the left 3 digits and on the left side of the right 3 digits. This would create a 2 pixel gap, between the two groups of three digits, to put the comma in.

Edited by SpiceWare, Mon May 21, 2012 8:42 AM.

[Omegamatrix]

SpiceWare, on Mon May 21, 2012 8:24 AM, said:

Nice!

I'd just posted a blog entry for score kernel suggestions, think this might be a way to get what I'm after. By using narrower digits (say 4or 5 pixels with 1 pixel spacing) I should be able to get a decent sized score, plus have some room to graphically showing lives remaining for both players.

Have you considered doing some RESxx bashing, and then masking portions of the digits with the playfield? Thomas did this in his Sudoku Kernel. I think Supercat was the creator of this technique, but I couldn't find his "score16" routine anywhere. If someone could post a link I would love to see it. I think the idea of drawing the full digit and then masking it is absolutely brilliant. It's like a seven segment display.

Michael also had some great ideas for positioning GRPx objects here.


I wrote a small demo based off of these ideas. I'm not doing any of the masking, just trying to find some alignment... I'm off by two pixels on the right side, but it might not be too noticable. The ball and missiles are still free. Anyhow this might give you some ideas for building your routine without using any flicker.



 Two Scores.zip   1.96K   6 downloads

[SpiceWare]

Hmm, that has potential. I'll look into it tomorrow as I'm heading to bed. Thanks!

[Omegamatrix]

Had an idea. Did a second version. Added two more digits on sides. Nothing is optimized. Running out door. No more time.



 Two Scores2.zip   2.68K   5 downloads



Edit added wrong file. Re-uploaded.

Edited by Omegamatrix, Tue May 22, 2012 9:30 AM.

[SpiceWare]

Ooh - that's slick.

Doesn't look like there's time to change color between scores as you have to use that time to update the playfield. A way to help reinforce which score belongs to which player would be to draw a lines above and/or below each score using the playfield and and color them via SCORE mode.

Edited by SpiceWare, Tue May 22, 2012 9:37 AM.

[Omegamatrix]

SpiceWare, on Tue May 22, 2012 9:36 AM, said:

Ooh - that's slick.

Doesn't look like there's time to change color between scores as you have to use that time to update the playfield. A way to help reinforce which score belongs to which player would be to draw a lines above and/or below each score using the playfield and and color them via SCORE mode.

There is a possibility. Switch philosophies. Use both players and and Playfield as masks, I.e. inverted player graphics. Use score mode, but not priority. Make both player colors the same, and it colors the Playfield too. Then just update color for background. I tried to update background color last night. It was a few cycles too earlier. With score you could use the ball, have ball same color as left side digits. Might just make it by placing ball on last digit on left side. Leave ball enabled all the time. Cover up rest of background with Playfield.

I only had the last week for Atari. No more time left for me to program for next two months or so. I will enjoy the development of Space rocks though.

[SpiceWare]

Omegamatrix, on Tue May 22, 2012 10:28 AM, said:

There is a possibility. Switch philosophies. Use both players and and Playfield as masks, I.e. inverted player graphics.

Hmm - I've been reviewing the code to see exactly what's going on. Very clever use of the missiles (and player/missile overlap) to create the "lives" digit. I really want to show lives but, unless I'm missing something, I don't think the inverted technique is would be compatible with using the missiles.

Quote

I only had the last week for Atari. No more time left for me to program for next two months or so. I will enjoy the development of Space rocks though.

Thanks!

[Omegamatrix]

SpiceWare, on Tue May 22, 2012 4:31 PM, said:

Hmm - I've been reviewing the code to see exactly what's going on. Very clever use of the missiles (and player/missile overlap) to create the "lives" digit. I really want to show lives but, unless I'm missing something, I don't think the inverted technique is would be compatible with using the missiles.

No, you're right. I was thinking and typing real quick, and the more I thought about it today the more problems appeared (no to mention time to do all the updates!). To build inverted digits with the missiles you'll need three parts... left side, middle (this also is 3 pixels wide!), right side. This doesn't work well. Also there would be gaps around the sides of the end digits of the players gfx, and gaps in between them. This is too bad, because the ball would have nicely covered that last digit on the left side, and you wouldn't have to mess with the ball at all during the routine.


That routine was thrown together quickly this morning as I woke up with it in my head, and it was all clear. It was a real rush job of sloppy nops, Ha Ha, but the concept is there. I like the solution because in never uses HMOVE, thus no comb lines, thus any background color looks nice. It does use a bit more time as one of the missiles has to be re-sized, and the other enabled/disabled but the covering up of them is basically free since you have to update the playfield registers anyhow, and like you said the third copy overlaps one of the other digits so it hides itself.


I hope I gave you some decent ideas for Space Rocks Darrell! Looking forward to it!!
Cheers,
Jeff

[Random Terrain]

Omegamatrix, on Tue May 22, 2012 6:03 PM, said:

That routine was thrown together quickly this morning as I woke up with it in my head, and it was all clear. It was a real rush job of sloppy nops, Ha Ha, but the concept is there. I like the solution because in never uses HMOVE, thus no comb lines, thus any background color looks nice. It does use a bit more time as one of the missiles has to be re-sized, and the other enabled/disabled but the covering up of them is basically free since you have to update the playfield registers anyhow, and like you said the third copy overlaps one of the other digits so it hides itself.


I hope I gave you some decent ideas for Space Rocks Darrell! Looking forward to it!!

I love all of this brainstorming and cooperation.


New band name:

Rush Job of Sloppy Nops

[SpiceWare]

very promising. Main issue is it's taller than the original score routine, so the screen's now 271 scanlines instead of 262.


I can resize the side segments, if I bring it down to 263 scanlines the digits look too squished.


265 and 267 don't look too bad.


And here's 269, just for grins


Any preferences?

I'll need to decide how to compensate for that - shrink the playing area and/or shrink the Vertical Blank and Overscan areas. I could also drop the lower colored line, though I really like how that turned out. The upper colored line will stay no matter what as that's when the prep to display the score occurs.

After that I'll have to revise the routine to not use LDA #<SHAPE_DASH and LDA #<SHAPE_SIDES as that conflicts with the use of Fast Fetch mode (I've disabled Fast Fetch mode to get the initial routines working). Easy fix will be to put the figure 8 graphics into a data stream.

And finally I'll have to add some datastreams to control the playfields.

Edited by SpiceWare, Tue May 22, 2012 8:37 PM.

[Omegamatrix]

I think the 267 line display looks great. How big is your display, 192, 200 lines? I think the score font compliments the vector graphics nicely.


Also the borders are very sharp! I like that. Very intuitive.

[SpiceWare]

Yeah, I've been leaning towards using the 267 one. I started with 200, so it's now 205. I suspect it'll be just fine to shrink overscan by 5 scanlines.

[SpiceWare]

Finally got the score routine working, new builds are in my blog. 2 player routines aren't finished yet, so player 1's information is shown on both sides for testing. Left Difficulty set to A will display test digits instead. Score is not wiped out though, so switch back to B to show your current score.

I also changed the ship to Purple as it contrasts better with the green.


I tried to set it up as a loop, but was short 3 cycles.

		lax DS_PF0L_ENAM1   ; 4 62
		sta PF0			 ; 3 65
		ldy DS_NUSIZ0	   ; 4 69
		lda #<DS_SCORE8	 ; 2 71
loop:
		sta GRP0			; 3 74
		asl				 ; 2 76/0
		sta GRP1			; 3  3
		sty NUSIZ0		  ; 3  6
		stx ENAM1		   ; 3  9
		lda #<DS_PF1L	   ; 2 11
		sta PF1			 ; 3 14 - must be before 28 or after 65
		lda #<DS_PF2L	   ; 2 16
		sta PF2			 ; 3 19 - must be before 38
		sta RESP0		   ; 3 22 - must be at 22
		sta RESP1		   ; 3 25 - must be at 25
		sta RESP0		   ; 3 28 - must be at 28
		sta RESP1		   ; 3 31 - must be at 31
		lda #<DS_PF0R	   ; 2 33
		sta PF0			 ; 3 36
		lda #<DS_PF1R	   ; 2 38
		sta PF1			 ; 3 41
		lda #<DS_PF2R	   ; 2 43
		sta RESP0		   ; 3 46 - must be 46
		sta RESP1		   ; 3 49 - must be 49
		sta RESP0		   ; 3 52 - must be 52
		sta RESP1		   ; 3 55 - must be 55
		sta PF2			 ; 3 58
		lax DS_PF0L_ENAM1   ; 4 62
		sta PF0			 ; 3 65
		ldy DS_NUSIZ0	   ; 4 69
		lda #<DS_SCORE8	 ; 2 71
				bne loop  ; 3 74 - drat, don't have the 3 cycles for the branch :( 

For the moment I just repeat the section 11 times:

		repeat 11
		lax DS_PF0L_ENAM1   ; 4 62
		sta PF0			 ; 3 65
		ldy DS_NUSIZ0	   ; 4 69
		lda #<DS_SCORE8	 ; 2 71
		sta GRP0			; 3 74
		asl				 ; 2 76/0
		sta GRP1			; 3  3
		sty NUSIZ0		  ; 3  6
		stx ENAM1		   ; 3  9
		lda #<DS_PF1L	   ; 2 11
		sta PF1			 ; 3 14 - must be before 28 or after 65
		lda #<DS_PF2L	   ; 2 16
		sta PF2			 ; 3 19 - must be before 38
		sta RESP0		   ; 3 22 - must be at 22
		sta RESP1		   ; 3 25 - must be at 25
		sta RESP0		   ; 3 28 - must be at 28
		sta RESP1		   ; 3 31 - must be at 31
		lda #<DS_PF0R	   ; 2 33
		sta PF0			 ; 3 36
		lda #<DS_PF1R	   ; 2 38
		sta PF1			 ; 3 41
		lda #<DS_PF2R	   ; 2 43
		sta RESP0		   ; 3 46 - must be 46
		sta RESP1		   ; 3 49 - must be 49
		sta RESP0		   ; 3 52 - must be 52
		sta RESP1		   ; 3 55 - must be 55
		sta PF2			 ; 3 58
		repend

Edited by SpiceWare, Yesterday, 7:44 PM.

[SpiceWare]

dupe

Edited by SpiceWare, Yesterday, 7:44 PM.

[Omegamatrix]

You can gain 2 cycles by using REFP1 before the loop starts. Then you can use the same value for GRP0 and GRP1, and get rid of ASL and LSR. When you draw the sides the new value will be $22.


So down to 1 cycle now.

[Omegamatrix]

Darrell, do you have a Fast Fetch register available? I think you can store to NUSIZ0 earlier (I haven't tried). So, no need to use Y, use A and then load the graphics. Then you can do the loop and have a free cycle left too.

;old

#@58
  lax DS_PF0L_ENAM1 #4 62
  sta PF0		   #3 65
  ldy DS_NUSIZ0	 #4 69
  lda #<DS_SCORE8   #2 71
  sta GRP0		  #3 74
  asl			   #2 76/0
  sta GRP1		  #3  3
  sty NUSIZ0		#3  6

;new
#@61
  lax DS_PF0L_ENAM1 #4 65
  sta PF0		   #3 68
  lda <#DS_NUSIZ0   #2 70
  sta NUSIZ0		#3 73
  lda #<DS_SCORE8   #2 75
  sta GRP0		  #3 2
  sta.w GRP1		#4 6   1 free cycle

I'm using '#' to keep the spacing aligned in the code box.


Edit: # still didn't work. The forum software really screws the code box up.

Edited by Omegamatrix, Yesterday, 10:24 PM.

[SpiceWare]

Omegamatrix, on Thu May 24, 2012 9:44 PM, said:

So down to 1 cycle now.

Saved 2 more - getting rid of that ASL allowed me to use LDA #< instead of preloading with Y. This change is already in place and confirmed to work

		lax DS_PF0L_ENAM1   ; 4 65
		sta PF0			 ; 3 68
		lda #<DS_SCORE8	 ; 2 70
ScoreLoop:		
		sta.w GRP0		  ; 4 74
		sta GRP1			; 3 77/1
		lda #<DS_NUSIZ0	 ; 2  3
		sta NUSIZ0		  ; 3  6
		stx ENAM1		   ; 3  9
		lda #<DS_PF1L	   ; 2 11
		sta PF1			 ; 3 14 - must be before 28 or after 65
		lda #<DS_PF2L	   ; 2 16
		sta PF2			 ; 3 19 - must be before 38
		sta RESP0		   ; 3 22 - must be at 22
		sta RESP1		   ; 3 25 - must be at 25
		sta RESP0		   ; 3 28 - must be at 28
		sta RESP1		   ; 3 31 - must be at 31
		lda #<DS_PF0R	   ; 2 33
		sta PF0			 ; 3 36
		lda #<DS_PF1R	   ; 2 38
		sta PF1			 ; 3 41
		lda #<DS_PF2R	   ; 2 43
		sta RESP0		   ; 3 46 - must be 46
		sta RESP1		   ; 3 49 - must be 49
		sta RESP0		   ; 3 52 - must be 52
		sta RESP1		   ; 3 55 - must be 55
		sta PF2			 ; 3 58
		lax DS_PF0L_ENAM1   ; 4 62
		sta PF0			 ; 3 65
		lda #<DS_SCORE8	 ; 2 67
		bne ScoreLoop	   ; 3 70

[SpiceWare]

Omegamatrix, on Thu May 24, 2012 10:22 PM, said:

Darrell, do you have a Fast Fetch register available?

Yep - we had the same idea, this reply popped up while I was typing in mine with the new loop code

Quote

Edit: # still didn't work. The forum software really screws the code box up.

Yeah, it's aggravating at times.

[SpiceWare]

I added a new build using the loop to the blog entry. It's the version with the shorter colored lines around the score.

[SpiceWare]

Omegamatrix, on Mon May 21, 2012 9:44 PM, said:

I think Supercat was the creator of this technique, but I couldn't find his "score16" routine anywhere.

Found it, though there's a lineup issue. Possible it worked OK in an older build of Stella. I get the same glitch on my VCS.

[Propane13]

This might sound dumb, but for the commas, how would they look if they were drawn on the scanline after the nuimbers?

-John