Collision Issue

Blitz3D Forums/Blitz3D Beginners Area/Collision Issue

Crazy4Code(Posted 2006) [#1]
It's hard to explain, but i'm having a problem with the collision between my ship and the asteroids. Download it here and see for yourself. I think it might have something to do with my changing px# and py# instead of using MoveEntity, but I don't know much about that. The ship seems to jump around the screen. I'm thinking it's because px and py keep changing even if the collision happens, so after it's not coliding anymore, it jumps to the spot where px and py are?


Sledge(Posted 2006) [#2]
Personally I would (and have) ditch(ed) the automated collision system and just use(d) meshesintersect(). If it's too slow, use simpler, invisible collision meshes.

However, you might want to try TranslateEntity() first, as your code already generates the values to translate the ship by. I *think* ellipsoid-to-ellipsoid collisions are supposed to work "both ways" (for ellipsoid-to-polygon, by contrast, the dest_type must be immobile) although you *might* have to define a reverse Collisions statement (ie asteroid-to-ship in addition to the ship-to-asteroid one you have). Plenty to try, there.


Crazy4Code(Posted 2006) [#3]
Okay, I used MeshesIntersect(), but it still seems a little buggy. It seems to only tell that they are colliding sometimes, and other times it just doesn't. I tried doing reverse collision statements too.


Sledge(Posted 2006) [#4]
Well I was feeling curious - see what you think of this (and pay particular attention to where the updateworld()'s occur, and how hideentity is used to uninvolve objects from the collision system when warping them from one side of the playfield to the other)...




Sledge(Posted 2006) [#5]

Okay, I used MeshesIntersect(), but it still seems a little buggy.


That is odd - I have always found it robust (the only thing to take care to ensure is that the meshes in question are not flat, which they aren't here). There's no collision response with the command - meshes will just drift through each other, but for Asteroids this is typically okay because as soon as you hit one you're dead!

Depending what you think of the code I posted above, you might not be interested in MeshesIntersect() any more; but if you want me to cast my eye over the MeshesIntersect code you found troublesome then post away.


Crazy4Code(Posted 2006) [#6]
Wait, I found a way that it works. I changed my movement system to use TranslateEntity instead of PositionEntity, then the collisions worked fine. The only thing is to make it work I had to have both "Collisions PLAYER,AST,1,2" and "Collisions AST,PLAYER,1,1" is it normal that I would have to have both of those for it to work?


Sledge(Posted 2006) [#7]

I changed my movement system to use TranslateEntity instead of PositionEntity, then the collisions worked fine.


Great minds... ;)


The only thing is to make it work I had to have both "Collisions PLAYER,AST,1,2" and "Collisions AST,PLAYER,1,1" is it normal that I would have to have both of those for it to work?


I'll say yes, because we're talking about computers and computers are dumb. Just as it is possible to have a one-sided object, it is possible to have one-sided collisions... unlike in the real world, the existence of one "side" does not infer the existence of the other. The first Collisions command is only concerned with what the Ship has hit and until you create an additional command to keep track of what the Asteroids have hit, they can't hit anything.

If you think about it, though, this is smart: If the compiler assumed that every time the ship hit an asteroid you also wanted a record of the asteroid hitting the ship *without you asking for it* the CPU could potentially waste a lot of time collating information that you just don't need. The system is geared for speed and processing no more information than you specifically request.