32 replies to this topic

[SpiceWare]

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:


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


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


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


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

[SvOlli]

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?

[SpiceWare]

Sorry, sure don't. While I can modify an existing RESP routine to use DPC+, I haven't yet spent the time to wrap my head around how the RESP trick actually works.

[SeaGtGruff]

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.

[SpiceWare]

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

[eshu]

Omegamatrix, on Fri May 25, 2012 5:51 PM, said:

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....e/#entry2092077

supercat, on Sat Sep 11, 2010 11:13 AM, said:

(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.....

[SeaGtGruff]

SpiceWare, on Sat May 26, 2012 10:49 AM, said:

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.

[Omegamatrix]

@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.


 ShinnyBars.zip   3.25K   1 downloads


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!!