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

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

devblogs.microsoft.com

Post reply on HN
Print view View original

21–30 of 179 posts

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

#21

Post by db48x »

proton_9 wrote: post #18
anilakar wrote: post #17

Earlier quoted context omitted.

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.

This sounds like a really interesting story, would like to read more on why half life 2 specifically? the game itself was pretty well optimized and ran on really low end hardware even back in the day.

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

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

#22

Post by kazinator »

> Anyway, my colleague found that there was one program that needed to allocate around 64KB of memory on the stack and initialize it. The standard way of doing this is to perform a stack probe to ensure that 64KB of memory is available, then subtracting 65536 from the stack pointer, and then initializing the memory in a small, tight loop.

Actually, the standard way of allocating 64 kB of memory on the stack is to just assume you can do it, subtract 64k from the stack pointer, and hope for the best.

Most stack allocations in the wild are not checked.

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

#23

Post by murderfs »

db48x wrote: post #21
proton_9 wrote: post #18

Earlier quoted context omitted.

This sounds like a really interesting story, would like to read more on why half life 2 specifically? the game itself was pretty well optimized and ran on really low end hardware even back in the day.

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.

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

#24

Post by limflick »

anilakar wrote: post #17
hodgehog11 wrote: post #2

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.

> to rename the game executable to hl2.exe

This seems genuinely unbelievable. Does anyone have a technical explanation for this?

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

#25

Post by hurtigioll »

limflick wrote: post #24
anilakar wrote: post #17

Earlier quoted context omitted.

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.

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

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

#26

Post by Taniwha »

psanchez wrote: post #20

This reminds me of a story from 15 years ago, where I was developing a technology to download games on demand by hooking into the OS calls. There was a particular game that was superslow when this tech was applied. Original game loading took around 15-20 seconds, whereas once the tech was applied it took easily 3-5 min, even with all data already downloaded. When I started digging into it, I realized the reason was t…

I used to be a graphics card/chip architect for macs in the early/mid 90s - our chips were the fastest, but some programs were resistant because they did stupid stuff: pagemaker invalidated the font cache every time it went thru its main loop, quark with ATM did an n*2 thing every time it wrote text etc etc. We had special hardware to accelerate text drawing and it did nothing because the software pissed it away. We considered creating a plugin that fixed all these things, it would have been hard to maintain, in the end we travelled around to the people who made these apps and talked them through their problems

To be fair excel would erase places white that it wanted to write up to 9 times before it drew any black pixels, we made that very fast! we didn't tell them :-)

At the time 24-bit framebuffers were so slow that before we built graphics acceleration hardware people would switch back to 8-bit to get stuff done, making 24-bit/true colour your daily driver was a big step forward.

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

#27

Post by Guvante »

Gigachad wrote: post #16
hodgehog11 wrote: post #2

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.

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.

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

#30

Post by st_goliath »

anilakar wrote: post #17
hodgehog11 wrote: post #2

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.

> GPU driver packages are already a huge collection of workarounds for bad game engine coding.

And of course, browser engines also do the same things for certain websites:

https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...

https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...

Post reply on HN