Notices by Tom Forsyth (tomf@mastodon.gamedev.place)

@mcc Linux is always difficult because you can certainly do it, but only if you discover the incantation. Mac is the easy one, because the answer is "no".

@c0dec0dec0de @mcc There are only two types of build systems - ones you hate, and ones you don't know enough about yet.

@RikerGoogling
https://memory-alpha.fandom.com/wiki/Riker_Maneuver

@eniko Just means you need more dither :-)

@eniko When I was writing drivers for 3D cards back in 1997, one thing our card didn't have was MSAA. But we could of course do dumb SSAA - just render 4x bigger, then shrink down.

I figured out we could do the 4x render in 332 with dithering, then when we did the shrink we'd read that but render to 565, because the extra colour bits came from blending the dithered pixels together.

I sent A/B pictures around the office, and nobody could tell the difference, but it was 15% faster. SHIP IT!

@mattly @mcc Also reminds me of a Discworld character who had precognition, and could answer your questions before you asked them, but then you had to actually ask the question she'd just answered or she'd get a headache. So it didn't actually save you much time.

Not sure how to classify this game. What genre is it even - a herd-em-up? It's gorgeous is what it is. Very intrigued. Well done @benthroop !
https://www.youtube.com/watch?v=Qtf2tJEKRc4

But on the SSE version, a whole bunch of tiny precisions are very slightly different, and a combination of the friction on the floor and the mass of the objects means the guard still rotates from the collision, but now he rotates very slightly less far.

So on the next frame of simulation, his toe is still in the way of the door. The door isn't allowed to just pass through his toe, so it does the only other option - it bounces back. I think by default it's set to do so completely elastically, so the door bounces back with exactly the speed it came in at, slams shut, and locks again. And you're stuck.

And that's why the bug went "back in time" - because yes it's the old code, but we were using a newer compiler with new default settings. In the original build, the compiler defaulted to x87, but in the newer compilers the default is SSE. It's not that one is "better" - the fundamental bug is that the guard was too close to the door, and that had always been there. But in the original the problem "self corrected" and so was never spotted, whereas in the newer compile it became a showstopper.

And there you have it. The two biggest bug-farms in gamedev - doors and floating point - contrived to make a simple NPC placement bug into quite the time-travelling palaver. /end

OK cool now we can ship the game phew. But why did this EVER work? The guard's toe was in the way in the original version as well. As I say, we went back in time and compiled the original as-shipped source code - and the bug happened there as well. It's always been there. Why didn't the door slam closed again? How did this ever ship in the first place?

So this kicked off an even longer bug-hunt. The answer was (as with so many of my stories) good old floating point. Half Life 2 was originally shipped in 2004, and although the SSE instruction set existed, it wasn't yet ubiquitous, so most of HL2 was compiled to use the older 8087 or x87 maths instruction set. That has a wacky grab-bag of precisions - some things are 32-bit, some are 64-bit, some are 80-bit, and exactly which precision you get in which bits of code is somewhat arcane.

But ten years later in 2013, SSE had been standard in all x86 CPUs for a while - the OS depended on it being there, so you could rely on it. So of course by default the compilers use it - in fact you have to go out of your way to make them emit the old (slightly slower) x87 code. SSE uses a much more well-defined precision of either 32 or 64 bit according to what the code asks for - it's much more predictable.

So problem solved, right? 80 bits of precision means the collision didn't happen, but in 32 bits of precision it does, and that's your problem, more bits better, QED, right? Well not quite.

The guard's toe overlaps in both cases - a few millimeters is still significantly larger than ANY of the possible precisions. In both the SSE and x87 versions, the door hits the guard's toe. So far, both agree.

This collision is actually properly modelled - a big innovation of HL2 was the extensive use of a real physics engine. The door and the guard are both physical objects, both have momentum, they impart an impulse on each other, and although the door hinge is frictionless, the guard's boots have some amount of friction with the floor.

On both versions, the door has just enough momentum to rotate the guard very slightly. The guard's friction on the floor is not quite enough to oppose this, and he rotates a tiny fraction of a degree. On the x87 version, this tiny rotation is enough to move his toe out of the way, the collision is resolved, and the door continues to swing open. All is well.

Once we'd figured this out, the fix was simple - move the guard back about a millimeter. Easy. But it took a lot of work to find because people had to dust off old memories of how the debugging tools worked, etc.

Once upon a time, I worked at Valve on virtual reality. This was in 2013 around the time the Oculus DK1 emerged, and Joe Ludwig and I decided that the best way to figure out how VR would work in a real game context was to port a real game to it and see what happened.

We picked Team Fortress 2 as the game - the reason why is a whole different story I won't go into here. TF2 used the Source 1 engine, and as it happened two Valve games also using that same version of the engine were Half Life 2 and Portal 1. So as a side-effect they also got to work in VR.

Well, Portal 1 "worked" - but all the tricks with perspective when you went through a portal were of course a nauseating disaster - it was pretty unplayable.