Some additional questions in advance:
- Was the mentioned binary from 2016-03-19 build from the "master" branch?
- Did you do the test with the classic graphics, or with some other (custom) graphics?
- Did you use full-screen or window mode when you encountered the speed problems?
- Which rendering mode did you use with the SDL2 version (see "special rendering) in "setup->graphics"?
Here are some explanations what changed in 188.8.131.52 that caused the slowdown in graphics performance you encountered.
One of the last additions to version 4 (developed in separate branch "global-anims" during the last few months, and therefore most probably not in the code base of your 2016-03-19 binary, at least not if you used the "master" branch) was a very generic extension of the classic "toon animations", making it possible to add various animations (both fixed and moving) to individual screens in R'n'D. (This is a feature requested by Juergen Bonhagen for his next fully customized version of R'n'D.)
Due to the quite generic nature of these new animations, the previous hack for displaying toons as used in pre-4 versions (that was very nasty, but also very fast) could not be used anymore (which added the toon to the backbuffer after backing up the screen area under it, draws the backbuffer to the visible screen and then restores the screen area again). Instead, the backbuffer is now copied to a second bitmap, all animations are added and then the second bitmap gets drawn to the visible screen. Although copying a single (even though possibly large) bitmap should be very fast on most systems, it adds graphical overhead nevertheless, that may result in a noticeable impact in graphics speed on older and/or slower systems (including my own desktop system, which has no dedicated graphics adapter, but only onboard graphics).
On the other hand, the SDL2 version makes (some) use of textures that are stored on the GPU instead of bitmaps worked on by the CPU (not for the whole game, but only for the final step where the animations are added). So most of the additional graphical work that has to be done is compensated by utilizing the GPU, which is usually quite powerful on modern systems. As a result, it apparently works just fine on average phones and tablets, which apparently have enough horse power to play it just fine. (On my own desktop system, that I assembled around 2011 with a AMD quad-core CPU, I already had quite some speed decrease when running in full-screen mode with version 3, so I did not expect any magic with version 4, even with additional GPU use.)
To be able to use a rendering mode that fits best the individual performance characteristics of the target system (read: speed of CPU and GPU), 184.108.40.206 RC1 has the following four rendering modes (in the graphics setup):
- "off", which streams directly to a texture and adds the animations there (possibly causing rendering artifacts),
- "bitmap/texture", which does everything in software before pushing the final buffer to the screen (also used by the SDL 1.2 version),
- "target texture", which is some sort of "illegal" technique (fastest on my system, broken on Windows, removed for final version 4),
- "double texture", which uses two textures to get rid of possible rendering artifacts.
The first mode should usually be the fastest with some decent GPU power, the fourth should still be just fine on such systems, and the second one should be the slowest on average systems (as it makes more use of the CPU than the other two variants). The third mode is only for testing purpose, may completely refuse to work (for example, it vertically flips the screen on my Windows 7 VM
), should theoretically be slow, but interestingly seems to be the fastest mode on my system when using a certain test level set with Full HD resolution and a number of animations playing. Nevertheless, this third mode will be removed (or deactivated, or hidden) in the final version 4.
What else can be done about it?
I most probably will add some additional changes to the rendering code to skip parts of the rendering "complications" when global animations are switched off in the graphics setup (this was previously "toons: on/off"). This should give a little speed-up during game play on slower systems, and hopefully makes things more playable again on such systems.