IGNORED

RAM Pong

Recommended Posts

Some interesting ideas about scoring. I will definitely think about some of those.

But first I need more free bytes (5 currently). And then I also would like to implement at least two ball angles.

Share on other sites

Multiple ball angles and scoring are necessary. Shrinking paddles is a brilliant idea. Others...

use background color? Or paddle/ball color?

Share on other sites

Multiple ball angles and scoring are necessary.

I have now 12 bytes free (almost 10%! ).

Shrinking paddles is a brilliant idea.

Yes, I have thought about that one too and I am pretty sure it is possible within 12 bytes.

Others...use background color? Or paddle/ball color?

I could do that, but I cannot imagine how to enocde the two scores. Maybe I could do some PF scoring, but I haven't found a good way here too.

Which leaves multi-ball angles.

Currently I am simply using the collision registers to detect that the ball has to bounce. What would trigger the different angles? Where the ball hits the paddle, I suppose. I doubt that this is possible within a few bytes...

Hmm... :ponder:

Share on other sites

I vote for the shrinking paddles.

When you don't have any paddle left, you lose, the ball passes by one more time, then the game stops.

Could the angles be a cycle? 45, 30, 15, 45, 30, 15, etc.... There would be some strategy in play then.

Share on other sites

Others...use background color? Or paddle/ball color?

I could do that, but I cannot imagine how to enocde the two scores. Maybe I could do some PF scoring, but I haven't found a good way here too.

Think of a single score, starting at 0. If R player scores, increment. If L player scores, decrement. -10 = L win. +10 = R win.

Figure out some way to translate this to colors...\$08 = neutral. \$00 = left win, \$0E = right win.

Or color = L score, brightness = R score. Then you can encode all in a single byte and display with a single store.

All of these schemes would be hard to interpret, but better in any case than forcing players to count on their fingers while they play.

Which leaves multi-ball angles.

Currently I am simply using the collision registers to detect that the ball has to bounce. What would trigger the different angles? Where the ball hits the paddle, I suppose. I doubt that this is possible within a few bytes...

Hmm... :ponder:

How about variable ball speeds instead of variable ball angles? Of course, same problem, I suppose...how to trigger.

Share on other sites

How about variable ball speeds instead of variable ball angles? Of course, same problem, I suppose...how to trigger.

That's easy: Fire button

Share on other sites

How about variable ball speeds instead of variable ball angles? Of course, same problem, I suppose...how to trigger.

That's easy: Fire button

Make some carts for the Retrobörse, Thomas......

Share on other sites

Make some carts for the Retrobörse, Thomas......

I'll put it on my Kroko Cart.

Share on other sites

When you don't have any paddle left, you lose, the ball passes by one more time, then the game stops.
I was thinking the other way around. As you score higher, your paddle gets smaller to give the opponent a fighting chance. While fighting for the winning point, your paddle would be like the size of the ball. I guess that the winner's paddle disappearing completely would be the "Game Over" indication, leaving the loser standing on the court with the remnants of their paddle to remind them of how soundly they'd been trounced or show how narrowly they'd lost. Edited by BigO
Share on other sites

Others...use background color? Or paddle/ball color?

I could do that, but I cannot imagine how to enocde the two scores. Maybe I could do some PF scoring, but I haven't found a good way here too.

both start all green. With every passing ball the losing player's paddle top and lowest lines turn red (he starts "burning"), and so forth, progressing towards the center of the paddle, till one paddle has completely turned red = game over.

That should give an intuitive visual gauge of the game's progress and both players performance...

Edited by r_type2600
Share on other sites

both start all green. With every passing ball the losing player's paddle top and lowest lines turn red (he starts "burning"), and so forth, progressing towards the center of the paddle, till one paddle has completely turned red = game over.

That should give an intuitive visual gauge of the game's progress and both players performance...

Good idea, but it will require some more bytes than just shortening the paddle.

BTW: 15 bytes free now. Maybe even 17.

Share on other sites

It's all in RAM, are you putting in self-altering code or something like that to gain those free bytes?

Share on other sites

When you don't have any paddle left, you lose, the ball passes by one more time, then the game stops.
I was thinking the other way around. As you score higher, your paddle gets smaller to give the opponent a fighting chance. While fighting for the winning point, your paddle would be like the size of the ball. I guess that the winner's paddle disappearing completely would be the "Game Over" indication, leaving the loser standing on the court with the remnants of their paddle to remind them of how soundly they'd been trounced or show how narrowly they'd lost.

Yeah, that works too! Might be better actually! There is a better game element in your scheme, IMHO. No easy wins. With each point, comes some additional focus required to close the deal!

I like it!

Share on other sites

