Christer Ericson

I answer this question over and over on Reddit. So, here’s a wall of text for everyone :)

Here's the list of links I give everyone getting started in graphics programming in general.

The main thing you need to know is https://fgiesen.wordpress.com/2016/02/05/smart/

OpenGL is a good API to start with. There's a lot to learn regardless of which API you use. Once you can do an animated character in a scene with lighting, shadows, particles and basic full-screen post processing, you'll know how to proceed forward on your own from there.

https://learnopengl.com/ https://raytracing.github.io/ https://gamemath.com/book/ https://www.gameenginebook.com/ https://realtimerendering.com/ https://google.github.io/filament/Filament.md.html https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://developer.nvidia.com/nsight-graphics https://renderdoc.org/

A common mistake I see in beginners that you should definitely NOT do is to try to make completely self-contained classes like `tree.draw();`that attempt to set up and tear down all of the OpenGL state required to draw an object. The code required to make `tree.draw(); mainCharacter.draw(); rock.draw(); dog.draw();` work in random order is not only a very slow way to use GL, it is also extremely error-prone because the state set by an earlier object can accidentally affect a later object in unplanned ways.

Instead, it is much better to have all of the code for actually rendering a…

'Fast' is a poor descriptive choice for a library that was clearly written without attention paid to CPU performance characteristics, GPU performance characteristics, or the nature of modern Canvas implementations.

EDIT: A quick glance at the sample game 'O!' in the chrome profiler shows that it is triggering a garbage collection roughly every second. Pretty bad for a game with such low scene complexity and rendering complexity, and those pauses may be long on a mobile device.

Based on a casual review of the source code (which I'll note is quite readable - good job!), here are some obvious problems that probably need to be addressed, both in terms of actual performance and code quality.

Don't render the scene in graph traversal order; doing so ensures that the number of graphics state changes (shader, transform, texture, etc) is as high as possible. Most game engines render using a more sophisticated algorithm where your drawing operations are ordered (as possible - obviously layering has to be preserved) by graphics state in order to minimize overhead.

For some documentation on this approach, see articles like
http://realtimecollisiondetection.net/blog/?p=86
I've been using this approach in my games for years and it produces a huge measurable performance improvement on virtually all modern architectures (even canvas, though it's less significant there)

The tickBefore/tick/tickAfter architecture is particularly suspicious, as is its use of poorly-scaling…

I just looked if there was a newer version of it. There doesn't seem to be, but Christer Ericson does still have a dedicated page for the book. The errata section[0] is surprisingly small given that it is 632 pages. I thought this snippet was interesting:

> All illustrations in the book were redrawn from my original illustrations. Unfortunately, the company in charge of redrawing the illustrations mangled almost all of the illustrations doing so (right angles became accute or obtuse, etc). I thought I had caught all their errors before the book went to print but sadly it seems I missed a few.

Tangent: his 2003 presentation on memory optimisation[1] is also still a very interesting read, especially the last section on aliasing. I wonder how much of those comments still apply to modern languages (or C and C++ compilers, for that matter).

[0] http://realtimecollisiondetection.net/books/rtcd/errata/`

[1] http://realtimecollisiondetection.net/pubs/

Yeah, that's why I loved that industry. A million hard problems to solve. Along that lines Real Time Collusion Detection[1] is solid gold for a lot of these types of spatial issues. It's basically data structures for gamedev.

Aside from the fun problems the rest of that industry can die in a fire. The basic business model is to prey on people's passion so that they pour themselves into the job for 3-5 years and then burn out leaving open a slot for the next poor soul who signs up. There's an occasional studio that has a sane workload but I'd hazard they're less than 3% of the industry. Plus they usually are gone in 5-7 years when the market shifts(10% of the market captures 90% of the sales).

Building stuff in your spare time is the only sane way to spend time in that space as far as I'm concerned, otherwise you're setting yourself up for a world of pain.

[1] http://realtimecollisiondetection.net/

Completely disagree - convex collision detection is a neatly solved problem. SAT [0] is implementable in a couple of hours, and GJK [1] is a really neat algorithm that takes a ltitle more than SAT to implement. For optimising collision detection there's some spatial partitioning [2] algorithms that work really well.

The gnarly stuff comes in when you're trying to figure out contact points and impulse responses and apply them without blowing everything up. I've written some of this stuff for a few games now, and the resources below have stood the test of time IMO

[0] https://dyn4j.org/2010/01/sat/ [1] https://realtimecollisiondetection.net/pubs/SIGGRAPH04_Ericson_GJK_notes.pdf [2] https://allenchou.net/2013/12/game-physics-broadphase/

A sphere-frustum check is a lot cheaper than a box-frustum check. The spherical test only has to check the distance of a single point to the frustum, a box intersection test is much more complex.

There are some false positives, but as with many things in game development 'close enough' usually works pretty well.

If you're really concerned with efficiency you should look into other data structures than an octree. Octrees are a nightmare for cache performance (like most other tree based structures) and cache utilization is usually the bottleneck on modern CPUs.

If you're interested in the subject this book (http://realtimecollisiondetection.net/books/rtcd/) covers everything extremely well.