Live data from Hacker News

The time the x86 emulator team found code so bad they fixed it during emulation

devblogs.microsoft.com

31–40 of 179 posts

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#31

I think we're starting to see more of this sort of thing happening now with Proton and Wine gaining prominence in the Linux community. Some games (Elden Ring comes to mind) have bad enough PC ports when they come out that the compatibility layer can incorporate a hotfix to improve performance, while users of the software on the original platform still had to suffer.

GPU driver packages are already a huge collection of workarounds for bad game engine coding. An Nvidia employee once told me that one of the easiest ways to squeeze out a few extra frames on your old machine is to rename the game executable to hl2.exe.

I can see how it can modify GPU driver behavior, but I cannot see how it would get you better performance with everything else the same?

What it should do is ensure some things not relevant to Half-Life 2 were not done, thus getting better performance for this game in particular, but there is no guarantee that same optimizations work for other applications or games, so one should not expect an overall improvement.

Unless they are doing some silly things like dropping quality, but that's the "everything else the same" point.

If not, why not have this enabled as default behavior instead?

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#32

Earlier quoted context omitted.

> to rename the game executable to hl2.exe This seems genuinely unbelievable. Does anyone have a technical explanation for this?

gpu drivers detect games, among other thing by looking at executable names then driver "optimizes" behavior, sometimes dishonestly (reducing precision), sometimes honestly (working around game engine stupidity)

Couldn't that also cause glitches since optimizations meant for HL2 might not work for, say San Andreas? I understand some optimizations might be universal but I can't help but think about unexpected behavior.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#33
post #21

Earlier quoted context omitted.

Because everyone reported performance metrics using it as a benchmark. Higher number = more sales.

If you go back 5 years, everyone was using Quake 3 Arena as the benchmark. ATI got in some hot water because if you renamed quake3.exe to quack3.exe, your FPS would drop by 15%, because they were silently reducing quality to juice their benchmark numbers.

5 or 50? I'd say 5 years ago it was already Witcher 3, Cyberpunk 2077, GTA 5, etc.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#34

Earlier quoted context omitted.

gpu drivers detect games, among other thing by looking at executable names then driver "optimizes" behavior, sometimes dishonestly (reducing precision), sometimes honestly (working around game engine stupidity)

Couldn't that also cause glitches since optimizations meant for HL2 might not work for, say San Andreas? I understand some optimizations might be universal but I can't help but think about unexpected behavior.

Who's problem is this?

Nvidia probably doesnt officially say anything about this and 99.9% of people do not rename process name

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#36
post #21

Earlier quoted context omitted.

Because everyone reported performance metrics using it as a benchmark. Higher number = more sales.

If you go back 5 years, everyone was using Quake 3 Arena as the benchmark. ATI got in some hot water because if you renamed quake3.exe to quack3.exe, your FPS would drop by 15%, because they were silently reducing quality to juice their benchmark numbers.

Apparently people did this with the DirectX "3D Tunnel" demo as well[1] back over 20 years ago.

Also there was one "that checked if you were printing a specific string used by a popular benchmark program. If so, then it only drew the string a quarter of the time and merely returned without doing anything the other three quarters of the time".

[1]: https://devblogs.microsoft.com/oldnewthing/20040305-00/?p=40...

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#37
post #15
post #14

To be fair it is possible that the developer enabled a special "unroll all loops, no matter what" optimisation flag during compilation. I agree it would be stupid for a compiler to even support such a flag, but those were the 1980s/90s.

Ahh... Good old funrollloops... https://www.shlomifish.org/humour/by-others/funroll-loops/Ge...

Right up there with fun, safe math optimizations

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#38

Earlier quoted context omitted.

gpu drivers detect games, among other thing by looking at executable names then driver "optimizes" behavior, sometimes dishonestly (reducing precision), sometimes honestly (working around game engine stupidity)

Couldn't that also cause glitches since optimizations meant for HL2 might not work for, say San Andreas? I understand some optimizations might be universal but I can't help but think about unexpected behavior.

Yes.

A lot of people use Nvidia profile inspector to enable reBar on all games and claim that Nvidia is purposely holding back performance, but doing this causes many games to crash.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#39
post #27

Earlier quoted context omitted.

Fairly sure GPU drivers do the same thing where they include a ton of per game tweaks to make them run faster. It does feel like a fragile way of doing things where an external component that should be agnostic to the software running ends up including a handful of junk trying to fix stuff that should have been fixed by the consumer of the driver.

It goes the other way too, sometimes you trigger some optimization silliness in the driver and the game needs to adapt to avoid it.

then the driver gets updated and the game either continues to optimize (wrong) or branches out into code that was written before that driver came out and generally wasn't that well tested, and the circle continues...

It's the life of a (game) developer...

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#40

SimCity had a read-after-free bug that Microsoft patched in Windows 95. That was a lot easier for customers than having Maxis fix it, which could have required exchanging copies of the game.

It feels like graphics drivers do / did this a lot too. At the very least they make specific optimizations for specific games, probably by tweaking settings and features that the game developers didn't optimize properly themselves.
Post reply on HN