Decouple drawing and rendering

[alexbatalov]

This PR decouples render calls from drawing calls and adds FPS throttling, thus greatly enhancing frame rate and overall performance.

The addition of renderPresent allowed to get insight into number of render calls (renders-per-second, RPS) which appeared to be 5 times larger than FPS. That’s unsurprising given the fact that event loops in the legacy code are not update-render cycles, instead they are render-whenever-I-want cycles. It was not a problem when it was fullscreen DirectDraw with direct screen frame buffer access. Original game didn’t even use double buffering, every blit was immediately reflected on the screen. However in SDL 2 this approach performs many expensive copies from main to video memory, causing significant frame-rate drops on large resolutions. Instead of rendering immediately on every blit, this PR delays rendering until the end of the event loop cycle thus employing (some sort of) update-render approach.

Here are my numbers. Testing was conducted in San Francisco since it’s one of the most crowded maps with unconstrained main event loop (FpsLimiter turned off), windowed (which is slightly slower than fullscreen), debug mode (I know, this fact alone ruins entire benchmark).

	800x600	1280x720	1920x1080	2560x1440
FPS	262	118	27	7
RPS	1442	714	274	139
New FPS	1122	657	235	93

With FpsLimiter you are still capped at around 60 FPS, but the performance is totally different if you have big screen.

Despite the relatively small amount of changes to the code, this is a significant change which might cause some disruptions to gameplay. There are many cases where fps throttling works together with legacy frame throttling, so frame rate can be sluggish on certain screens. Some blocking animations might be skipped as well. Some windows might totally freeze. These will be eventually fixed.