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

51–60 of 88 posts

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

#51

Post by zenethian »

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…

Nix seems like a cool tool but nix users are becoming increasingly irritating.

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

#53

Post by Shekelphile »

Wowfunhappy wrote: post #6

Wait, so is that "beta" of Half Life 2 VR a thing I can play? If it is, how did I not know about this, and if not... why not? 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...

It was publicly released in 2013 and you can enable it with -vr in args IIRC. Not sure if it would work with modern VR hardware since steamvr wasn't a thing back then.

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

#54

Post by Agentlien »

phantasmish wrote: post #47
accrual wrote: post #29

Earlier quoted context omitted.

Fantastic! If HL3 releases on VR, maybe I'll do HL2 in VR (refresher), then Alyx, then HL3. :)

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.

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

#56

Post by adastra22 »

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…

Maybe I'm not seeing it. How would the bug finding be easier here? Seems like the same setup. They could compile with recent tools, and they already had the compiled version with old tools (hosted on Steam).

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

#57

Post by torginus »

nasretdinov wrote: post #10

I wonder how on earth stuff like x86->ARM translation works so well if games break even after switching from x87 registers to SSE preserving all the logic otherwise...

I remember there was a huge scandal where Intel's compiler, icc (considered to be the fastest for quite a while back when) defaulted to x87 when it detected an AMD CPU instead of SSE, giving AMD cpu's a handicap (incidentally, that's the reason why x87 used to be much faster on AMD for a while).

A lot of games were shipped with icc, so my guess is they'd work just fine as they were tested with both.

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

#58

Post by adastra22 »

ksherlock wrote: post #34
pdw wrote: post #27

Earlier quoted context omitted.

Rosetta uses software emulation for x87 floating point. That's slow, but in practice that doesn't matter much. Mac software never had a reason to use x87 FP, every Intel Mac had at least SSE3 support.

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?

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

#59

Post by matheusmoreira »

accrual wrote: post #33
why_at wrote: post #22

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

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

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

#60

Post by wowczarek »

WatchDog wrote: post #49
accrual wrote: post #30

> The door and the guard are both physical objects, both have momentum, they impart an impulse on each other 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. https://developer.valvesoftware.com/wiki/Impulse

The impulse console command originates from Quake, the Half-Life 1 engine (GoldSrc[0]), was based on the Quake engine, and the Half-Life 2 engine (Source), was based on GoldSrc. 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/0023…

Noclip FTW
Post reply on HN