#12057 - goro - Tue Oct 28, 2003 12:00 pm
Hi,
For learning purposes, I want to re-create 'Pong' but I'm stuck at doing collision.
I have no bg to worry about, I can make my bats move up and down, and I have a ball. So I just need the most simple collision technique for this project.
Also - I intend to write a very simple tutorial (aimed at absolute beginners like me!!) so please provide very simplistic replies.
Thanks.
ps. I checked the tutorials section & did a search on the forum & read a lot of posts but didn't quite find an answer that was simple enough...
-edit - I know I can just compare the x& y positions of the bat & ball but I wish to start the learning curve for collision...
#12058 - marcmccann - Tue Oct 28, 2003 2:09 pm
for a pong type game i reccomend bounding rectangle collision detection, just have the edges of the ball at the edge of the picture. This is done like (pseudo)
if ball bottom > paddle top then no collision
//Do stuff
if ball bottom <= paddle top then collision
//Do stuff
same goes for the balls Y position.
That was a pathetic attempt to explain it, i will email you a proper thing when i get chance.
Also radius based collision is an option but probably not worth struggling with for a pong type game.
_________________
The GBA is one Lean and Mean machine!
#12061 - goro - Tue Oct 28, 2003 4:47 pm
bounding rectangle collision detection and radius based collision?
Are these the main ways of doing collision?
Like, what did they use for the snes and megadrive games?
I wouldn't mind covering some slightly advanced topics like how mario can be blocked by an obstacle (say, a wooden box)and then jump onto it...
#12062 - tepples - Tue Oct 28, 2003 5:01 pm
Mario jumps. Mario is falling. The physics engine scans the playfield surrounding Mario at all times and determines that in the next frame, Mario's rectangle will overlap that of a solid playfield object. Then it places Mario on the object and changes Mario's state from "falling" to "standing".
A more complicated collision method, used in Sonic the Hedgehog 2, gives each 16-by-16 pixel map block a collision map consisting of a left extent and a right extent of the solidness of that block.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#12095 - goro - Wed Oct 29, 2003 11:22 am
| Quote: |
| Mario's rectangle will overlap that of a solid playfield object |
Okay, I'm beginning to understand. For collision to work, we always need a bounding box.
Q: Can you confirm that the x,y position (attributes 0,1) are for the bottom left corner of the sprites and that our virtual bounding box begins here.
| Quote: |
| and changes Mario's state from "falling" to "standing". |
It seems FSM's played a big part in programming even in days of olde...
| Quote: |
| A more complicated collision method, used in Sonic the Hedgehog 2, gives each 16-by-16 pixel map block a collision map consisting of a left extent and a right extent of the solidness of that block. |
Software like Maped create collision layers. Is this what you speak of, and are most 'commercial' GBA games programmed in this way?
Also - how did they do it in Sonic 1 or in the older sms or nes games?
| Quote: |
| The physics engine scans the playfield surrounding Mario at all times and determines that in the next frame, Mario's rectangle will overlap that of a solid playfield object. |
At all times? By this you mean it does 1 check per frame?
So his bounding box has bigger radius and when the first pixels overlap, the engine waits till the next frame to act on the collision?
| Quote: |
| a left extent and a right extent of the solidness of that block. |
Can you clarify how?
Thanks for your responses so far...
#12098 - tepples - Wed Oct 29, 2003 4:07 pm
| goro wrote: |
| Can you confirm that the x,y position (attributes 0,1) are for the bottom left corner of the sprites and that our virtual bounding box begins here. |
Screen positions of sprites are always the top-left corner.
| Quote: |
| Software like Maped create collision layers. Is this what you speak of, and are most 'commercial' GBA games programmed in this way? |
I don't know how "most" games do it.
| Quote: |
| Quote: | | The physics engine scans the playfield surrounding Mario at all times and determines that in the next frame, Mario's rectangle will overlap that of a solid playfield object. |
At all times? By this you mean it does 1 check per frame? |
I was just using SMB as an example of a platform game. I don't know how many sub-tasks SMB decomposes its collision tasks into, but yes, it runs collision testing every frame.
| Quote: |
| So his bounding box has bigger radius and when the first pixels overlap, the engine waits till the next frame to act on the collision? |
During each "current frame", the engine is always computing the "next frame" before sending it to the video chip.
| Quote: |
| Quote: | | a left extent and a right extent of the solidness of that block. |
Can you clarify how? |
You'll have to read this. I wouldn't suggest such a sophisticated scheme for your first platformer, though.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#12100 - goro - Wed Oct 29, 2003 5:12 pm
Wow, Thanks!!
| Code: |
| Screen positions of sprites are always the top-left corner. |
Even when the horizontal_flip is on?
| Quote: |
Quote:
Software like Maped create collision layers. Is this what you speak of, and are most 'commercial' GBA games programmed in this way?
I don't know how "most" games do it. |
Sorry, I meant to ask : is this was a good way todo it for a platform-type game?
| Quote: |
| During each "current frame", the engine is always computing the "next frame" before sending it to the video chip. |
Is this the way to do it on a gba (using mode 0, 16-color sprites/tiles etc)?
| Quote: |
Quote:
a left extent and a right extent of the solidness of that block. |
Thanks for that link, I'll check it out asap. Any idea of how they dealt with collision on the old nintendo (NES)?
Thanks again....
#12103 - tepples - Wed Oct 29, 2003 6:17 pm
| goro wrote: |
| Quote: | | Screen positions of sprites are always the top-left corner. |
Even when the horizontal_flip is on? |
Clarification: Top-left corner of the bounding rectangle, not top-left corner of the image. The flip doesn't affect where the sprite's bounding rectangle is. Rot/scale matrices don't affect where the sprite's bounding rectangle is. There are only five bitfields that have any effect on a sprite's bounding rectangle as seen by the GBA video chip: x position (left side), y position (right side), shape, size, and double-size.
Note that what I said applies only to what is seen by the video chip. Game engines may have other ideas of the origin of a sprite's local coordinate system. If you're confused, study some analytic geometry.
| Quote: |
| is [a collision layer] a good way todo it for a platform-type game? |
To save space in ROM, try computing both your display and your collision map in real time from a more abstract representation in ROM. This is how at least Super Mario Bros. does it, which is how it managed to squeeze all its map data into 5 kilobytes.
| Quote: |
| Quote: | | During each "current frame", the engine is always computing the "next frame" before sending it to the video chip. |
Is this the way to do it on a gba (using mode 0, 16-color sprites/tiles etc)? |
On some level, that's how any real-time game on any platform works. A real-time program is a transformation from the state of the machine in one frame to the state of the machine in the next frame.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.