Dynamic In-Game Resolution Plans (Patreon)

A good amount of people plays Retroquad at lower resolutions. My computer has a 3.60GHz CPU, but CPUs with much lower speeds are very common.

Until yesterday I thought of modifying the interlaced rendering code to implement a non-flickering half-resolution mode, but that would break the vertical per-pixel dithering of many visual elements.

To preserve the dithering, the interlaced rendering must either flicker or ghost the image. It's possible to modify the multiple instances of dithering across the whole engine to adapt the dithering to a half-resolution interlaced mode, but that seems to be an overcomplicated solution.

So, I thought about the viewsize cvar, which reduces the in-game resolution independently of the actual video resolution, making it faster to render. In doing so, the in-game view is rendered to a smaller portion of the screen. It should be possible to upscale the reduced in-game view up to fill the whole screen during the postprocessing stage (which performs fog, screen warping, or simply copies the rendering buffer as is), done before rendering the 2D elements (HUD, GUI, etc).

Many modern games have a dynamic resolution mode, which does something similar according to the framerate. So, it's possible to implement the same thing in Retroquad, making the game dynamically reduce the ingame resolution when the framerate is too low, and gradually increase the ingame resolution back to 100% when the framerate is high enough. Some dithering may be optionally applied on this upscale to smooth it out, and the lower ingame resolution still works with the interlaced rendering, so by combining both features a big increase in the framerate should be possible.

Right now the postprocessing needs some fixes at reduced viewsize values (fog is glitchy), and I'll test the whole renderer at reduced viewsizes to see if there's any other compatibility issue to fix. Afterwards, it's just a matter of implementing upscaling versions of all postprocessing modes, and implementing a function to select & configure them according to the framerate.

lnterlaced rendering still needs a method to dynamically switch between its different modes. Framerate alone isn't good for this, because it's more a matter of how different each frame is instead of how fast it was rendered.

First, I'll compute how much the view angles changed between frames, which is quite straightforward. Since the default FOV has a 90 degree angle, any angular difference beyond that should be considered as the maximum angular speed between frames. Differences in angular speed will be used to select the interlacing mode between full ghosting (at 0% angular speed) and full flickering (at 100% angular speed). The progression between 0% and 100% will likely need some curve algorithm to balance the interlacing modes better.

Computing how much the view position changed between frames will very likely be needed too, but that's more complicated. The more orthogonal to the angles the positional movement is, the more we should avoid ghosting. And even when the movement is exactly in the same axis as the angles (straight forward/backward), we should completely avoid ghosting when it's too high. But of course, the lower the speed is, the more we should favor ghosting and avoid flickering. Determining good speed values for this isn't easy, because the issues with ghosting are also largely dependent on how far away the scenery and objects are.

Anyway, time to work. Getting all this to work will be enough to bump the version number to 0.18.0.