111–120 of 179 posts
Earlier quoted context omitted.
This is a horrible and yet not unexpected insight into the internals of Excel
> To be fair excel would erase places white that it wanted to write up to 9 times before it drew any black pixels I feel like I'm having a stroke trying to read this, what does it mean??
heh, when Raymond Chen dunks on the MSVC team =)
Earlier quoted context omitted.
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…
I remember when 24 bit color was exotic and aspirational and you had to settle for 16.
Earlier quoted context omitted.
They were most likely just bugs. Quite possibly really stupid bugs. Not every bug results in the program doing the wrong thing, they often just make the program do the right thing very slowly. And nobody notices, since it still produces the right result.
Yes, they were bugs, I think programmers (and their marketing people) were more focused on new features than performance
Now the bugs that get ignored for new features cause bad results AND bad performance.
Earlier quoted context omitted.
I remember when 24 bit color was exotic and aspirational and you had to settle for 16.
16 bits? Luxury. I had 6 colors when I was a kid and was happy to have them.
Back then you did what you could with graphics and it wasn't a lot. After I got a PC I had indexed color for a long time and working with indexed color was pretty rough because anything physics-based like rendering or raytracing was going to be difficult. You could render a photo pretty well with 256 carefully chosen colors and dithering but if you wanted to, say, composite two photos and do general sorts of things you'd need to convert to "true color", do the math there, then re-quantize for display.
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…
Part of Windows Explorer actually does tons of tiny 4 byte ReadFile calls in to its tracking database like file when you delete a file. If you deleting lots of files this quickly adds up.
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.
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. Un…
> 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.
I can't quite parse this. Yes, there is no guarantee that the optimizations will work for another game, which is precisely why you can expect an improvement with hl2. With non-hl2, you may get an improvement, you may not, and you may get incorrect behavior.
Everything else is not the same, but hl2 doesn't use the stuff that's different.