Comparing today's binary to one I have from 2016-03-19: today's is slower in play, and when side-scrolling the playfield it is both slower and noticeably flickery. Both SDL1 and SDL2 binaries are affected.

On Ubuntu 12.04 on old laptop with 2.1GHz Intel i3-2310M CPU and just the wimpy on-CPU graphics controller.

- 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 4.0.0.0 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), 4.0.0.0 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.

> - Was the mentioned binary from 2016-03-19 build from the "master" branch?

Yes; with my debug-keys patch, which I am certain does not magically speed up the graphics :)

> - Did you do the test with the classic graphics, or with some other (custom) graphics?

Um. No custom graphics of mine; possibly of the level. The level I am looking at right now is "/usr/share/games/rocksndiamonds/levels/Emerald Mine Club/emc_cosmos_mine_10/15".

> - Did you use full-screen or window mode when you encountered the speed problems?

Window, when reported. Just now I did (1) double-click on window titlebar, which brought it to full-screen-window (title bar now showed "129%"); performance was the same. Then (2) Alt-Enter (now full-screen with no window decorations, no visible titlebar to announce a percent-size); still same performance. These two tests done in "Special rendering: off" mode.

> - Which rendering mode did you use with the SDL2 version (see "special rendering) in "setup->graphics"?

Had never been to that setting before. Upon entry it was set to "Double texture mode (slower)".

> - "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.

I tried each one of these and performance was identically slow. (Note: did not check for side-scroll flickering; the test level I was on at this moment doesn't do a lot of linear side-scrolling that makes this obvious.)

For yesterday's build, trying each of the 4 rendering modes, the answer was "00:10" (once "00:09", but I assume that's due to my manual control of '551' and ESC).

For 2016-03-19 build, the answer was "02:31", i.e. 151s of game time in 10s realtime, 15:1 speedup.

Additional notes:

I just noticed the Antialiasing setting. It was set to (default I think?) "Linear". Changing to either "None" or "Anisotropic" made no difference.

I've been playing for months, ever since you put it in and it worked, in "Small game graphics: ON" mode. Turning this off -- returning to twice-as-large cels, half-by-half-as-big view into the play area, made no difference. Neither Antialiasing nor Large (not-Small) cel rendering made it fast. I didn't do actual clock checks on these modes but the play was obviously about the same 1:1 speed.

I really don't think the game is struggling to keep up 1:1 game:real time, especially not identically in 4 different rendering modes. I think the "replay as fast as possible" mode broke in a game-logic manner.

Or perhaps that mode was never intended to exist? In that case, let me plead with you to make it intentional!

I generally do:

(1) Play level N, repeating until I "win".
(2) Game has now moved me to level N+1.
(3) Go back a level, hit '551' to watch level N replay in fast-motion.
(4) Usually, go forward to level N+1 and work on solving it.
(5) Sometimes, decide I don't like the sloppy / inelegant way I've solved level N; start a new run to do it better.

If (3) didn't work -- if I could only watch level replays in realtime -- I would have to give up this methodology and just settle for whatever sloppy solution I recorded the first time.

Quick comment (before going into details): Although version 4.0.0.0 indeed added some overhead to screen redraw (which I thought was what you described here), what you are now talking about is in fact the bug you reported in your other thread "'Fast as possible' not working". But this has nothing to do with "slower" graphics or screen redraw due to additional graphical operations (like changed the handling of masked screen borders or toon animations), but ... is simply a programming bug. (Please refer to that other thread for further comments on that topic.)

As there is indeed some graphics performance degradation, I will keep this thread for discussing just that.

Yeah, I had initially mischaracterized it because even regular speed gameplay felt a bit slower. Now I'm no longer certain about that (would have to carefully scrutinize side by side play). The flickery thing was certainly there at first, though not last time I tried -- and I haven't played at all since last night's long post that this is grand-reply to. I'm keeping an eye out, I'm sure the flickery problem will eventually reproduce again and I'll report details.

[...] because even regular speed gameplay felt a bit slower. Now I'm no longer certain about that (would have to carefully scrutinize side by side play).

If you played for 10 seconds according to your desktop clock, and then got "00:10" on the game clock (tape recorder), the game runs just exactly as it should (speed-wise) on your system. So apparently CPU and GPU are powerful enough at least for "normal-sized" game window and R'n'D window mode. (Full HD sized levels and fullscreen mode may be another story though.)

Have not noticed either slow or flickery problems recently. I can't say it's fixed for all various setting combinations, only that I have settled on a combination which works for me.

Some years back I had observed that performance was much better on this machine I'm using right now (with a wimpy Intel Core i3-2310M CPU, 2.1GHz dual core, using the on-chip GPU), than on a beefier machine (i5-2410M with AMD Radeon HD 6400M/7400M). I haven't retested in a long time, but will soon be migrating my desktop activities to a fancier Dell refurb, so I may be revisiting that whole area soon...

Have not noticed either slow or flickery problems recently. I can't say it's fixed for all various setting combinations, only that I have settled on a combination which works for me.

As a quick check, you might like to temporarily rename your local R'n'D data directory (~/.rocksndiamonds), start the game (with default settings due to the newly created data directory) and check for any slow or flickery graphics/gameplay. If you should encounter such problems, it would be good to know if there is a single setup change that fixes it (most probably then being a change of the "special rendering" settings).