Jump to content
IGNORED

Collision detection - best practice


Recommended Posts

To all whom have developed/currently developing atari games,

 

would like to hear from your experience the practice you chose to follow in your sprite - to - playfield collision detection.

in particular how your main character walked and jumped over terrains 

how the main character was stumble upon walks / bricks etc and couldn’t moved on

and how your main character hit one of the enemies in the game (which made out of character) and dies 

 

cheers 

  • Like 1
Link to comment
Share on other sites

Typically you don't do collision with terrain with hardware collision. The PMG and the field have to overlap to generate collision. You want to stop the player BEFORE it overlaps though. Also there is one player (or two) so it's no big deal to solve the collision with terrain by other means. Typically you'd use your logical map data, most games have something like that. And you can always just check the correct pixels in the VRAM manually with CPU.

Hardware collisions are more useful as detection of player getting killed.

 

Link to comment
Share on other sites

A bounding box method.  Possibly multiple ones for the player if he's animated with drastic changes in frames.

Similar for playfield character codes, or in some cases a table might be sufficient where e.g. terrain height adjustment values are maintained.

 

I think Pharoah's Curse might use hw collision or a mix of that and bounding methods.  The end result being the player often bounces back or height adjustments lag behind what they should be.

Link to comment
Share on other sites

I'd like to refer to what @R0gerand @Rybags wrote above.

 

Let's examine a case study : crown land

 

image.thumb.png.22f912dd42babfe9964d41cddb335c37.png

In the image above, the main character is PMG based i beleive it is being comined out of 2 player with an ORing 3rd color , AND missiles to have the cape effect (as i can tell the sprite is more than 8 pixel wide).

 

I have debugged the game in Alitrra and there are 21 char mode lines (Antic mode 4) so I beleive that the scenery is made out of character set.

 

I don't think that HW collision was used here for terrains as that playfield color of the terrain was used for other stuff on screen.

I do beleive that HW collision was used for collecting the stars and bumping into the creatures and they are clearly made out of PMGs (a multiplexing technique of PMGs but still PMGs) so HW collision make sense.

 

Let's go back to the terrains. what is the minimum best calculation that a developer can perform in order to get such a beautiful terrain calculation.

 

I would like to hear some thoughts from you guys.

remember the character can move left and right, can jump and ascend and descend can fall down.

so please refer to these paths of player in your response.

I can think of the bounding box method suggested above by @Rybags,

and i guess this what was done here,  but i am interested to learn the best practice and minimum usage of CPU in order to acheive the best collision i can have (such as crown land)

 

Cheers

 

Link to comment
Share on other sites

image.thumb.png.3ce94e517fc166bdbe982d9eb5188d18.png

in this example, the main character is facing left and standing almost on thin air. one pixel movement to the left and he falls down to the terrain below him.

so to continue my thoughts above, he moves left but also needs to calculate the terrain underneath him.

 

i want to have a rational solution for all the possible movements.

 

happy to hear thoughts

Link to comment
Share on other sites

I don't understand your question. Are you asking how Crown land is made ? I have no idea.

 

I would test logical map what type of brick is bellow the player. And if there is chance of player being on the ledge, I would check graphics data of the current player frame combined with exact player coordinate. Probably using some small table.

 

But let's analyze this game of mine https://atariage.com/forums/topic/283993-sails-of-doom-new-multijoy-game/

There are all kinds of collisions.

Ship vs. shore is done by logical map only. I take coordinates of the ship, check what kind of tile is at those coordinates, and every tile has direction to which it pushes the player away from shore.

Ship vs ship is done by another table. It's basically 2D array, 16x16, which tells me distance from coordinates 0,0. So I take relative coordinates  of the ships, lookup the table, and I know let's say the ships are 10 pixels away. Let's say the collision limit is 8 pixels. So 10 pixels is 'no collision' case. If the distance is 6, ie less then 8, I know I have to move every ship 1 pixel in the opposite direction to solve the situation.

Theb there is ship vs. shell. That also uses this distance 2D array, except the collision distance is smaller (IIRC), and there is also test for current shell altitude.

There is also shell vs. terrain. I want shells which land on water to splash, but shells which land on ground to explode. And that is done by checking actual color of the pixel where the shell landed. If it's blue, I do the splash, otherwise I do the explosion.

This game draws (mostly) everything in graphics, so to avoid ships, shadows, or other shells affecting this test, it is done in the moment all the moving objects from previous frame are erased, and the map is clean.

 

Link to comment
Share on other sites

Bruce Lee is based on sprite - to - playfield collision detection. The interview with Ron Fortier in Retro Gamer 145 gives some very interesting details, even if it seems that his memory sometimes fails ?:

Quote

The genesis of the gameplay was from research that I was doing related to aspects of the ANTIC/CTIA/GTIA processors. I was intrigued by how the processors produced collision detection [using] colours. Bruce Lee had to fit in 32k. The processor ran at 0.8 (sic) MHz so you were always cycle counting. Hardware collisions would help reduce code, and,as it was done in hardware, it would be a zero hit from a cycle perspective.

 

See also :

 

Link to comment
Share on other sites

9 hours ago, R0ger said:

Haha, that's great ! He's really sunk 1 pixel deep into the floor ! I never noticed. And anything which is same color as floor can be jumped onto.

This makes it possible to create new levels. To try to extend the game, I have set up areas where detection is used.

If characters (sprites) are out of these boxes, the selected playfield color have no influence on them.

For example, for the floor colour:

image.png.fcd380caad721acefdf39e83baae3548.png

 

To be honest, I don't know if it's a good idea...?

Link to comment
Share on other sites

4 hours ago, fantômas said:

This makes it possible to create new levels. To try to extend the game, I have set up areas where detection is used.

If characters (sprites) are out of these boxes, the selected playfield color have no influence on them.

For example, for the floor colour:

image.png.fcd380caad721acefdf39e83baae3548.png

 

To be honest, I don't know if it's a good idea...?

Well I guess the main worry would be if the system is too free, it would allow player to get over obstacles he's supposed to get over. With game small as as Bruce Lee it shouldn't be too hard to simply test it. But I don't see how extra tests on logical level would harm the game.

Link to comment
Share on other sites

6 hours ago, fantômas said:

 

image.png.fcd380caad721acefdf39e83baae3548.png

 

in the bound boxes, what coordinates do you use? 

PMG coordinates? char mode coordinates?

 

Also, i have an idea for a moving terrain like i showed above, 

I can create a hidden missile that moves with the terrain and check collision with that missile - as long as it collides the main sprite stick to that terrain

Link to comment
Share on other sites

20 minutes ago, R0ger said:

create table where for every X coordinate you have a height of the terrain. There's like hundreds of way of doing it

I guess this sounds like a good approach.

eventually, I guess to do a proper terrain sticky-ness programing, map coordinates is the practice i think i will follow.

thankd @R0ger and all.

 

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