pong collision from nerdy nights

log in · Post by **log in** » Tue Dec 20, 2011 7:41 am

Could you help with the paddlewidth

you mentioned?
(and paddleheight and left and right)

Lets take 1 step back first.
I made 2 moving balls what did i use for that..

-variables : ballx and bally

-initial ball stats : lda #$30 sta ballx and lda #$40 sta bally

-update sprites :lda sta the Y,sprite,attribute,X

-update ball sprite: for the controls

So i thought ..

how do i get paddlewidth to start with the checks you mentioned.

so i looked here on the forum and google and i saw most people use these variables.

-top
-down
-left
-right

So i thought where are the x and y ? seems that

left=x and y = top
right = x + width
down = y + height

MY QUESTION :

1. How do i get the the width and the height?

and

2. how do i put it in my code?

My incomplete awnser and guesing..

1.width is x +other tiles / height is y+ other tiles,for exsample a pong paddle of 4 tiles is the y +the other 3.

2. how to put in code

variables = well.. left right top bottum .rs 1

initial ball stats= uhm.. left is x and top is y,but what about the right side of the ball and the bottum? Can this be the same also #$30 and 40 like my exsample? and if ther more pixels the would be a multiple lda #$ followed by sta ballright?

update sprites= well this gets confusing i gues multiple loadoing lda?

log in · Post by **log in** » Tue Dec 20, 2011 1:15 pm

NEVERMIND

I think i got it.

x is the top left corner,need to add 8 for right
y is 1 below that add 7 to get the bottom

lda object x
clc
adc #$08
clc
cmp object2 x
bcc check something

Kasumi · Post by **Kasumi** » Tue Dec 20, 2011 2:57 pm

You are definitely doing good problem solving and thinking about things in a good way. Keep it up!

Most of that sounds good except for a couple of things.

Did you set up the disappearing sprite I mentioned? If so you can do this one step at a time to make sure the parts work before the whole.

Also:

Code: Select all

lda object x
clc
adc #$08
clc;There is no need for this.
cmp object2 x
bcc check something

Using clc before adc is right, because if the carry could possibly be set it adds one more.

But using clc (or sec) before cmp is not needed. cmp acts the same no matter what the carry flag is, and it either clears or sets the carry flag based on the values. So doing something with the carry flag immediately before a cmp can serve no purpose.

y is 1 below that add 7 to get the bottom

If I understand correctly, you want to add 7 because the y sprites are drawn 1 pixel from their actual position?

That is actually good thinking, but because all sprites are affected the same by that you should still add 8. Unless you are adding 7 for another reason.

Edit: Actually, some other quick things:

variables = well.. left right top bottum .rs 1

Actually, you don't ever need to store the right and bottom variables. In the code you wrote, you'll notice the cmp can happen without ever storing the right value to RAM. And once the cmp is done you don't need it again.

update sprites= well this gets confusing i gues multiple loadoing lda?

Yep! You'll be doing lots of loading and storing.

When we get this working, there is a slightly better way to handle objects but I will avoid that for now.

log in · Post by **log in** » Wed Dec 21, 2011 3:34 pm

1. About the disappearing sprite

ashamed to say this but i cant test it because i have no idea how to change the 0F in another value to get it on screen.

2.I did draw this

Uploaded with ImageShack.us

log in · Post by **log in** » Wed Dec 21, 2011 3:51 pm

There are some mistakes in there i think.
For exsample: #$32 is for a 4 sprites paddle but this should be #$24 because the top already takes 8 sprites ,i only need to add the bottum 3 rows.

I really thought because x is the top the first y is only 7 and x pics up the other 1.So that would mean #$31 in total or #$ 23.

Another thing is coding in general .I thought its set in stone, but i see that doing something like a collision can be done in may ways.

I saw a collision code that works with bcc only

I thought that can't work but it did because the programmer swapped the player and the ball instead of using bcc and bcs.

Kasumi · Post by **Kasumi** » Wed Dec 21, 2011 5:07 pm

1. About the disappearing sprite

You have already succeeded in getting a sprite to move up and down.

You did this by adding to its y position while down is held, and subtracting from its y position while up is held.

The screen is 240 pixels high.

For the disappearing sprite, just do some setup. Each time before you check for the condition it should appear on, set its y position to #$FE (A value larger than the screen's resolution).

