Cache improvements and effect caching

[Ghabry]

not ready yet, have strange flickering.

Improved the caching strategy, before our Cache was unlimited and never cleared any recently (<5s) used assets. Now the clear is forced when the memory usage is 10 MB (+3 MB SE).

Which means the memory foodprint is in simple games (havn't used the MSVC memory profiler yet) ~20 MB plus Database.

Besides reduced memory usage the effect cache should also help in some situations to make the effect faster because tone & flash are only calculated once now per same charset.

Related #1177

[Ghabry]

Comparison images: (already making them now, as the "flicker fix" won't increase the memory usage)
The biggest impact has "Fix the out of bounds check code" but combined with "Support caching" it helps to prevent increase of memory usage over time (when more parts of the map are visited).

Note: These are manual recordings, so the time axis won't match, look at the memory usage.

Obviously highly suggestive because I picked the most crazy examples. In IB e.g. the change is around 0, stays at ~22 MB the whole time.

The Looking Glass:

Master:

This branch up to "Fix out of bounds":

This branch all commits:

RPG_RT: 21 MB but they have two advantages: They use 16bit and for Tone effect they modify the palette instead of copying.

Yume2kki

Master: (32bit limit -> crash)

This branch up to "Fix out of bounds":

This branch all commits:

RPG_RT: 37 MB

[Ghabry]

The flicker fix also will contain yet another minor improvement: It saves 258 KB per CharSet that is affected by a screen effect. Saves a non measurable amount for "The Looking Glass" and 2 MB in Yume2kki.

The "Operator <" is required for keys in std::map.

[Ghabry]

Does this require constexpr? It could be useful as a tunable parameter in RPG_RT.ini

I can make it non-const.
Though I don't see that much use in making this tunable. You will always need at least a small cache for reducing lag on slow systems (e.g. without the SE cache Yume Nikki was unplayable on older systems because the IO and the decode took too long).
And even on newer systems not caching e.g. the system graphic has a noticable performance penalty, the Game Browser startup speed is now instant instead of delayed (and I always thought the cause is the FileFinder...)

[fmatthew5876]

Does this require constexpr? It could be useful as a tunable parameter in RPG_RT.ini

I can make it non-const.

Unless it's going to be exposed as a runtime config parameter I would leave it constexpr, at least then you can maybe eke out some additional compile time optimizations.

[fmatthew5876]

All this LGTM, though I admit I am not that familiar with this corner of the code.