The return of the turbo button(theregister.com) |
The return of the turbo button(theregister.com) |
This seems like the root problem. Developers, please don't do this. Just let the user run the software, and if it's not fast enough for them, it will be self evident. Don't insert your own personal judgment about what kind of PC is "good enough" and if you absolutely feel you have to butt in like that, don't make the logic faulty like these games apparently do.
When I buy a game, I expect to run it. If my PC is too slow, it will run slowly and I'll be motivated to upgrade or fiddle with the graphics settings. Trying to be this performance police is like saying "Your PC is pathetic. In lieu of letting you run this software you paid for, please accept this picture of my middle finger instead." I wouldn't want to do business with a developer that treats me like that.
Example: Old software that can't handle larger-than-expected disk free space. There are AppCompat shims in Windows for lying to applications re: free disk space quantity because some old applications stored the result of disk free queries in 32-bit integers. Who would ever have more than 4GB of free disk?!?
The integer overflows that result invariably cause unexpected behavior.
Just make the API call to write to the disk. If that returns "disk full" let the user know. Don't "check" first.
idk. Things don't always behave super gracefully if the disk is actually entirely full, this could lead to data loss as other applications can't persist their state as they expect to be able to.
If you're doing something like a system update where you're updating shared libraries, you don't want to get the kernel and glibc yet only half the libraries. You could easily end up in a state where you're not able to rerun the install or even free space without booting up a live USB or something.
I think you underestimate the ingenuity and amount of free time available to PC gamers...
From the article I assumed this was different from the DRM issue, but it links to the exact same Intel KB article.
You can tell the author doesn't use Excel :)
Hi. Author here.
Yes, I do occasionally use Excel (although I favour LibreOffice for most things these days.) TBH, though, this is I think the first time I have ever heard of anyone wanting this behaviour. Usually I heard about people who couldn't understand why they were no longer able to scroll around their spreadsheet in the usual way.
I'm vaguely glad to learn that someone somewhere does want this!
I currently have a compact ("tenkeyless") keyboard which lacks the key, so I tend to use a spring-loaded setup where holding down alt/option/etc. and an arrow key scrolls the window.
https://www.ablebits.com/office-addins-blog/2018/05/23/turn-...
Some people got upset because it doesn't have a turbocharger in it and felt it was wrong to use the word in the name.
Because of turbo buttons on PCs when i was growing up, turbo buttons on 3rd party console controllers, and many other experiences i always associated with just fast, not a specific car part.
(Next we can discuss whether a "Mustang" is a kind of horse, a two-door sports car, a four-door electric crossover, or...)
(Disclaimer: No fact checking was performed on my end).
But I do use it. It's a great key for toggling screen recording, because it's right next to Print Screen and makes logical sense in terms of positioning. It also doesn't do anything useful, or didn't.
Obviously it's not a real problem, but you can't really assume people don't work buttons into their workflow that aren't normally used.
A problem right now is asking how much memory the GPU has. The NVidia driver for Linux will spill data out to main memory if the GPU memory fills up, but you take about a 50% performance hit when this happens. It's better to cut down distant detail and stay in fast GPU memory. But it's hard to find out how much GPU memory is available and how much a spill costs. With "onboard graphics", as in laptops, there may not be any dedicated GPU memory, so this isn't even a meaningful question.
Later models obviously ran faster, but that broke the TV out feature. It seems bad to sell people a newer, more expensive model that loses a popular feature. So, a TV back-compat button was put in so you could still use your TV in cases where you really need to. Technically, you didn't lose the feature when you upgraded.
Also, some games were written with the assumption of a fixed 4.77Mhz clock and would run unplayably fast on newer machines. The back-compat button would slow the machine down so you could still play last-year's games.
But "NTSC Backwards Compatibility Button" is not a sexy name for a feature. So, some genius labeled it the "Turbo Button" even though it actually slowed down the machine.
Once the early machines had it, all the later machines had to have it too. For a long time it simply cut the clock rate in half. Eventually, it did nothing and was abandoned soon after.
On the 386 that didn't work anymore, but there was an external cache. So typically, the turbo button would disable external cache.
Then the 486 came with built-in L1 cache. And it was always way too fast. At that point the turbo button didn't make sense any more. I guess there were software solutions, but I don't recall any name.
(To switch between 4.77 MHz and 8 MHz)
The difference was usually quite noticeable.
I did use it on some older games which just ran too fast on the 286 with Turbo on.
https://www.anandtech.com/show/17047/the-intel-12th-gen-core...
The problem with that was that the processor frequency to high/medium/low-performance class mapping was being done based on Pentium 4 clock speeds, so if you were using an AMD processor (or even one of the first generations of Intel's own Core i-processors if you still happened to be playing those games a few years later) with a lower clock speed but higher IPCs (so a roughly equivalent performance), those games would mistakenly assume your processor was slow and disable various graphics effects and other settings.
Somewhat annoyingly, Maxis/EA never fixed that issue even though AMD processors weren't totally obscure even at that time, either.
The saving grace was that at least things weren't totally hard-coded – there was a rules file in a plain text-based format controlling the various things that should be enabled or disabled based on the detected performance level, and so it was comparatively easy to just change the expected clock speed levels to something more reasonable for a non-Pentium 4 processor.
Later this was also helpful because the GPU detection started having its own issues a few years down the line: When AMD started recycling model numbers for its graphics cards, some newer models were then being mis-identified as some slow, older model that would require various workarounds/lower graphics settings, so again you had to manually edit the rules to fix things.
From memory it was something like UT99 running a loop to determine CPU speed at the start when most modern CPUs are running at a lower clock, and when you start actually playing CPU speeds up and game engine goes crazy.
ah found it https://www.vogons.org/viewtopic.php?p=328803#p328803
"UT uses the RDTSC instruction to measure time. This is an assembler instruction that reads the "Cycle Counter" value from your CPU."
It did that ~10 years ago. On modern CPUs however, that instruction reads a counter which grows at the stock frequency of the CPU (e.g. at 3.6GHz for Ryzen 5 3600), regardless of frequency scaling of any of the cores.
|_| |
| | |
| _
|_ |_|
I had a 5x86/133 that had that pin broken. It worked but unimaginably slowly. Wedging a snapped off pin from another CPU into the socket and trying to keep the whole mess bodged/glued/soldered together made it usable again.