A time-travelling door bug in Half Life 2
mastodon.gamedev.place
mastodon.gamedev.place
This reminds me of another story with FPU involved. I was a game developer once. We were making a game that consistently triggered assertion failures related to FPU calculations, but only on a single PC in the whole office. The game was explicitly setting FPU precision to 32 bits at the start to make all calculations more consistent. However, on that particular PC, there was a fancy hand writing input software that injected its DLL into every process. As you've probably already guessed, that DLL did FPU mode reset to the default in the event handling loop (i.e., main thread). I had to shift FPU mode setting code from process initialization to the event handling loop to be able to deal with the damage that third party DLLs could inflict.
I'd also love to play Portal, actually. They say it makes you sick, but to my knowledge I'm immune from VR motion sickness, so worth a try...
The real truth is they moved out of the game development space and embraced the game platform space letting their old products wither and die.
Alyx just hasn’t been quite enough motivation for me to take on the project of figuring out how to get it hooked up and working, though I did at one point do the few minutes of googling to confirm it might work (I think it’s one of those Facebook ones, and as I recall it is supposed to work for Alyx but I’ll need some cable or other). Especially since it’s a fairly short side-story, it’s just not enough juice to be worth the squeeze.
The conclusion of the series (until it’s not the conclusion any more—yeah, I know how franchises work, lol) though? That’d do it.
If I already had it out and used it regularly I’m sure I’d have played Alyx by now, but with that being the only thing I have any interest in doing with it, just not enough to get me to set the thing up for that alone.
It's been a while since I've played HL2 but this isn't exactly how I remember it. While a lot of things were physics objects I thought the doors would just smoothly rotate towards their target position without any physics at all. You can't bump them shut with another physics object for instance.
This was a popular griefing tactic when TF2 first came out where you could trap everyone in spawn by crouch-jumping into the spawn door as Scout: https://youtu.be/JUPzN7tp7bQ?t=243
I stuck a tire in a door frame and tried to close it, the tire emitted a bunch of dust clouds as the two objects fought before the door finally ejected the tire at high speed.
I wonder if speed runners have found ways to abuse this...
https://wiki.sourceruns.org/Infinite-Health-Door.html
In Half-Life 1 there is a map with two doors that deal negative crushing damage, so you can wedge yourself in them to give yourself a massive over heal
I wonder if the term "impulse" here has any connection to the various impulse commands available in the source engine. I remember using "impulse 101" and causing havok in the opening plaza area. Spawning zombies on the roofs, sending them after the combine, etc.
In quake, the impulse commands were used mostly to switch weapons[1]. I'm not really sure about the naming though, why choose the word "impulse".
[0]: https://en.wikipedia.org/wiki/GoldSrc.
[1]: https://github.com/id-Software/Quake/blob/0023db327bc1db0006...
The impulse command sends a command to the server instantly, rather than in the usual UserCmd sent to the server 30 times per second. They are used mostly for debugging, just assign #90 to your debugging function, then poke it from the console while the game is running. No need to change and potentially break the network code.
It turned out to be an x87 bug where a piece of code was actually computing the wrong answer!. Logically following the code would make you think that the particular failure in question would never happen - and yet it did. That was quite a rabbit-hole to go into to figure out.
And some of those posts are way longer than tweets used to be, but we're still splitting them for no real reason than to make them tweets instead of blog posts?
It was always fun to play on a new server and check what OS it was running that way, too. :-)
One advantage of this is that it will become very easy to not only build the original source of the game, but also build it with the original toolchain and dependencies, the toolchains for those dependencies, etc. etc., all the way down.
Hopefully something like that at your finger trips would have made finding the root cause of this bug a good bit easier!
They’re using Arch Linux. Let’s call it a win and move on lol.
The goal with Nix should be that you can use the same infrastructure for all of Linux, macOS, and Windows. (And other Unixes, other OSes, etc. etc.)
What is the current story for using Nix to build Windows binaries?
Native Cygwin builds are also currently in progress: https://github.com/NixOS/nixpkgs/pull/447520. I would expect this to be done very soon, there year even (holidays permitting).
There is a MinGW build of Nix but it is missing some features. There has been MSVC build of a fork in the past and I would like to revive that also.
There some some open questions relating to Nixpkgs's heavy use of Bash, but longer term I would like to compete for Windows in all ways:
- Support all cross (MinGW, Cygwin/MSYS2, MSVC ABI with LLVM, MSVC with Wine) - Be Cygwin packages - Be https://github.com/msys2/MINGW-packages / https://github.com/msys2/MSYS2-packages - Be VCPKG
All these things have slightly different trade-offs, and Nixpkgs is very good at portability, so we should simply do them all.
You could also try the newer version of the codebase with the older tools (assuming nothing broke / no newer C++ features) if you like.
edit: wayback machine doesn't work, though !ais does:
Edit: since this post was second chanced, I can add on that some of the pre-PC consoles have weird floats too. If they had floats at all. Lots of fun for emulation developers. Even fun for contemporaneous game developers... PilotWings on the SNES comes with different revision accelerator chips and the demo only works properly on the early revision chips (but I think? the later revision chips have more accurate math). The PS2 FPU has weirdness around NaN, Infinity, very large numbers, and denormalized numbers. Etc.
I debugged some software synthesizer code a while back (like 20 years or so now I think of it) where a build of it on one platform failed because of a precision bug. I can't remember the details, but there was a lot of "works fine on my machine" type discussion around it. Anyway it relied on a crude simulation of an RC circuit reaching very close to 0 asymptotically to trigger a state change, but on something like 64-bit Intel with a specific processor it never quite made it low enough to trip the comparison because of something to do with not flushing denormals.
From an electronic standpoint, making it simulate "it's high enough" as being about 0.7 and " it's low enough" being about 0.01 was far closer to the instrument they were trying to simulate, and making it massively imprecise like that got it going on everything.
We take how fast hardware floating point is for granted. I suspect it would be interesting to compare something compiled with softfloat with a normal benchmark and see just how bad it is.
It's a great reason to do your DSP code in fixed-point, which is just integer with a couple of steps you have to write down on paper to keep straight until you get to the end. Or, I do, because I suck at arithmetic. Just do it all in machine-length signed ints, and forget all the mystical world of tiny tiny floating point values ;-)
I remember this dps site with lost of c and delphi code, there is where I found what denormals are.
Nowdays I dont see DPS code dealing with denormals. Maybe the CPU does not have to do it in software anymore? I don't really know.
musicdsp.org?
> Fixed floating point has been a mistery to me, and to be fair floting point is too. I know digital synths like Virus or Waldorf all used 24 bit fixed point math DSP.
If you imagine scaling a 16-bit value for like a volume control from 0 to 1, then you'd have maybe 32767 for maximum positive, and -32768 for maximum negative. You could convert those to floats, multiply, and convert back to a 16-bit integer.
But you don't want to use floats, you want to keep it all integer. So you make the volume range be from 0 to 255, and multiply your 16-bit value by that. Now you've got a 24-bit value, with a "binary point" between bits 7 and 8. Now the output is way off scale for the 16-bit DAC but if we chop off the fractional part by just shifting the result of the multiply left 8 bits, you've now got your volume control.
Some DSPs will actually do a 16 bit by 16 bit multiply which just discards the lower 16 bits of the result, with the assumption being that both 16-bit values mean "-1 to 1".
A lot of games were shipped with icc, so my guess is they'd work just fine as they were tested with both.
long double x87me(long double a, long double b) {
return a+b;
}
pushq %rbp
movq %rsp, %rbp
fldt 32(%rbp)
fldt 16(%rbp)
faddp %st(1)
popq %rbp
retqInsanity. The values were just right. Just wow.