Then check the condition you want it to appear on (like A button being pressed), and set its y position to something on screen (like #$80) only if A is pressed.

So... its y position starts at #$FE. And that will only change if the condition is true.

Code: Select all

Happens every frame: sprite's y pos is set to #$FE
Check if A is pressed.
if A is pressed, y becomes #$80.
else y keeps the value you set before. (So it would still be #$FE)

When A is pressed, it appears. When released, it disappears.

Get that working before continuing. It's important. If you still have trouble with it, ask about THAT. No collision detection until the disappearing sprite works. Easy stuff before hard stuff. The reason I want you to do this is so you have something that will immediately tell you when something is not working. The code on your paper can't work. The disappearing sprite would tell you why if you checked each condition with it.

Edit: #$24 is different than #24. When you put a $, that means the number is in hex. #$24 = 36. #$32 is 50.

Another thing is coding in general .I thought its set in stone, but i see that doing something like a collision can be done in may ways.

Absolutely. There are a millions way to get the same result in programing. It's the same with math. I want the number 4. 2*2, 2+2, 8/2, 9/3+1 etc. They all get 4.

The most important thing is that you understand what you're trying to do. If you do, you can find many ways to do the same thing and can choose which one is best for you instead of relying on a possibly confusing piece of code.

For exsample: #$32 is for a 4 sprites paddle but this should be #$24 because the top already takes 8 sprites ,i only need to add the bottum 3 rows.

I don't understand this. A 4 sprite tall paddle would be exactly 32 pixels tall. But the top doesn't already take up 8 pixels (I assume you meant pixels). The position you have represents a pixel, not a sprite.

Sprites actually have very little to do with it. Let's pretend they don't exist for a bit.

You know the X location of your object. You know the y location of your object. This point is the top left corner of your object. It is a single point. Adding a width value to the X location makes your object grow that many pixels bigger to the right of this point. Adding a height value to the Y location makes your object grow that many pixels pixels bigger below that point.

How many pixels wide do you want your paddles to be? 8? Then you add 8. But this can be ANY number. It doesn't have to be a multiple of 8 just because sprites always are.

How many pixels tall do you want your paddles to be? 32? Then you add 32. 24? Then you add 24?

Depending on how your code is written, you're right. You should add 1 less, but you should do it for BOTH axises not just one. It's also possible to add more and use different branches, but bleh. A pixel difference won't matter for your first routine. When you understand it you can make it perfect.

The sprites have nothing to do with your collision detection. They help the player see what's going on, but they just don't matter to the computer checking positions. You can write working collision detection code on a computer that displays no graphics.

So the fact that your paddle is made up of multiple sprites shouldn't affect what your collision detection is doing at all.

Forget the paddles. Forget the ball. Forget every sprite except the one that disappears and reappears.

You know 4 things about two objects.

1. You know each object's X position (Left side of the object).
2. You know each object's Y position (top of the object).
3. You know each object's Width.
4. You know each object's Height.

Now use your disappearing sprite.

I asked you earlier to make two sprites that move. One of those sprites will be object1. The other will be object2.

You add object1's width to object1's x position. Compare that to object2's x position. If it is less, then the sprite disappears. Otherwise, it appears.

That's the first step.

log in · Post by **log in** » Thu Dec 29, 2011 2:07 pm

Back after the holidays and became a father again

At work i did some programming in my very little spare time.
And i came up with this after a lot of thinking.

first the flashing sprite:

A button:

lda ball3y
clc
lda #$30
sta ball3y

Im still a programming rookie so this made the sprite apear on screen but it also staid on screen after pushing A.
tried to make it dissapear again but nothing i did worked(i suck

)

but programming can be done in many ways so i came up with this;

B button

lda ball3y
clc
lda #$ef
sta ball3y

pushing A makes it appear
pushing B makes it dissapear

first check wide+x ball 1 VS ball 2 x
i came up with this

Collision:

lda ballx
clc
adc #$08
cmp ball2x
bcs NoHit
bcc sprite

sprite:
lda ball3y
clc
lda #$30
sta ball3y

NoHit:

It worked (i think)
the sprite(the 3th ball) appears after the second ball is completely passed the first.

Somehow i thought it would appear more then halfway past the sprite.
But it is correct right?

Kasumi · Post by **Kasumi** » Thu Dec 29, 2011 3:29 pm

Congratulations on your new child!

Code: Select all

lda ball3y
clc
lda #$30
sta ball3y

Why are you doing clc here? The state of the carry flag only affects a few instructions and lda and sta are not affected by it.

To make the sprite disappear, just do this right before it.

Code: Select all

lda #$F0
sta ball3y

Full code like so:

Code: Select all

lda #$F0
sta ball3y;Putting the sprite off screen.

lda buttons1
and #%10000000
beq staygone
lda #$30
sta ball3y
staygone:

See how that works? It's always set to #$F0 before the check. If the check fails, it stays #$F0 because the code that sets it to #$30 is skipped. If the check passes, #$30 is stored there.

Code: Select all

bcc sprite

sprite:

Don't ever do this. There are no instructions between the branch instruction and the label you are branching to. That means you could comment out that branch, because whether it branches or doesn't branch the program will do the exact same thing.

Code: Select all

lda ballx
clc
adc #$08
cmp ball2x
bcs NoHit

Here's what this says:

If ball1x+8 > ball2x then branch to No Hit.
If ball1x's right edge > ball2x's left edge there is no collision.

Code: Select all


+ = Ball1
- = Ball2
* = Ball2 and Ball1 overlapping

0123456789ABC (X pixel position)
++++****----
    |  |    
    |  |-Ball1's right edge (7)
    | -Ball2's left edge   (4)

7>4

There is a collision in the above diagram that your one check should cover. Does it work as expected in the above case?

log in · Post by **log in** » Sun Jan 01, 2012 12:46 pm

1. The sprite code was almost the same as i had ,but i had it after the buttons part.(i fixed it and got it working).

2.The branch without instructions between it was just stupid.It was raw code that i had and didn't clean up yet.

3.the collision
http://www.google.nl/url?sa=t&rct=j&q=2 ... RMHjwK3RzA

i also read this.(and the stuf from here)

//If all the following conditions are true
if(
ballx+ballwidth >= paddlex
&&
ballx<= paddlex+paddlewidth
&&
bally+ballheight >= paddley
&&
bally<= paddley+paddleheight
)
{
//we collided
}else{
//no collision occurred.
}

So to awnser your question does it work? No

I think i know now what was wrong.

The x checks:

ballx+w >paddlex
ballx < paddlex +w

if i keep this in mind with the balls and the sprites i made i see now that if its past the ball or for the ball nothing happens but if its in between it 'hits'and the collision code that makes the ball move the other way gets activated.

So now the trick part how to put this in code.

-------------------------------------------------

lda ballx
clc
adc #$08
cmp paddlex
bcc no collision

So we loaded ball x we added its width and compaired it to the paddle.We want it to be > or bcs to continue the collision check.
So if its bcc we guide it to no collision code.

the code runs further..

lda ballx
cmp paddle x
clc
adc #$08
bcs no collision

^^ don't know if this is correct coding im just typing this out of my head and on the go. I could turn this around by the way and load the paddle first.

The most important thing is that i think i know what im trying to do with a collision. im checking if object 1 and 2, if there not before or after its a hit.

Kasumi · Post by **Kasumi** » Sun Jan 01, 2012 3:44 pm

I think you know have the right idea, but the code below is strange.

Code: Select all

lda ballx;Ballx is in A.
cmp paddle x;We check ballx with paddlex.
;The carry is set if ballx is greater than or equal to paddleX. 
;It is cleared if ballx < paddlex

clc;But we never use the state of carry flag from the above cmp.
;This instruction just cleared it, so the state of the flag before this instruction is lost forever.

adc #$08;We add 8 to Ballx which is in A.
bcs no collision;If ballx + 8 > 255, we branch to no collision.

I realize you typed it up off the top of your head, but that's what that code is doing.

You need to find a way to add 8 to paddleX and compare the sum with ballx.

im checking if object 1 and 2, if there not before or after its a hit.

Correct.

log in · Post by **log in** » Tue Jan 03, 2012 1:03 pm

I got the collision working.(but not perfect yet)

First i did it with the blinking sprite and it worked.After that i made a reverse code for the ball and it worked.The collision worked and the ball bounces back.

The only strange thing is that the collision works at the very last second.
The ball is in the paddle hits the last pixel of it and returns.
Seems like a x check problem i need to fix.

But im already very happy.

Now i got a lot of work ahead of me.

First i need to change my code to your nmi structure because it already crashes after i add a second collision code.(only background displayed)
Too much too do i think.

Ill ad score what i alread did before and worked fine.
Make a nice background.
Have a start screen and game over and maybe credits etc.

So ill have m agenda full this month.

Kasumi · Post by **Kasumi** » Tue Jan 03, 2012 3:45 pm

First i need to change my code to your nmi structure because it already crashes after i add a second collision code.(only background displayed)

That's really not good at all. How are you displaying the background? If you're trying to update the background all at once when rendering is happening, that would be why it's crashing. Bunnyboy's NMI wouldn't cause a crash unless you're doing a LOT in a frame.

One thing you should do now is reserve some temp RAM. 8 bytes for now, you can always add more later.

Then make your collision routine a subroutine. It will set the carry flag if the collision is true, and clear it if it is false. Instead of acting directly on ballx, ballwidth, etc, it will act on the temp RAM.

Ballx=temp1
Bally = temp2
Ballwidth = temp3
ballheight = temp4
paddlex=temp5
paddley = temp6
paddlewidth = temp7
paddleheight = temp8

To use it, you store the x, y, width, and height values of the two objects you want to collision check to RAM.

Then you jsr to the subroutine. When it returns, you can use bcc to branch passed the code that should happen if the objects collided if the collision didn't happen.

This way you only type your check collision code once. Each time you change it to make it better, it affects everything that uses it.

In that end it would look like this:

Code: Select all

lda ballx
sta temp1
lda bally
sta temp2
lda ballwidth
sta temp3
lda ballheight
sta temp4

lda paddlex
sta temp5
lda paddley
sta temp6
lda paddlewidth
sta temp7
lda paddleheight
sta temp8
jsr collisioncheck
bcc skipbounce

;code that makes ball bounce here

skipbounce:

There's a way to improve on that a little more if you use lda variable,x and ,y.

log in · Post by **log in** » Tue Jan 10, 2012 3:21 pm

quick update

1.I got the collision for 1 paddle perfect.Found the bug.I had a typo in the X position of the paddle.

2. For the background i use the old nerdynight method of loading it in 4 parts,but i changed that in a variable system with high and low part of the background BUT ill have to search more info about incbin so i can use that.

3. How does my pong look

Well i have a nice background and 1 paddle works 100% and i have 2 scores displayed.
The downside : the second paddle doesnt work at all even checked it with the sprite trick and the scores have a very funny bug.If the ball hits the left or right wall the score is added but the screan flashes and shakes for a second if i add background the zeroes come threw it,funny but a bug.

Ill add some source code and video later.

EDIT the temp ram is still abracadabra for me but ill look it up later .

Kasumi · Post by **Kasumi** » Tue Jan 10, 2012 4:26 pm

Temp RAM is just a way to use a general subroutine.

Ballx, bally, paddle1x and paddle2x etc. can't be used to store an unrelated number while the game is running because it will mess up the positions of those objects.

Right now (I assume) your collision routine works by comparing ballx with paddlex directly. This means you can't use it to check ballx with paddle2x or any other two objects without overwriting the values stored in ballx and/or paddlex.

If the routine used RAM values that weren't required to be consistent outside the routine, it could be used for testing any two objects and you wouldn't have to overwrite ballx, bally etc. or write multiple routines that do the same exact thing (like checking a collision) just with different ram locations (paddle2x instead of paddlex for instance).

You would just write the values needed to the temp RAM before you jsr to the routine, and that one routine would check for a collision using the values in the temp RAM. If you want to compare two different objects, write the different object's positions to the temp RAM before the jsr to the subroutine and the same routine will tell you if they are colliding.

Basically, temp RAM is RAM that is only used for a small part of the program and doesn't need to keep its values the same across multiple frames. The same RAM can be used for a lot of routines, because once the routine is finished the RAM's values have already been used and are "free" again.

Post by **tepples** » Wed Jan 11, 2012 8:14 am

Or you could look up "temp RAM" in an encyclopedia by its more common name of local variables. If that article is abracadabra, I'm willing to help explain it line by line.