Jump to content
IGNORED

7 Digit Full Sized Score Display


Recommended Posts

I sent Nathan a test build with the new sprites. They're rather blocky looking without the shifting, so I suspect the HMOVEs will not be going away.

 

I got to thinking that if I chopped 1 PF pixel out of the left player's area, to be balanced I should also chop one out of the right. This is what my current build looks like:

post-3056-0-39357200-1337991796_thumb.png

 

That bright pixel depends on what colors are chosen. Because of the way the Atari generates it's signal, some color transitions will cause an artifact color to appear between the two. I don't notice a 3rd color between purple and green, but I do with other transitions:

 

Jr Pacman - red shows up when going from brown to black

post-3056-0-42521500-1337992922_thumb.jpg

 

Adventure - red shows up when going from grey to purple, blue shows up when going from purple to grey, black shows up when going from purple to orange

post-3056-0-45821400-1337992927.jpg

 

Bowling - red shows up when going from orange to blue (this one's more noticeable on the screen than in the photo).

post-3056-0-01200400-1337992934_thumb.jpg

 

stephena's been working on adding this to Stella to make the emulation closer to the real thing.

Link to comment
Share on other sites

Since you're already squeezing out more than 48 pixel sprites, I've got one idea on what I want to do, but don't know how:

 

For an interactive eye-candy cartridge, I want to put the name in the top line on the left side for about 7 lines (48 pixel sprite), on the top right I want to display the configuration number: the same 7 lines with 8 bit data loaded from ram and precalc'ed elsewhere. For the ROM, I've got at least 1k to spare and about half of the RAM. The code should work without DPC+.

 

I wanted to adopt the 13plus2 routine from qotile, but it seems like it only works with static texts.

 

SpiceWare, Omagamatrix: any suggestions or examples to learn from?

Link to comment
Share on other sites

When you use the RESP trick with both sprites, they don't line up the same due to 1 machine cycle equaling 3 color clocks, such that 3 MCs equal 9 CCs-- you get a 1-pixel gap alternating with a 1-pixel overlap, since the two players are 9 pixels apart rather than 8 pixels.

 

As for the RESP trick itself, hitting RESP once on a line will reposition the player, but due to the way the player's position counter works you won't get the main copy of the player, just any extra copies you've enabled, because there's no signal to start drawing the main copy like there is for the extra copies-- instead, the main copy is triggered by when the position counter resets itself upon reaching the last count.

 

However, if you hit RESP twice on a line and the second RESP is hit while the signal to start drawing one of the extra copies is active, you will get the main copy in addition to the extra copies, because the start signal that was active when RESP was hit the second time triggers the main copy. (Actually, I suppose it's really an extra copy rather than the main copy, but in practical terms I think you can call it the main copy since it's lined up exactly where the main copy should be lined up, and is followed by all of the extra copies that you've enabled.)

 

Assuming you've got three copies with close spacing, you can get all three copies by hitting RESP, waiting 3 MCs, and hitting RESP again.

 

And since RESP takes 3 MCs, you can get three copies of player0 plus three copies of player1 by hitting RESP0, RESP1, RESP0, and RESP1 one after the other-- except the player1 shapes will be shifted right 1 pixel from where you'd want them to be for a standard score display. However, if you're going to have a blank pixel column in your digits anyway, you can make all the digits line up if you use two sets of digits-- one set for player0, right-justified within player0's 8 pixels (blank pixel in bit 7), and another set for player1, left-justified within player1's pixels (blank pixel in bit 0). That way both the 1-pixel gaps and the 1-pixel overlaps will coincide with the blank pixel columns in the score display.

 

As for actually displaying a score (or other text), the time spent hitting RESP will take away from any time you need for loading the digit shapes, so that might present some problems.

  • Like 4
Link to comment
Share on other sites

So if I understood that correctly, the <-- comments below explain how it's working?

 

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 <-- main copy not showing, triggers duplicates to show
	sta RESP1		   ; 3 25 - must be at 25 <-- main copy not showing, triggers duplicates to show
	sta RESP0		   ; 3 28 - must be at 28 <-- since duplicates are triggered, this triggers main plus duplicates
	sta RESP1		   ; 3 31 - must be at 31 <-- since duplicates are triggered, this triggers main plus duplicates
	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 <-- initial triplicate done showing, so this triggers duplicates but not main
	sta RESP1		   ; 3 49 - must be 49 <-- initial triplicate done showing, so this triggers duplicates but not main
	sta RESP0		   ; 3 52 - must be 52 <-- since duplicates are triggered, this triggers main plus duplicates
	sta RESP1		   ; 3 55 - must be 55 <-- since duplicates are triggered, this triggers main plus duplicates
	sta PF2			 ; 3 58
	lax DS_PF0L_ENAM1   ; 4 62
	sta PF0			 ; 3 65
	lda #<DS_SCORE8	 ; 2 67
	bne ScoreLoop	   ; 3 70

Link to comment
Share on other sites

I also notice on a real TV that games which use score have a bright middle pixel where the color changes. This might fix that too.

 

That sounds like it might be the known race condition in score mode - supercat mentions it here: http://www.atariage.com/forums/topic/168616-lxa-stable/#entry2092077

 

(the TIA's race condition occurs at mid-screen when using score mode if PF2.7 is set; there may be a half-pixel-wide odd-color stripe in that case).

 

I'm sure theres a better source for info about it - but that's just the last place I remember it being mentioned.....

Link to comment
Share on other sites

So if I understood that correctly, the <-- comments below explain how it's working?

Yep. You can also wait a different amount than 3 MCs:

 

STA RESP0

SLEEP 3

STA RESP0

The second RESP occurs while the start signal for the near copy from the first RESP is active.

 

STA RESP0

SLEEP 8

STA RESP0

The second RESP occurs while the start signal for the middle copy from the first RESP is active.

 

STA RESP0

SLEEP 19

STA RESP0

The second RESP occurs while the start signal for the far copy from the first RESP is active.

 

This assumes the appropriate copies are enabled. For example, the SLEEP 19 pause will not give you the main copy if you haven't enabled the far copy.

 

If you're using multiple copies of players that are spaced 8 pixels apart, you can get a string of nine players 8 pixels apart as follows:

 

STA RESP0

SLEEP 3

STA RESP0

SLEEP 7

STA RESP1

SLEEP 3

STA RESP1

SLEEP 7

STA RESP0

SLEEP 3

STA RESP0

The first two RESP0s give you three close copies of player0. The two RESP1s then give you three close copies of player1, beginning 8 pixels after the third copy of player0. And the last two RESP0s give you three more copies of player0, beginning 8 pixels after the third copy of player1.

 

Of course, you can do something else besides SLEEPing; I just used SLEEP to illustrate the number of MCs you need between the various RESPs.

  • Like 2
Link to comment
Share on other sites

@SvOlli, Maybe try to store some digits in ram, and then try repositioning after the 48 bit display is drawn. Things get tricky with VDELPx though.

 

@Eshu, I remember Supercat saying that before, but I think it was in another thread. That was the first I heard about it too. It might be color blending like Darrell is showing though. I'd have to find a program I tried it in to remember.

 

@Darrell, the bars looks great! Have you considered adding any effects to them? How about a subtle shine? Nothing to bright as to distract the player, but just enough to add a little eye candy so that if they are looking right at the score when they get a new life then it makes all the better. I made a quick demo to illustrate the idea. It's not fully functional as I don't have the time... but it conveys the idea.

 

post-7074-0-59666800-1338097586_thumb.png

ShinnyBars.zip

 

 

It's constructed with the ball, so only one player can get a shine at a time. Maybe if both players get a new life at the same time randomly choose who one gets the shine effect. If a player gets a new life while the shine is going on for the other player, then switch the shine immediately to the player who just got the life. Kinda brings out the competition, like the other person just one up'd ya.

 

 

Anyhow, I thought I'd share the idea to see if you like it, or maybe it'll give you some other ideas. There are lots of things you could do with those bars. As it is SpaceRocks is already damn impressive. I played for a while today, and I do love how the asteroids rotate. Very good job!!

  • Like 1
Link to comment
Share on other sites

Interesting - I noticed a SCORE mode glitch today. PF2 has all pixels turned on while PF0 has the first pixel turned off. It looks like player1's color is being applied to the playfield a pixel early.

post-3056-0-16989200-1338419784_thumb.jpg

 

This does not occur on my 7800, so the glitch depends on the TIA.

 

To hide the glitch, I shortened the bars by 2 PF pixels. This leaves a 1 PF pixel overhang on either side of the digits/lives, so they're more balanced looking than before.

post-3056-0-24358500-1338420973_thumb.png

Link to comment
Share on other sites

Weird. I wonder if all 2600's do that?

 

For the kernel it is not necessary to use score at all (because 1 PF block was chopped out before). In the shinny bars demo above I was strictly usingg the background color for the bars. It is also possible to just use the playfield, or a combo of playfield and background colors to construct the bars. You can also correct the glitch in score mode by placing the ball over the pixel that gets updated early, and making the ball the same color as the left side.

 

 

The score display does look nicer now! :thumbsup:

 

 

I suppose if it is a one player game you could also do some graphics with the right hand side. For example you could blank out player 2's life display, and then scroll "HIGH SCORE" across player two's score display, and then flash the high score. Actually thinking about it now the "I" in HIGH might look funny as it would be off to one side. I'd have to see to decide. Maybe "HI-SCORE" would look better with the "I" left justified. You could also do "HI-SCORE P0" or "HI-SCORE P1" depending on who died. There are other words that could be drawn, but it's hard to distinguish "D" from "O", and letters like "V", "W", etc are not possible.

 

 

Anyhow it might be all bang in the wrong area. You certainly don't want to distract the player while the game is going. I like the shine effect better because it is more subtle. I guess the more important parts now are tuning game play and sounds now. The game is coming along real nicely. :)

Edited by Omegamatrix
  • Like 1
Link to comment
Share on other sites

I hadn't looked that closely at the inner workings of shiny bar demo yet so didn't realize they were drawn by the backbround color. When I noticed the glitch I considered changing how it was drawn, but then realized that the bars on the "inside" overlapped the digits significantly more than the bars on the "outside".

 

I'm wondering if, for better image balance, player 2's score should shift in from the left and using trailing spaces instead of leading spaces. So instead of seeing the score change like this (the - characters are spaces):

---999  3
--1000  3

 

it'd change like this:

999---  3
1000--  3

Link to comment
Share on other sites

I think it looks pretty good as is. I would love to see it symmetrical, but the current construction with the missiles doesn't allow time. Modifying it is like trying to lay a carpet in a room with too many walls. You keep turning it so that it will fit and a corner keeps popping up somewhere else.

Link to comment
Share on other sites

I probably could have explained that better as I think you misunderstood my plans. New explanation: player 1's score is right-aligned, player 2's score is left-aligned.

 

This is what the current build does:

post-3056-0-33909000-1338657533_thumb.png

post-3056-0-81777300-1338657538_thumb.png

post-3056-0-81383300-1338657544_thumb.png

Edited by SpiceWare
Link to comment
Share on other sites

  • 2 weeks later...

Does this rely on the fact that the numbers are printed like digits on a calculator? Meaning, could you insert a new font?

Yes, it relies on simulating a seven-segment display. You can display all 26 letters using it, but the representations are not all unique so context is required to correctly decipher the words.

 

My end goal would be to fake a text mode display for a Nethack kind of game.

You'd probably be better off using the 32 character display that eshu came up with. If there's room I'm hoping to do a DPC+ version of it for a credits easter egg. The DPC+ version should allow for 16 rows of text.

Link to comment
Share on other sites

  • 8 months later...

It seems this is what I've been looking for, although I only need 3 digits per player... Can anyone confirm this can be made to function without the DPC+ (given that only three digits need to be shown and the others can be completely masked off)... I 'just' (compared to you guys I imagine) started programming for the Atari 2600 and I'm still a bit in the dark about the RESxx, HMxx and other crazy bits.

Link to comment
Share on other sites

It seems this is what I've been looking for, although I only need 3 digits per player... Can anyone confirm this can be made to function without the DPC+ (given that only three digits need to be shown and the others can be completely masked off)... I 'just' (compared to you guys I imagine) started programming for the Atari 2600 and I'm still a bit in the dark about the RESxx, HMxx and other crazy bits.

 

If you only need 3 digits per player then you'd be better off using a normal 48 pixel routine, but position the players(sprites) so the 48 pixels wrap around the border so that 24 pixels are drawn on each side of the screen.

Link to comment
Share on other sites

Clever. In a perfect world I would like to be able to display 3 + 2 digits for both players (health and ammo), but because I do not want to dive into DPC+ or other techniques for my first project I don't think I have the cycles or RAM to pull it off. Guess I'll just have to display them underneath eachother. Many thanks, this forum has been (and I guess will remain for a long time) a great source of information!

Link to comment
Share on other sites

If you only need 3 digits per player then you'd be better off using a normal 48 pixel routine, but position the players(sprites) so the 48 pixels wrap around the border so that 24 pixels are drawn on each side of the screen.

 

Boulder Dash manages to get 4 digits per player without the 48 pixel routine.

http://www.youtube.com/watch?v=w6Ge6G9sT9E

Skip to the 35 second mark to see that.

It also does a 3 groups of 2 digits a few seconds before that. No DPC stuff, just Thomas Jentzsch magic :)

Link to comment
Share on other sites

If you want to use the full 7 digit display, then you could unwind it all like I did, or use DPC+ to compact it into a loop.

 

post-7074-0-44792800-1361815196_thumb.png

 

I also made a different type of 7 digit display for Circus AtariAge. This has a single digit on the left for the lives/level, and the 6 digit score on the right. The score and lives/level digit can have independent colors. I'm using a few tricks to display this. Most notably I discovered a trick a while back to use TIM8T as a loop counter, and have aligned my graphics to be indexed by the INTIM values as TIM8T decrements. I also loaded this kernel into ram.

 

I'm sure DPC+ could do this display quite easily without needing the timer or ram kernel, but it's still cool to see what the unmodified hardware is capable of. You could definitely unwind that routine as well to get around using TIM8T, but I think you'd still have to load a digit or two in ram because of the limited cycles. This routine is in the Circus Atariage source attached to the first post in the Circus AtariAge topic.

 

post-7074-0-95993600-1361815778_thumb.png

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...
  • Recently Browsing   0 members

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