Make some carts for the Retrobörse, Thomas......

I'll put it on my Kroko Cart.

Share on other sites

This thread led me to 'discover' something interesting:

```	 lda \$85

;lda is at \$84, \$85 is at \$85```

Loads #\$85 to accumulator, but wastes a cycle although, I am sure it is rare to find a situation where this is useful.

Share on other sites

It's all in RAM, are you putting in self-altering code or something like that to gain those free bytes?

I haven't used selfmodifying code here yet. But I do something like this:

```.variable = . + 1
lda #INITIAL_VALUE```

Which saves one byte of RAM.

The space gains are coming from optimizing the existing code for space, e.g. reusing register contents, reducing overhead space (no timer, just simple WSYNCS). And I gained quite some space by optimizing the paddle enabling/disabling code now (which is looping over both players to save even more space):

Old, 32 bytes:

```yPosLst	 .byte   50, 50
yPos0	   = yPosLst
yPos1	   = yPosLst+1
yPosNewLst  ds 2
yPosNew0	= yPosNewLst
yPosNew1	= yPosNewLst+1

lda	 yPosNew0
sta	 yPos0
lda	 yPosNew1
sta	 yPos1
...

; draw player:
tya						; 2
sbc	 yPosLst-1,x		; 4			 C = 1
lda	 #0				 ; 2
lda	 #\$c0			   ; 2
sec
sta	 GRP0-1,x		   ; 4 = 18/19

lda	 INPT0-1,x		  ; 4
bmi	 .skipPos		   ; 2/3
sty	 yPosNewLst-1,x	 ; 4```

New, 20 bytes:

```yPosLst	 ds 2
yPos0	   = yPosLst
yPos1	   = yPosLst+1

sty	 yPosLst			; 3			 y = -1, avoids disabling paddles at top
sty	 yPosLst+1		  ; 3
...

lda	 INPT0,x			; 4			 paddle pos reached?
bpl	 .skipPos		   ; 2/3			no, skip
inc	 yPosLst,x		  ; 6
.skipPos:					  ;   =  7/12
cmp	 yPosLst,x		  ; 4
txa						; 2			 x = 0/1
ror						; 2			 a = \$00/\$80
sta	 GRP0,x			 ; 4 = 14```

12 bytes gained!

Share on other sites

Another update, now with (4) variable angles.

7 bytes free...

RAM_Pong__2_player_v0.3_.bin

RAM_Pong_11.zip

Share on other sites

Another update, now with (4) variable angles.

7 bytes free...

To play a game in ram... just too cool!

Share on other sites

For the record, I was only kidding when I said this.

Share on other sites

For the record, I was only kidding when I said this.

Really? Knowing that before, would have saved me a lot of time.

BTW: I got an idea for displaying the score, which doesn't require much space:

I could move the center line a few pixels left or right, if a player misses the ball.

Good idea?

Share on other sites

And how about changes the player color?

Starting in white, then every ball loses turn a bit dark, when the player turn in darkest color, this case black, the game is over.

BallOut

Lda COLUP0,x

beq GameOver

sbc #2

sta COLUP0,x

If COLUPX is 0, game over. Assuming it's possible to read the colors registers...

Share on other sites

This is simply amazing work you have done. Getting any game to work in 128 bytes is challenging beyond description - and then to make that game fun... I'm shocked.

Anyway, I thought of something you can do after a game is over and you have a winner. Since the cartridge can be removed, why not let the winner put a cartridge in the slot. Then, your game would boot the cartridge. This could be the Pong Chooser - and could be used to decide which game two warring kids play:

Kid 1: I want to play Star Fire.

Kid 2: No, i want to play Thrust!

Kid 1: No, no. Star Fire!

Kid 2: I want Thrust!

Kid 1: Star Fire!

Kid 2: Thrust!

Kid 1: Star Fire!

Kid 2: Thrust!

Kid 1: Let's Pong over it!

Kid 2: Ya, you are going down!

Share on other sites

If COLUPX is 0, game over. Assuming it's possible to read the colors registers...

Unfortunately it is not.

Share on other sites

This is simply amazing work you have done. Getting any game to work in 128 bytes is challenging beyond description - and then to make that game fun... I'm shocked.

Thanks for the compliment. Actually I am surprised myself how far I got.

Anyway, I thought of something you can do after a game is over and you have a winner...

LOL, I like that idea.

Share on other sites

Another update.

Now the game "counts" the score by moving the net. The game is over, when the net reaches one border.

Also the net is dotted now, which did cost me the last two free bytes.

Unless someone reports bugs I consider the RAM kernel part done. Working on a title screen now...

RAM_Pong__2_player_v0.4_.bin

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.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.