Open AdamsLair opened 9 years ago
I have a suggestion for this one.
If VSync isn't the real VSync (caps the framerate to the screen's refresh rate), turn it to real VSync.
Now, about capping framerate: there could be an option in the Settings menu called FramerateLimit, with a bunch of values: 30, 60, 120, 180, Unlimited.
If VSync isn't the real VSync (caps the framerate to the screen's refresh rate), turn it to real VSync.
It was VSync'ed in the beginning, but I turned it off pretty soon, because it just didn't look good. The thing about the editor is that unlike a real game, it doesn't have a fixed framerate and nothing else going on - it needs to dynamically redraw the scene based on user interaction. While I agree that VSync in general is great, it just wasn't a good fit for this specific situation.
Now, about capping framerate: there could be an option in the Settings menu called FramerateLimit, with a bunch of values: 30, 60, 120, 180, Unlimited.
Sounds good to me. I'd probably not have it in the game settings, but somewhere in the editor settings though.
I know this is old but if it's still open I'd like to help. I propose not stressing about VSync and instead just capping the frame-rate to an option that can be defined in the editor. Also, instead of a bunch of pre-defined values, wouldn't it be better if the user could just type in a frame-rate?
Is there a class within Duality that handles game time? If so, can it be used?
It should be possible to do this change entirely in editor code, briefly looked up the spot and as far as I recall this is the overall area where editor updates happen. There already seems to be some rough frame time limiting code here, based on which I'd say the editor is currently capped at around 100 FPS.
Since this issue is pretty old and it seems like the code has already changed a bit since then, I think the first step should be to verify actual editor behavior in a test scene with a diagnostic ProfileRenderer
and sandbox mode.
Now, about capping framerate: there could be an option in the Settings menu called FramerateLimit, with a bunch of values: 30, 60, 120, 180, Unlimited.
Sounds good to me. I'd probably not have it in the game settings, but somewhere in the editor settings though.
Late grain of salt: As the game always targets 60 FPS, it might make sense to not expose this through editor UI to avoid confusion. Could still be added later, if there's a game-specific framerate setting at some point.
While I do think a cap is good Iam running a 144hz monitor so just capping it to some value doesn't sound right.
Not sure if this can be done in a more smart way? Figure out the refresh and limit it to that? Though that sounds like something with loads of edges cases. Might be easier to offer some values the user can select or lets the user fill in a value.
You're right that limiting to some value is not ideal, and there might be a better way, but I think that we're not at that level of rendering / update emulation anyway in the editor sandbox and this might not be something easily fixed by choosing the right refresh time, or letting the user do it. On the plus side, it doesn't seem to be that bad either, since the topic didn't come up so far - and I personally never noticed side effect from this either during gamedev.
The proper way to handle this would probably be VSync, but as far as I remember, we do not have VSync active in the CamView to avoid UI lag (to be checked, might be wrong!). I'm not sure it makes a huge difference whether or not we imitate monitor refresh rate in that case. Also, the way editor updates currently take place is not stable, as updates and render frames can be deferred at any point due to UI events being processed.
Let's first check whether there's the need to do something about the emulated refresh rate, as this is a small and probably low friction change. To achieve better parity with how the actual game renders in sandbox mode while still retaining UI responsiveness, we might need to do a bit more, and that sounds like it could a bigger issue, probably better dealt with separately.
Before approaching either of those, we first need a good examination of the status quo, to see if there is actually a practical problem right now.