HN Explorer

38 comments

[ 4.8 ms ] story [ 98.9 ms ] thread
trinovantes
IBM is probably the last place I expect to find a game dev tutorial

Are they trying to mimic Digital Ocean's docs to promote their brand?

scaglio
> IBM is probably the last place I expect to find a game dev tutorial

Exactly my thought. Totally unexpected.

samwillis
> Updated 19 November 2012 | Published 20 November 2012

Not only is this an old post published just after DO lunched - but it apparently was updated before it was published…

Anyone who was new to JS in the last five years is going to see the older syntax in this post and be like “what ‘prototype’? Why aren’t they using ‘let’ and ‘const’? Why aren’t they using forEach to loop through that array? Why isn’t this in TypeScript?”…

mvladic
Why would they use forEach? Is that criteria that your code is more modern? Or by forEach you mean: "for (const entity of entities) {...}"?
samwillis
forEach landed in Chrome in 2014 after this post, at the same time as for...of. True that forEach was available in some browsers earlier than that and could be polyfilled. Which do I mean? either.
jsgamedevthrow
I have no idea what its like these days, but back then a ton of those sorts of methods would cause extra allocations (and thus unnecessary GC). That is the very last thing you want in a game engine.
fein
You are correct. Everything that isn't a native for loop (forEach, map, reduce, etc) is slower than a native for loop.

https://leanylabs.com/blog/js-forEach-map-reduce-vs-for-for_...

dahart
Looks like it’s gotten better recently with ratios like 1.5x - 3x; it wasn’t that long ago that using the functional iterators was 10x slower than imperative loops. Still, I have a hard time choosing the functional iterators even the cases that are only 50% slower, and even though I prefer them for how clean and elegant it makes the code. Performance and energy use matters, especially in a physics engine. Defaulting to the slower style might not be visible initially, but is sapping cycles from every corner of the code.
pharmakom
forEach mixes statements and expressions so (imho) is poor style.
Kiro
Maybe it's not true anymore but forEach used to be much slower, which matters when you make a game engine and need to iterate lists at least 60 times a second.
nileshtrivedi
With the right algebra (PGA2D which adds an additional dimension whose unit vector squares to 0), rigid body physics simulation with collision detection/response can be implemented in < 50 lines of Javascript: https://bivector.net/PGADYN.html

Basically in PGA2D, rotations, angular velocity/acceleration, torque etc automatically get handled by geometric product of multivectors. The additional dimension makes all rotations centered at origin, which makes them compose much more nicely.

joshspankit
That website has one of the most elegant simple “wow” moments I’ve ever seen.

I didn’t even notice at first. I just thought “oh that’s cool: they’ve primed the physics so it bounces through neat patterns before settling”. But my brain was gently tapping my shoulder... When I listened to it I noticed it was a hypercube, saw “n-dimensional“, and WOW

cyber_kinetist
I previous had some exposure to rigid body dynamics using the more conventional Lie group notation used in robotics (as seen here: http://hades.mech.northwestern.edu/index.php/Modern_Robotics and https://www.cs.cmu.edu/~junggon/tools/liegroupdynamics.pdf). But I felt the Lie group theory surrounding it were hard to understand (I don't have that much exposure to abstract algebra, I wasn't a mathematics major).

So you think would PGA aid in understanding the weird properties of SO(3) and SE(3) (and its tangent spaces), as well as writing simulation code with it? I know that people use various representations for rigid transformations (screws vs. dual quaternions vs. exponential maps vs. motors), but I am interested which method would work the best in both a theoretical sense (in understanding the kinematics and dynamics more abstractly) and in a pragmatic sense (difficulty of writing and reading actual simulation code, amount of operations used, SIMD-friendliness, etc.)

cancandan
This is great, thanks for the link.
aby7
Published November 19, 2012
onion2k
A rather more modern physics engine for JS games can be found at https://rapier.rs/. It's written in Rust, compiled to WASM, works for 2D and 3D, and it's fast (well, fast for JS anyway).
pwdisswordfish0
Rust isn't JS...
samkon
Compiled to wasm, it can be used in javascript games.
onion2k
Through the magic of WASM compilers every language is JS now.

has nightmare

pwdisswordfish0
No, that's still not JS. JS is a programming language. It doesn't mean "any program that runs in the browser".
onion2k
Evidently the "has nightmare" line wasn't enough of a clue that I was making a hilarious joke.
pwdisswordfish0
It's obvious there was a joke in the comment. It just didn't lie in the conflating-/not-conflating-things-with-JS part of the comment. Also, it was lame.
TheRealPomax
No, now it's web assembly[1], which is a flavour of assembly code that can run in all modern browsers because those browsers add WASM runtimes. It is as far away from JS as you can get while running in a browser. Even Flash and Java were closer to JS than WASM is.

You can implement a WASM runtime _in_ JavaScript (and people have done this, and it turned out to run so well that in some cases the performance hit was basically irrelevant), but that's because JS is Turing complete and any Turing complete system can emulate any other Turing complete system.

[1] https://webassembly.org/

naillo
For a more modern approach (that's one of those rare cases where things have gotten more powerful while getting simpler over the years): https://www.youtube.com/c/TenMinutePhysics/videos (by basically the inventor of PBD, which he barely even mentions/brags about).
rando14775
What is PDB?
naillo
Position based dynamics :) With normal `next_pos = current_pos + velocity * dt` schemes you can get instabilities and it can be non obvious how to implement certain physics phenomena. With PBD you basically define a 'constraint' that particles have to satisfy (e.g. rigid lengths become a 'distances between points must be X') and then you solve for a valid configuration in between renders (basically with gradients descent, though you solve for roots so it becomes newtons method).
meheleventyone
Paper for the extended version here, linking to this one because the extension solves some issues and isn't that much more complex: https://matthias-research.github.io/pages/publications/XPBD....

For a more lay explanation you solve constraints directly by moving elements around and using the difference between their current position and previous position as their velocity. If you've some experience of numerical integration it's quite similar to verlet integration. This approach is good because it lets you have constraints with infinite stiffness without the simulation exploding.

The original papers consider points (like a mass-spring system) but it's also been extended to rigidbodies.

breck
Interesting! This makes sense to me.

I'm new to physics engines—I just started figuring out how to upgrade my simple grid cellular automata engine to a 2D engine for my toy sim tool (https://github.com/breck7/simoji) —and have been surprised by existing implementations, because it just seems not how the universe actually computes. I had not seen PBD before and it seems to be a closer model.