Okay, here's what I mean... I've drawn a diagram that I hope is easy to follow, illustrating 2 different cases of movement and a resulting collision, where the objects' positions + velocity result in the same positions in each case but where different behaviour would be expected:
In the diagram, the green shapes represent objects in their initial positions, red shapes represent their initial positions + velocities, and red arrows represent direction of movement to make it slightly clearer.
In Case 1, Object 1 slams into the side of Object 2 as it travels upwards. The desired effect would be for Object 2 to be unaffected and Object 1 to be repositioned as close to Object 2 as possible along the X axis without overlapping with it.
Case 2 results in the same end positions if the velocities were to be added to their previous positions, but this time, Object 2 is coming up from beneath Object 1 and colliding. Here you'd want Object 1 to be unaffected and Object 2 to be repositioned next to Object 1.
How might you factor all of this into such an algorithm? Clearly, the initial positions must be taken into account but I don't trust myself to come up with something that works without a maze of if statements or switches and elaborate boolean statements.Then of course it has to work on all other cases such as diagonal movement and with only 1 and both moving etc. etc.
In all honesty i would stick to floats for position and stop trying to do this yourself, go look at box2d and more than likely it solves all your issues without me getting into all the reasons even the correct answer to this can fail in "other" cases. I stopped trying to do my own physics (in cases where I cared about the complicated potential interactions) when Pentium 2 was new and shiny. It's just not worth the effort if you can use a very well tested library for free.
I hate the phrase "It's just not worth the effort if you can use a very well tested library for free."
It is worth every effort to try and build it yourself, the reward from figuring out this kind of problem is fantastic when you can sit back and say, "geez, i've just worked out (sure with a little help) how to do something that some of the best programmers in the world have issues with".
If you don't have much experience, you should definitely go with floating point, and preferably use an existing library. Box2d is pretty good.
I'm currently working on a fixed point physics engine, and it definitely isn't easy. The main thing is that it forces you to think very carefully about all your algorithms. Fixed point has some advantages, such as better portability, robustness, determinism, and more control over precise errors, but it also takes a lot more work to implement. Note: performance is not an advantage, at least if you're targeting modern CPUs.
I trust exceptions about as far as I can throw them.
I hate the phrase "It's just not worth the effort if you can use a very well tested library for free."
It is worth every effort to try and build it yourself, the reward from figuring out this kind of problem is fantastic when you can sit back and say, "geez, i've just worked out (sure with a little help) how to do something that some of the best programmers in the world have issues with".
That really depends on your goals.
If your goal is to do something hard, then sure, masochistic wheel-reinvention is great; if your goal is to make a cool game, why bother?
Well in some cases, the gameplay you want can't be supported by an existing physics engine. And obviously there are other possible reasons too. But I suppose that was a rhetorical question.
I trust exceptions about as far as I can throw them.
the gameplay you want can't be supported by an existing physics engine[/quote]
and in some cases can be as hard to understand and use effectively as writing it yourself.
In short, if you use a tool to do something you dont understand yourself how can you prove its working?
Monkey's can use calculators and they will work as intended, but garbage in = garbage out.
In short, if you use a tool to do something you dont understand yourself how can you prove its working?
Monkey's can use calculators and they will work as intended, but garbage in = garbage out.
I can't really think of an example of using a library where you would not be able to asses whether the results are expected or not. After all, you wouldn't be using the library in the first place unless you were using it to solve a specific problem. More to the point, by using library code, you know it's been road tested. Rolling your own? Well, you'll be spending a LOT of time testing to see if the results are as expected, time that would be better spent actually developing your game. If you want to roll your own for academic purposes, sure, why not. But for production, I really cannot the justification for investing so much time re-inventing the wheel.
I hate the phrase "It's just not worth the effort if you can use a very well tested library for free."
It is worth every effort to try and build it yourself, the reward from figuring out this kind of problem is fantastic when you can sit back and say, "geez, i've just worked out (sure with a little help) how to do something that some of the best programmers in the world have issues with".
I don't dissagree with the sentiment but if the intention is to complete a game, getting stuck on a complex problem such as this is the wrong thing to do. If this is purely learning and or experimental, sure, write it yourself and learn the wonders of multi-contact/penetration issues which make even the 2D case a nightmare of complexity. As such, been there, done that, don't suggest it unless you really want a headache.
[color="#1C2837"]This is hardly true at all. All operations done on the a graphics card are floating point from fragment transformation to rasterization. Floating point values are valuable to the graphics card. Anti-aliasing requires sub-pixel measurements. When it comes time to writing the color to video memory a simple integer truncation is performed, no rounding. And to get technical, you can have a discrete set of decimals. Think of a set containing values in increments of 0.5..
2D tilemap based games rarely use anti-aliasing, specially those that use the sharp edges of pixels as an aesthetic resource instead of trying to compensate it, and the graphic error I mentioned is a very common one that I've seen in many games that assumed the graphics card would do all the magic for them, I've even seen the same error in 3D games that used tiled terrain meshes that displayed seams due to rounding errors
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.
