New Collision System

[DivFord]

I'm planning to re-do collisions.

• Collision will be a class.
• It will have the current room and the player as members.
• It will have functions to check for collisions with player, blocks and props.
• Among other things, that should allow props to check for player collisions on canMove, and, if they return one, to call Push on the player. If the player can move in the direction pushed, he gains velocity, if not, we kill him. That allows rise blocks to lift the player, and only kill him if they crush him against something.
• If projectile checks for collisions on all blocks, it can then choose to affect movement based on the isTraversable property, and apply effects independently of that.
• I may as well implement bounding boxes while I'm at it...

Thoughts?

[Fyll]

Slow, but steady(ish).

I've got it to the point where I'm trying to get the collisions to work properly (currently, for some reason, things fall /slightly/ too far and get stuck in the thing beneath them). Once this has been fixed, I'll stick the player in, then it should be back up to where it was before (but better!).

Seeing as I've deleted several files and added a few others, what's the opinion going to be on pushing? I've copied all of the old files into a spare folder, but I don't want to push and completely overwrite your stuff.

[DivFord]

No problems on my end. I've been working on art, not code, so I can implement all that after you push.

[Fyll]

Just a question of interest, how elastic do we want the collisions to be? At the moment (perfectly elastic) everything is hilariously bouncy. I'm almost loathe to stop it from being so. :P

EDIT: To clarify, do we want things to have individual bounciness, or just a global bounciness?

[DivFord]

If individual bounciness is achievable, I say go for that. Rubber blocks could be fun, later on :)

[mspraggs]

I made one commit, and I think it was relatively minor. You'll probably need to pull anyway before you push.

[Fyll]

Okay. The code re-write is all done and pushed. Feel free to pick it apart and point out any obvious bugs.

[DivFord]

And on New Game Day as well. Bravo.

Having tested it briefly, it seems to function, but feels horrible :P I think part of that may be the animation being out of sync with the movement. Is it possible to disable animation (except left and right facing) while we tune the controls?

I take it movement is acceleration-based now?

[DivFord]

Collision is still a little dodgy:

I made the blocks fall in left-to-right order, so that glitchy block is getting stuck on the top-right corner of the one to the left of it.

[DivFord]

Also with the magnet hand. I think it's because I stood on top of the block to push it...

[Fyll]

Movement is acceleration based. As you say, the numbers do need tweaking. If you want to disable player animation, it's all in Player::updateSprite(). When it calls setGFXStuff. If the last parameter is 8 (frames), change it to 1.

There's a slight problem in that you can push crates still. Only very slowly, but you can move them around by bumping into them. If you pushed the one on the left across a little bit, the one on the right will have landed on top of it. I'd be tempted to try to fix this by pushing things from their centre of mass. That'd make the crate above push the bottom one slightly to the side so it can fit (I think).

Yeah, the magnet hand is wierd. I'd forgotten it was as bad as it was (seeing as it rarely turns up in a level).

I'll have a look in to fixing these tomorrow.

[mspraggs]

Iain could you summarize what changes you've made? It's a bit difficult to tell as everything is so different.

[mspraggs]

Also I really like the way everything behaves now. I can see a few bugs, but the physics seems a lot more predictable, and the game more stable!

[Fyll]

The key thing (I think) is that instead of having an array containing the tiles in the level, they're all just pushed into a vector (so may not necessarily be in the right order). Players, Blocks, and Bullets are all Objects, and Props are Blocks. Object has a function for checking if it's collided with a given Object, and then tries to use physics to make them bounce off of each other (in collideEx()). If any two objects have collided, they each get told who they collided with, then act accordingly in their own collide() functions (i.e. Bullets die, crates smash). If they did change as a result of the collision, they each get checked again in case it has a knock on effect. This is unfortunately where every segfault I've seen has come from, and I'm not too sure why.

I think those are the key points...

[DivFord]

Could it be that bullets are colliding with things, so the bullet to thing collision is checked, and the bullet is destroyed, then the thing to bullet collision is checked, and the bullet no longer exists?

