Requesting Help With Collision Detection

[Cybearg]

Does anyone have any suggestions for a simple, efficient, and small collision detection routine that works well, particularly for platforming?

 

Here's what I'm currently doing:

 

First, I use pfreads to check for platform collision. This seems to work very well, except once the player has moved past a certain vertical point, pfreads read phantom platforms that will stop the player where there aren't any, so I skip falling routines beyond those vertical points:

 

temp5 = (player0x + 1) / 4 - 4
temp3 = (player0x + 4) / 4 - 4
temp6 = ((player0y + 1) / 

falling = 1
if pfread(temp5, temp6) then falling = 0
if pfread(temp3, temp6) then falling = 0
if player0y < 8 then falling = 1
if player0y > 84 then falling = 1

 

In this example, a bit named "falling" is used to determine whether the player is falling or standing on a solid platform.

 

As I said, this works very well for me, but it becomes more problematic with collision detection for walls:

 

if !collision(player0,playfield) then leftlock = 0: rightlock = 0: goto 0collide
if rightlock || leftlock then goto 0collide
if mirrorh then leftlock = 1 else rightlock = 1
0collide

 

This checks to see if the player's sprite is clipping through the playfield (which could only happen if the player ran into a wall) and then determines which side of the sprite the wall is on based on which direction the sprite is facing (the mirrorh bit is set to 0 when moving right, 1 when moving left).

 

When the player attempts to move left or right, there is a check to see whether or not that side is locked out or not:

 

if joy0left && player0x > 15 && !leftlock then player0x = player0x - 1: mirrorh = 1
if joy0right && player0x < 139 && !rightlock then player0x = player0x + 1: mirrorh = 0

 

This works fairly well, as I've yet to slide through platforms the way I do when using a pfread for horizontal collision, but the problem here is that players can become stuck on walls if they slide up against them while facing the wrong direction, since the code will assume that they're colliding with a wall on the wrong side and will lock out their movement controls.

 

Any suggestions for a better way to determine which side of the sprite is colliding with a wall? The problem with pfreads is that they're unreliable with horizontal collision because each pfpixel is a whole 8 pixels tall, so you actually need two pfreads to check depending on how many pixels the player has fallen beyond the top of the pfpixel and there things get complicated and the code gets messy. I'd like to avoid that if I can. Anyone have any elegant solutions?

Edited July 8, 2013 by Cybearg

[+Gemintronic]

R.T. made a good demo of platforming physics here:

http://atariage.com/forums/topic/179473-fake-gravity-platformer-test/page__hl__%20random%20%20platform

[Cybearg]

R.T. made a good demo of platforming physics here:

http://atariage.com/...andom platform

Maybe it's just me, but R.T.'s examples never work. When I compile/run his .bas file, the player just falls through the ground and off the screen. None of his other collision detection examples have ever worked correctly for me, either. No idea why.

 

See the attached.

 

And in any case, his side collision is this:

 

  rem  ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
  rem  '  Don't move right if a pfpixel is in the way.
  rem  '
  temp5 = (player1x-10)/4

  if pfread(temp5,_Convert_Y) then goto __Skip_Joy0Right

 

... Which would be fine, except that's really only effective if platforms are a single line tall, like they are in his example there. If they're the normal, 8-pixel height, that would cause the player to slip 'n slide through all but a line or two of the playfield blocks.

fake_gravity_platformer_with_duck_and_fire_button_2012y_05m_29d_0338t.bas.bin

Edited July 8, 2013 by Cybearg

[+Random Terrain]

In case it might be helpful, here is a version I was working on without the thin lines:

 

fake_gravity_platformer_with_duck_and_fire_and_pfres23_2013y_07m_08d_1559t.bas

 

fake_gravity_platformer_with_duck_and_fire_and_pfres23_2013y_07m_08d_1559t.bin

 

I saved it with a new date so I'll remember what I posted. It's old work-in-progress code that probably isn't ready to be posted. I don't feel like going through it right now to clean it up, so view it at your own risk. I planned on turning it into a game, but it looks like that will probably never happen.

[Cybearg]

Thanks, but it still uses pfreads for left/right movement, which won't do because, though the lines are thicker, they're only about a quarter the height of a normal pfpixel, so you don't much see the kind of problems that I do.

 

I'm mostly looking for some advice as to an efficient way to prevent the player from tricking my collision system by dropping down alongside a solid pfpixel, then getting their movement in the correct direction locked because they were facing that way, allowing them to turn around and walk freely through the playfield. Pfreads for horizontal collision just doesn't work well on low-res playfields.

 

And I still have the same problem with the player falling constantly in this, RandomTerrain. You use pfreads to determine ground collision, correct? Why am I apparently the only one that your code doesn't work for? Are you doing something that no longer works with modern bB versions? Some kind of tricky hack that won't compile in my version?

 

I've attached the result of me compiling your .bas file so you can see what I mean.

fake_gravity_platformer_with_duck_and_fire_and_pfres23_2013y_07m_08d_1559t.bas.bin

Edited July 8, 2013 by Cybearg

[+Random Terrain]

It works with the version of bB in bBWin7_64bit.zip.

[+Random Terrain]

It works with the version of bB in bBWin7_64bit.zip.

 

What version are you using, Cybearg? Is anyone else reading this having the same problem?

[+Gemintronic]

Compiles and runs OK for me. Here is my bB info:

 

batari Basic Compiler date (8/8/2011 7:31:02 PM)

Current bB compiler version supports -O option. Peephole optimizer option enabled.

Current bB compiler version supports DPC+ Kernel. DPC+ options enabled.

 

Has anyone had contact with Fred? Maybe we can put together an "after 1.0" compilation for him to declare version 1.01 or something.

[+Random Terrain]

Compiles and runs OK for me. Here is my bB info:

 

batari Basic Compiler date (8/8/2011 7:31:02 PM)

Current bB compiler version supports -O option. Peephole optimizer option enabled.

Current bB compiler version supports DPC+ Kernel. DPC+ options enabled.

 

Thanks. After we find out what Cybearg is using, maybe we'll be able to find out what is messed up.

[Cybearg]

I'm using batari Basic 1.01, DASM 2.20.07, and vbB 1.0 b566

[+Random Terrain]

I'm using batari Basic 1.01, DASM 2.20.07, and vbB 1.0 b566

 

You might be using one of the screwed up versions that is full of hair-pulling bugs.

 

Have you done the 200 step process mentioned in this post to get the latest non-buggy version in some thread somewhere:

 

http://atariage.com/forums/topic/212872-random-position-on-playfield/#entry2765008

You need the download on page 9 post 224 for 1.1d, then an exe on page 11 post 254.

To fix a timing error, an edit is shown in post 274, and the 2 edits in 275 fix the missile0 color bug.

[Cybearg]

I just tried everything mentioned there, copying and replacing all of my bB files with the ones listed there and applying all the fixes. Your examples still result in the player falling through the ground for me.

[+Random Terrain]

I just tried everything mentioned there, copying and replacing all of my bB files with the ones listed there and applying all the fixes. Your examples still result in the player falling through the ground for me.

 

Can you temporarily switch to the version of bB in bBWin7_64bit.zip and see if it works with that?

[bogax]

I'm using the same bB 1.01 and DASM and 2.20.07

and it works for me

 

Did you change anything in the .bas file?

[Cybearg]

I'm using the same bB 1.01 and DASM and 2.20.07

and it works for me

 

Did you change anything in the .bas file?

No, nothing.

[SeaGtGruff]

I just tried everything mentioned there, copying and replacing all of my bB files with the ones listed there and applying all the fixes. Your examples still result in the player falling through the ground for me.

Can you post the binary file for us to look at?

[Cybearg]

Can you post the binary file for us to look at?

fake_gravity_platformer_with_duck_and_fire_and_pfres23_2013y_07m_08d_1559t.bas.bin

fake_gravity_platformer_with_duck_and_fire_and_pfres23_2013y_07m_08d_1559t.bas.asm

Edited July 11, 2013 by Cybearg