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.
The time the x86 emulator team found code so bad they fixed it during emulation
11–20 of 179 posts
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#12heh, when Raymond Chen dunks on the MSVC team =)
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#13Couldn't they just turn the optimization off for this loop?
Which optimizer replaces a 64k loop with 64k instructions? Ah, yes. Microsoft's!
There is no indication that the compiler that produced the code was Microsoft's. Actually the article hints otherwise ("[...] whatever compiler was used to compile this code").
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#14To 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.
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#15To 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...
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#16I 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.
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#17I 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.
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#18I 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.
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.
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#19I 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.
A big portion of GPU driver updates are actually just that, same with Windows updates.
Windows 95 patched a bug in SimCity just to get it to work.
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#20This 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 the game was using something like
fread(data, 1, 65536, fptr);
fread(data, 65536, 1, fptr);
The easy fix was to swap arguments for certain calls. The long fix required to use an internal cache to account for these cases so that the hooked ReadFile was faster when data was already in disk.
Funny thing is that as we started rolling out the tech and applying it to more and more games we realized lots of games did this. We went for the cache fix and games ended up loading faster than before. Honestly, games could have load all the data in a couple of seconds by just swapping the args. I'm guessing developers did this on purpose so that games seemed like they were loading a lot of stuff, although you never know.