I know nothing of programing but I know one thing for the past 20 years or using computers... old software runs fast on newer hardware. In fact, current software runs fast on new hardware. But I understand what you are saying, but isn't this just stupid to program a game to tax any CPU to the max?
To a certain degree it's stupid, yes. Not all games are programmed this way, but a lot are. The idea is though that there's no "good enough" for a game. With something like Word, it's ok to let the CPU sleep when you're just looking at the page not writing.
With a game the idea is that if you can increase input response by just a milisecond, or produce extra frames you should
This comes down to eSports games typically running at many hundreds of frames per second, because the people who play it aren't satisfied with the tiniest imperceptible delays.
Plus it's an easier way to program the games. Some games allow you to set a framerate limit, meaning that when the game reaches 60FPS or whatever the limiter is set to, it allows GPU and CPU to relax a bit. On Windows you can typically set this through the driver control panel for the GPU too (though it doesn't always work for all games).
On a 60hz screen, you can't see the difference between 60 and 120FPS, but some argue they can feel it in input delay. I can't, hell I barely can between 30 and 60, but that's a different matter entirely.
Those framerate limiters aren't super common in older games, but I used them whenever they're there, because I see 0 benefit above 60FPS, and would rather the system just relax when it produces the frame fast enough. And it does make a huge difference.
[doublepost=1557606220][/doublepost]
Correct, but some games you can sometimes limit frame rates in the settings or by enabling vsync. If your frame rate is far beyond the refresh rate of your monitor, enable vsync to prevent doing extra work that you can’t see.
Depending on implementation, vsync doesn't necessarily prevent extra work. In most implementations of vsync, the CPU/GPU will continue creating frames as fast as they can, but just not send them to the display, discarding the work, but doing it anyway. This is to keep game physics and input delay running smoothly. Especially important for those games in which the physics are tied to the frames - Which is again a less than ideal way to program it, but easier.
