Oops! I actually wrote this article one year ago but never finished it. Let’s say it’s finished, and boom! released.
This is a follow up on the previous article about our fiber-based job system. It contains a few details about our implementation, what we found to be important or not.
You may have heard of Meltdown and Spectre. In January, these two new security vulnerabilities were made public, and it was kind of a big deal: all modern processors were more or less vulnerable, all systems affected, they could steal your passwords and everything.
Things have settled down a little bit since then; security patches have been released and no actual attacks have been reported. But still, discoveries of that scale are not common, so I was curious: How do these vulnerabilities work?
The explanations I could find on the Internet came in two flavors:
the one for security experts (extremely technical, very hard to follow) and the ones for scared customers (that will make you doubt everything you known about computers).
So I decided to write my own: for people that have some knowledge about CPUs, but no interest in actually exploiting the vulnerabilities.
I attended a Game Connection master class this year again. This time it was with Jason Gregory (Lead Programmer at Naughty Dog) on concurrent programming, and it was very interesting.
I won’t give a full account because we saw way too many things (500 slides!).
Instead, I’ll just write about a few spin lock implementation tricks that he showed us.
We have a fiber based job system at Pastagames. I started coding it just after seeing this Naughty Dog GDC Talk back in 2015. And so far, we’re really happy with it.
In this article, I’ll focus more on how we use it than on how we implemented it ‒ our implementation is very close to what Christian Gyrling presented in his talk.
If you haven’t seen the GDC Talk yet, you should watch it first. It’s very interesting and it’s probably necessary to follow what I’m talking about.
Strings are often used as identifiers in games: object names, sound effect names, particle type names, etc. They’re a bit like enums with the advantage of allowing your game to be data-driven: you don’t necessarily need to recompile your program to accept new values.
But strings are no fun: storing them efficiently is a headache, they’re bigger and they’re slower than enums.
Fortunately there’s an alternative: string hashes. We like them a lot at Pastagames, and here are our humble solutions to the practical problems that come with them.
I attended Mike Acton’s master class during last year’s Game Connection in Paris.
Unsurprisingly it was about data-oriented design, but it was a workshop, a practical exercise, and it showed us (or at least me)
a new facet of the concept, as well as a few interesting techniques.
I feel like I’ve been saying this a lot lately ‒ at least once per intern we take at Pastagames ‒ so I guess it’s time I write it down.
There’s nothing new here, this has been said a hundred times over on the Internet,
but since a lot of people are still not aware of it, here is my contribution.