Although that's a good point... I don't see it being useful 99% of the time for sound as PC-Speaker is probably emulated in DosBox.

As for resolutions and supported ratios, yeah that could be useful. Although most of the time it will be 4:3 unless the game came out in the last 6 years.

Some are able to be tweaked relatively easily, for others that is... definitely not the case. Which can be disappointing on a widescreen monitor.

I've never seen an actual monitor that couldn't handle it, 99% of the time it's laptop monitors that have stretching vs scaling issues.

But if it's a windows game that can be a problem, with DosBox if I understand it right there's an option to force scaling, meaning it will increase the resolution and then emulate widescreen just by putting black on the two ends, thus taking that problem away. other games however... Not so easy...

I'm reminded of Nox, which runs it's menu fixed at 640x480, but you can upscale it to quite a few resolutions, although above 800x600 I couldn't see enough of things so I didn't bother going higher.

But enough on that. Perhaps a thread would be better off than a mix, or specific mixes where workarounds aren't possible. Hmmm...

I think that 60fps should be a standard. I can't speak for the behavior of the FPS police on Steam per say, but I can say that I for one do get disappointed in an FPS lock in much the same way when there's a resolution lock. Games need to be future proof for this sort of thing. Higher frame rates will always translate to tighter controls.

Sure, let's drag those assholes in here too, why not. Let's turn GOG into the freakshow that is Steam.

Standards change over time. GOGs library still heavily skews towards older titles.

Colossal twats generally: "omfg i dropped to 40 fps with the graphics settings cranked up to max!!!!111"

A lot of games use frames in the physics, triggers, scripts, speed, calculations, and animations. It's not so simple to uncap it.
Freakshow? You're being kind.

Which is simply bad game design.

It isn't for AAA companies who tend to make their games big and spectacular and it isn't for indies who can't get it to work on their budget; and it shouldn't be for any game that isn't an explicit 3D high speed experience. You can push your arbitrary standards on AAA companies, which is what the Steam group attempts with their evidently uncontrollable outrage machinery, but all you will achieve is that people are hunting down indie developers like Gambrinous for no reason at all.

A game locked at 30 frames per second may be a case file, but in no way is it a bullet point on a stupid ostracism list. Which it_would_be_here_as_well.

https://twitter.com/the_moviebob/status/622530222915747841

Stop the anti-developer outrage folks. Stop that absurd entitlement. The industry is fucked up enough as it is.

As far as I know the alternative is a lot more complex.

Not that much more complex. You just have to keep game logic and display handling in different parts of the code and ensure the communication between the two works. It's a much cleaner and safer approach.

Calculating delta time and what not is not nearly as straight-forward as just locking everything to a certain framerate.
I'll agree to that, but it's not as though all designers are experts or even technically competent.

no, it is a bad code design, the game can be great nonetheless.

Thanks, Nirth. Might give that a try this week.

Not to mention more expensive instruction-wise.

Having worked with the lowest level instructions, on x86 hardware the basic instructions (add, subtract, xor, etc) are probably 2-5 cycles, while multiply is about 40 and divide can be a whopping 160! That was for 32bit instructions, 64bit could be slower.

Since most detla frames are also going to be in floating point, you are heavily going to be relying on multiplication of that value. Multiplying everything against the delta vs just adding a fixed number can be quite the strain when there's hundreds of thousands or millions of calculations done for that.

Fixed framerates sound better in my mind, but they have to be high enough that it's not an issue. Say pushing for 120 frames, with a second piece of code compiled for 60, then you get the advantage of pure raw speed in the instructions and code while also getting high framerate results.

But that's not how most 3D games are written. One second you could have 60, dip to 55, or go just over 60... sounds like a mess.