3 ms·
What you say is true for regular websites, but game code has different needs than the type of JS you normally use in websites. I've seen people do some very na
by vanderZwan 9y ago
What you say is true for regular websites, but game code has different needs than the type of JS you normally use in websites.
I've seen people do some very naive stuff, like:
var particle = {
color: randomColor(),
position: new Point(x, y),
// number of frames the particle lives
decayIn: 50 + Math.ceil(Math.random()*100),
};
... for very short-lived particle effects.
This does not scale if you want to draw thousands of particles that each last a few seconds.
If they were smarter about it, they could create a pre-allocated "pool" using a maximum nr of particles and re-use them.
Likely to be even faster would be preallocating one Uint32Array (for color), two Float64Arrays (one for x and y), and one Uint8Array (for decayIn), and then use an index to look up an individual particle's color, x, y, and remaining frames.
Anyway, what I'm saying is: idiomatic JS definitely can result in garbage collection-related bottlenecks for game development, but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays).
- vanderZwan 9y ago> but a lot of this can be avoided by using non-idiomatic coding styles (like heavy dependence on TypedArrays). Too late to edit, but this really should have finished with: ... at the cost of code that is more verbose yet the opposite of self-documenting, inherently frail even if you put wrapper-functions around those typed arrays, and likely to require massive changes all over the code-base for the smallest updates. In my opinion, unless you have a really good reason to not use alternative options like WASM or Emscripten, trying to squeeze that kind of performance out of vanilla JavaScript it's unlikely to be worth the technical debt.