Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A time-travelling door bug in Half Life 2

mastodon.gamedev.place

Post reply on HN
Print view View original

81–88 of 88 posts

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

#81

Post by Ericson2314 »

throwaway314155 wrote: post #32
Ericson2314 wrote: post #19

It's a goal of mine to get Valve using Nix. (I hope our in-progress Windows support would make this especially compelling.) 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 h…

> It's a goal of mine to get Valve using Nix They’re using Arch Linux. Let’s call it a win and move on lol.

Using completely different packaging infrastructure for the different platforms you support is no good!

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

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

#82

Post by ErroneousBosh »

lomase wrote: post #72
ErroneousBosh wrote: post #62

Earlier quoted context omitted.

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…

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. 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.

> I remember this dps site with lost of c and delphi code, there is where I found what denormals are.

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".

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

#83

Post by brokenmachine »

Nothing to do with the actual story which was very interesting, but I just find it so absurd that in 2025 we're still splitting posts into paragraphs because of some weird historical character limit on tweets.

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?

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

#84

Post by 01HNNWZ0MV43FF »

brokenmachine wrote: post #83

Nothing to do with the actual story which was very interesting, but I just find it so absurd that in 2025 we're still splitting posts into paragraphs because of some weird historical character limit on tweets. 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?

Worse is better, it's easier to write inline on your Fediverse account than to write a blog post somewhere else and syndicate it

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

#85

Post by 01HNNWZ0MV43FF »

matheusmoreira wrote: post #59
accrual wrote: post #33

Earlier quoted context omitted.

Just did some quick testing - the doors definitely have physics and can get stuck on objects and can impart forces. But unimpeded yes, they smoothly open/close. 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.

> ejected the tire at high speed I wonder if speed runners have found ways to abuse this...

You might find this funny

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

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

#86

Post by akimbostrawman »

RobKohr wrote: post #77
account42 wrote: post #74

Earlier quoted context omitted.

It did work with the Index at some point. Valve have been neglecting VR though (especially on Linux) so I wouldn't bet on it still working.

Considering the upcoming release of Frame, a VR headset based on Linux, I feel this couldn't be a more untrue statement. 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.

Both can be true considering they are very different projects and hardware. SteamVR on linux even with a steam index has many issues. I am sure however that the linux support of the frame will be much better considering it also releases alongside there own Linux PC.

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

#87

Post by DarmokJalad1701 »

I have encountered at least one bug at $job which was tracked down to x87 instructions. Our "production" build is deployed on embedded ARM CPUs while we have test builds compiled for x86 (32-bit) and x86_64 (different subsets of functionality). Anyway, the bug only showed up in the 32-bit x86 build. The same code worked fine in production and in the 64-bit test builds.

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.

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

#88

Post by matheusmoreira »

01HNNWZ0MV43FF wrote: post #85
matheusmoreira wrote: post #59

Earlier quoted context omitted.

> ejected the tire at high speed I wonder if speed runners have found ways to abuse this...

You might find this funny 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

That's amazing!
Post reply on HN