Should positions be defined as ints or floats?

Started by
21 comments, last by Sean_Seanston 12 years, 9 months ago

I suppose really, I'd like to both complete my current game and learn something from implementing this kind of algorithm if at all possible. Shortcuts are nice, but like Seriphis said, it's nice to have the satisfaction of doing things like this yourself, especially when it's such a core concept in game development.

I see Box 2D is open source... I might research that a bit and see if I can learn anything. Are there no relatively popular articles/tutorials around about this kind of thing though? I could swear I heard a lot about this kind of thing before I decided to actually try it myself, but then I dunno.

Is making 2 moving 2D objects collide with each other really that difficult? Maybe destroying one of them outright is much more common I suppose... I could look into just doing that for the purposes of my current game but I'd still like to be able to collide things like this.


I think collision detection has fallen out of favor in the research communities for the most part due to the fact that there are plenty of open source/closed source solutions available and very few companies are willing to fund teams to write in house solutions instead of just using an existing library. Now, given that, if you want some of the older research you might start by looking at CCD (continuous collision detection) which is the primary solution anymore. Going through the Box2d code is probably the most likely learning source as it puts all the various pieces together in context. Or, the book Realtime Collision Detection For Games (think that's the one based on Solid) which does a good job of going through all the problems and how to solve them.

And just to be complete, some more searchable terms which are all generally related to collision detection in various ways:

Penetration calculations (say sphere/sphere, sphere/box etc)
Sweep and Prune
Time of contact calculations (again, various primitives)
All forms of closest point calculation with various primitives.

Lots more but the above can keep you busy for a while.
Advertisement



I've even seen the same error in 3D games that used tiled terrain meshes that displayed seams due to rounding errors




yes it is a question of rounding error, but it happens most likely because of a T-junction in the terrain mesh. If the adjacent tiles have exactly the same edge positions, there shouldn't be any seams visible.

Best regards!



Lots more but the above can keep you busy for a while.


Cool, looks like it should. I'll see what I can figure out and move forward based on whatever I find...

Thanks.

This topic is closed to new replies.

Advertisement