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.

> Which basically expanded back in the day to 65k reads of 1 byte for several MB file. Each fread translated to 65k reads of ReadFile Windows API

What software did that that badly? If the code asks for (up to) 65,536 single byte items, why would you split that into 65,536 calls?

Also, that change changes behavior. The old call could read anything from zero to 65,536 bytes, the new one only can read zero or 65,536 bytes.

(Reading the source of a few implementations, I think most implementations will fill the output buffer with partial objects if the input doesn’t supply an integral number of them, but the return value of fread cannot signal that to the caller)

Doesn't that break anything relying on the return value? fread gives you the number of objects read as a return. So I think a pretty typical thing would be to fread and then parse that number of characters, and that'd just break?

"I'm guessing developers did this on purpose so that games seemed like they were loading a lot of stuff"

I really hope that was not the case and rather think incompetence or to deal with obscure legacy problems, but the gamer in me gets enraged at the thought someone would artificially increase loading times.

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.

The most interesting part is that IIRC they shipped the entire Windows 3.11 memory allocator to make it work.

I have very little understanding on how allocation works at OS level, but I'm surprised there are no wrappers like dgVoodoo or dxWrapper specifically for this kind of issues. There are quite a bunch of old Windows games (Need for Speed 1-4 for a start) that refuse to run on modern OSes due to rather...bold memory management strategies.

Ahh... Good old funrollloops...

https://www.shlomifish.org/humour/by-others/funroll-loops/Ge...

speaking of which, what became of it?

They didn't have the code for the offensive program, they were creating the emulator to run it on a different architecture.

Which optimizer replaces a 64k loop with 64k instructions?

Ah, yes. Microsoft's!

The big one I remember was many applications, not just games assuming the buffer swap was performed by a blit into the display buffer, not an framebuffer pointer update. They relied on the previous frames data still being in the back buffer. For those applications you were forced to blit the buffer, not swap the pointer and take a performance hit.

I also remember a media player being called out by name in the code for doing invalid operations, needing a work around and code to detect it was running just to function.

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

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

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?

> to rename the game executable to hl2.exe

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

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.