61–70 of 70 posts
Are there any tools that can generate this from comments, or perhaps an Eclipse or Visual Studio plugin that shows this type of documentation along with the code?
I love the look of the annotated code. I think it would be particularly useful for documentation. Are there any tools that can generate this from comments, or perhaps an Eclipse or Visual Studio plugin that shows this type of documentation along with the code?
Nice code. Thank you. Are those ball-to-line collisions energy preserving? I believe they are... However it seems there might be an edge case, where moving a colliding circle until it no longer intersects the line, might cause it to skip past another line. Because of this, the lines should not intersect each other. Sorry to ramble but I love this sort of stuff. Collision detection is covered well in many game develop…
But... I guess this won't be the first time someone posts bad physics code on the internet and poses it as a good example.
Nice code. Thank you. Are those ball-to-line collisions energy preserving? I believe they are... However it seems there might be an edge case, where moving a colliding circle until it no longer intersects the line, might cause it to skip past another line. Because of this, the lines should not intersect each other. Sorry to ramble but I love this sort of stuff. Collision detection is covered well in many game develop…
Yeah he should be getting the starting & ending position of the ball during the tick, and determining whether that line intersects the other line. If it does, the intersection point should be found and the segment that goes past the line should be reflected over the normal, and the ball placed at the new endpoint of the reflected segment. And, of course, the velocity vector needs to be changed as well. But... I guess…
Of course, this is what physics engines do, and why you should probably use one instead of reinventing the wheel.
In terms of showing how a game loop and really basic game physics works, however, this is a pretty clean and understandable example.
Nice code. Thank you. Are those ball-to-line collisions energy preserving? I believe they are... However it seems there might be an edge case, where moving a colliding circle until it no longer intersects the line, might cause it to skip past another line. Because of this, the lines should not intersect each other. Sorry to ramble but I love this sort of stuff. Collision detection is covered well in many game develop…
Yeah he should be getting the starting & ending position of the ball during the tick, and determining whether that line intersects the other line. If it does, the intersection point should be found and the segment that goes past the line should be reflected over the normal, and the ball placed at the new endpoint of the reflected segment. And, of course, the velocity vector needs to be changed as well. But... I guess…
The OPs code is fine. And was written by a she, not a he.
Your suggestion is what is sometimes called 'continuous' collision detection. It is needed in some cases, particular when the OP approach might miss collisions (less often for when knock-on-collisions are missed, since those are rarer). But that approach is not 'better' - it is far more time consuming (vastly more for 3d rigid bodies with angular velocity), and has a visual benefit in some cases (not in the OPs case - or at least you wouldn't see the difference).
But, of course, both approaches are very approximate and only intended to give the right feel. If you wanted to be even more accurate you would process your collisions by subdividing updates around the collision (a good pool-ball simulation does this, to model proper breaks). And you'd have to use different integrators than the 1st degree Newton update.
This process can keep going as far as you like. For physics systems I've worked on for modelling the behavior of rigid components in MotoGP bikes, the kinds of approximations you allow are very different to the physics engines I've built for commercial games. Neither are 'better' or 'worse' - a good programmer understands the requirements of their domain . To that extent, the OP's approach is fine, and powers the vast majority of the physics in current generation video games (most engines do support continuous collision detection, but it will be switched off for most rigid bodies in a scene, for performance).
That's pretty educational. OT: I'm not a game developer. What are the other patterns - besides the global state and mutation functions - that one can use for a game loop?
The main loop then steps through each component (of which physics would be one) and lets it update the entity data for all entities.
This pattern took over from class/inheritance based architectures about 10 years ago.
There have been some suggestions that Functional Reactive Programming is a better approach. I've used it in some prototypes, but I couldn't scale it to engine-size, and I'm not aware of it having been used successfully for a full game engine.
So, this approach is pretty much it. You keep a database of state, then you run a system (the physics system, say) to update that database.
[1] http://t-machine.org/index.php/2007/09/03/entity-systems-are...
Just have to say, it gets more amusing with more balls and lines: https://zifnab.net/circles-bouncing-off-lines/
Earlier quoted context omitted.
I wonder if the weaving in literate code is one of the things that could only have been invented to deal with Pascal. It is useful to be able to rearrange the presentation even in JavaScript, but I doubt it would be enough of a pain point for people to invent weaving in an alternate history were literate programming was born on more flexible languages.
I wrote a literate-programming compiler to deal with JavaScript programming (any language works, but js is the one I use the most); it use markdown as the language in which the code is embedded. For me, prototype setup and async stuff seemed to naturally lead me to want to differ in the ordering between how I write and how the program is laid out. I find it quite liberating to not care what order I write the code in,…
To be honest, I was mostly thinking of Haskell when I wrote my comment. (Semi-) Literate programming is quite popular in their world, and Haskell gives you great flexibility out of the box to order your code. (And even there, having a more flexible order can help, but it's not as urgent.)
qznc makes a great argument for weaving different languages.
Earlier quoted context omitted.
Yeah he should be getting the starting & ending position of the ball during the tick, and determining whether that line intersects the other line. If it does, the intersection point should be found and the segment that goes past the line should be reflected over the normal, and the ball placed at the new endpoint of the reflected segment. And, of course, the velocity vector needs to be changed as well. But... I guess…
Hmmm, you appear to have a high opinion of your ability to determne 'good physics code'. Unfortunately, just a high opinion, not a high ability. The OPs code is fine. And was written by a she, not a he. Your suggestion is what is sometimes called 'continuous' collision detection. It is needed in some cases, particular when the OP approach might miss collisions (less often for when knock-on-collisions are missed, sinc…
while (trig.isLineIntersectingCircle(circle, line)) {
physics.moveCircle(circle);
}Earlier quoted context omitted.
Hmmm, you appear to have a high opinion of your ability to determne 'good physics code'. Unfortunately, just a high opinion, not a high ability. The OPs code is fine. And was written by a she, not a he. Your suggestion is what is sometimes called 'continuous' collision detection. It is needed in some cases, particular when the OP approach might miss collisions (less often for when knock-on-collisions are missed, sinc…
You're right, there's a gradation of compromise, and I wasn't fully polite in my comment (nor did I think to attempt to determine OPs sex... then again, I'm a guy with a "girl's name", so who's to say "Mary" is necessarily a girl? aaaanyway...). I'm not suggesting that all software must compute integrals in order to have convincing physics. However, when I see code like this I involuntarily get itchy: while (trig.isL…
You bring up a slightly different issue now, which I'm not sure if you are suggesting the problem is with the unbounded loop or with the serial strategy for resolution.
On the former, I agree with in the narrow (interpenetration resolution isn't usually guaranteed to converge), but taking
while (has_interpenetration()) {
resolve_interpenetration();
}
for (int i = relaxation_steps; i > 0 && has_interpenetration(); --i) {
resolve_interpenetration();
}
On the latter, modern game engines do some steps globally, rather than just running through each rigid body (often collision detection, interpenetration resolution, resting contact resolution, but not normally collision resolution or integration). But the OP approach of running everything in series wasn't unusual 15 years ago when game physics systems started to become ubiquitous. Before companies like Mathengine and Havok perfected LCP approaches, folks like Ipion and FastCar were doing impulse-based calculations that were heavily serial. So for a very simple JS experiment, it didn't strike me as a problem. I'd have written it that way too, if it were me.