[Fyll]

Nah, things don't get destroyed until after the collision checking loop. As it happens, the Magnet gun segfaults were due to this, as it kept getting accelerated by the bullet, which meant it had to be rechecked, but then it accelerated again, as the bullet hadn't been deleted yet. This should be fixed in the pushed version.

EDIT: Admittedly, I haven't seen the segfaults in a while, so they could have been cleaned up already (I'm not counting player crush segfaults, as that's something else).

[DivFord]

I was able to push it a little bit, but then it segfaulted.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libbackend.dylib 0x000000010e57d29f Vector::operator/(float) const + 47 (Vector.hpp:19) 1 libbackend.dylib 0x000000010e57929e Object::mid() + 62 (Object.hpp:46) 2 libbackend.dylib 0x000000010e57e0f7 Block::collide(Object) + 839 (Block.hpp:54) 3 libbackend.dylib 0x000000010e58ecdf Object::collideEx(Object) + 63 (Object.hpp:67) 4 libbackend.dylib 0x000000010e58a532 Game::collisionCheck(Object, Object) + 1218 (Game.cpp:212) 5 libbackend.dylib 0x000000010e58a5d0 Game::collisionCheck(Object, Object) + 1376 (Game.cpp:216) 6 libbackend.dylib 0x000000010e58a5d0 Game::collisionCheck(Object, Object) + 1376 (Game.cpp:216) 7 libbackend.dylib 0x000000010e58a5d0 Game::collisionCheck(Object, Object) + 1376 (Game.cpp:216)

[Fyll]

Push what?

[DivFord]

The steel crate. I thought we were still talking about the magnet hand segfault.

[Fyll]

Have you pulled the latest version (also, the magnet gun should pull, not push)?

[DivFord]

Ah. The segfault was me crushing myself with it then…

Good idea though. It's much more intuitive for a magnet to pull metal. We should maybe remove the recoil though, if you haven't already.

[Fyll]

Yeah. Crushing's an iffy thing. I need to check if you're being pressed in two opposite directions with sufficient force. Actually, it sounds wuite easy when I put it like that...

Anyway, I believe the reason it segfaults when you get crushed is because of the mass difference between you and the crate (and order of 100). This could be solved if I could stop you from pushing things, as then the crates wouldn't need to be so heavy.

[DivFord]

Could you just add a lockX and lockY parameter? Set lockX to true on crates, then they can't be pushed sideways. Does that work?

[Fyll]

What if a steel crate is "thrown" into one of them? Should it move then?

[DivFord]

Interesting… I'm not sure.

[Fyll]

If so, I just need to put a type() check, and not do the x-direction of it's OBJ_PLAYER, otherwise, I'd remove the x-direction for everything /but/ the player.

[DivFord]

Fair enough. That would make more sense.

[Fyll]

Okay, pushed. You can now no longer push things by walking into them or jumping at them.

By the way, I'm liking the new graphics!

[DivFord]

Yay! To both.

[DivFord]

A couple of points:

1) If you pull the steel crate into the air, then against another prop (haven't tried with blocks) it sticks there.

2) You can lift the steel crate while standing on it. Which is awesome, but you're supposed to be a physicist...

[Fyll]

1) Hmm. I managed to recreate this, then I changed some code, and now I can't, so I assume it's fixed.

2) True, but unless we want to just pull the player towards the crate (considering the mass difference), we're going to have to have a bit of suspension of physics.

[DivFord]

Eh. I can live with that. It's pretty neat. Better make sure we let Alessandro know.

[Fyll]

Well, the numbers still need to be tweaked everywhere (the cannon-jetpack is back, now with a magnet-hover feature!), so it could end up that the gun is weakened. It should just be a case of changing the numbers in PropList.

Also, squishing should work now.

[Fyll]

Okay. Any new comments on the new collision system should be put in their own thread, as this one's getting a tad cumbersome.