Live data from Hacker News

A time-travelling door bug in Half Life 2

mastodon.gamedev.place

61–70 of 88 posts

Re: A time-travelling door bug in Half Life 2

#61

Earlier quoted context omitted.

There was at least one reason... 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 retq

what is this?

Looks like a demonstration that using `long double` math requires dipping into x87 instructions, specifically the `fldt` instruction: "floating point load ten bytes".

Re: A time-travelling door bug in Half Life 2

#62
post #46

Earlier quoted context omitted.

It's probably because you have to have weird precision issues where the numbers are calculated ever so slightly differently, and some other effect like a guard being slightly too close and getting clipped by a door where that difference matters. 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…

Is funny because the only code I have read that flushed denormals was in synth code.

Denormals in audio code are kind of the "perfect storm", because they take ages to deal with - you're suddenly back into softfloat land - and because you have to deal with many thousands of them in a few hundred microseconds.

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 ;-)

Re: A time-travelling door bug in Half Life 2

#63
post #42

Earlier quoted context omitted.

Impulse is change in momentum: https://en.wikipedia.org/wiki/Impulse_(physics)

Right, I was just wondering if the developers repurposed the term impulse from the physics engine when creating console commands. "impulse 101" is a common cheat to give all weapons with ammo, but why not "give" or "player.addItem" or something? Just a curiosity.

As for the name "impulse", I don't know - but the way this command works reminds me of interrupts.

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.

Re: A time-travelling door bug in Half Life 2

#66

Is there an alternative place to read this, for those of us with strict work network rules that consider mastodon as social media?

Chuck in a !wayback before the url, it gets you here: https://web.archive.org/web/20251124090635/https://mastodon....

edit: wayback machine doesn't work, though !ais does:

https://archive.is/ng0ke

Re: A time-travelling door bug in Half Life 2

#67
post #37

Earlier quoted context omitted.

The game has ammo pickups that refill 20% and 50% of whatever your max ammo is, so floats have to be involved in there somewhere.

Dividing by 5 or 2, respectively, are integers, if the game developers wanted them to be. More so because the actual units of ammo need to be integers if they are to render as full bullets each

Or more generalized "ammo += (maxAmmo * percentageToFill) / 100"

Re: A time-travelling door bug in Half Life 2

#68
I used to work at the studio responsible for the Driver games, and few years back we dug out the code for the original PC Driver and tried to compile it again, mostly for fun - we had to change a lot of hand written assembly code to make it build, and discovered that yeah, the game worked but none of the game replays worked - and it was for that exact same reason, better/different floating point precision issues. Really fun thing to investigate though.

Re: A time-travelling door bug in Half Life 2

#69

Earlier quoted context omitted.

HL3 exclusively in VR is likely the only thing that’d get me to increase my “time spent in VR” from the current about-ten-minutes to about six hours.

Interesting that Half-Life: Alyx exclusively in VR wasn't enough, then. I love VR and that game is the best VR experience I've had.

It's kinda sad, with all the time an money spent on VR, HL:Alyx remains the only truly great VR game.
Post reply on HN