Christer Ericson

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/

Interestingly you can find a lot of good tips in the optimization section of 'Realtime Collision Detection ' https://realtimecollisiondetection.net/

Pure gold, indeed. It is a very important reference book (can be found in Amazon both new and used), not only for collision detection, but also for space partition, geometry, code optimization, etc. Also, the author has an amazing blog in the web page of the book: http://realtimecollisiondetection.net/blog/

A few years ago when I needed to write collision detection for a variety of specialized cases, I found the book "Real-Time Collision Detection". It is one of the few really comprehensive resources I was able to find on the topic. The example sources are C++ but the concepts apply to 3d in any domain. The website for the book is http://realtimecollisiondetection.net/

Christer Ericson's book "Real-time Collision Detection" covers all this and much, much more in a very readable (IMO) fashion. The companion website for the book is at http://realtimecollisiondetection.net/ and the blog on that site can be just as invaluable a source of information as the book itself.

It predates dolphin's use of it, though don't ask me by how long. Here's a reference to the term from 2008: https://realtimecollisiondetection.net/blog/?p=73

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_not… [2] https://allenchou.net/2013/12/game-physics-broadphase/

I always give my students these to read when I teach design patterns :-) https://realtimecollisiondetection.net/blog/?p=44 http://realtimecollisiondetection.net/blog/?p=81 "The “Design Patterns” book is one of the worst programming books ever. Yes, really. I’m 100% dead serious when I say that I think it has set (and will continue to set) the progress of software development back by decades."

Christer Ericson's 'Real Time Collision Detection' is a killer reference on the topic, and he used to run a super interesting blog [1] on various mathy things related to game development. [1] http://realtimecollisiondetection.net/blog/

Interesting question from the interviewer, who must have neither friends nor family ;) One source of salary information, probably relevant to you, being a non-US type, might be the H1-B database: http://www.foreignlaborcert.doleta.gov/performancedata.cfm (select Performance Data tab, download latest PERM spreadsheet) See, for example, this blog post: http://realtimecollisiondetection.net/blog/?p=107

http://realtimecollisiondetection.net/blog/?p=107 Christer Ericsson, a tech director at Sony Santa Monica (God of War) has pulled out all the figures for game developers a few times. As a point of reference, in my experience, game developer salaries tend to be ~10% higher than a similar role at Microsoft/Google/Apple but with poorer benefits.

As far as I know, salaries are included in H1B visa database. Ah, here's the article where somebody mined it for game developer salary: http://realtimecollisiondetection.net/blog/?p=107

By demanding copyright assignment and then paywalling, they are directly reducing the social utility of this research work by drastically limiting its audience. They have even threatened web authors for merely linking to copies which belonged to the authors rather than themselves: http://realtimecollisiondetection.net/blog/?p=101

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.

The source data is linked to in the About section in the website. I don't have the original HN thread, but the blog post itself was this: http://realtimecollisiondetection.net/blog/?p=70

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/

'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 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-p… 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…