Improved performance of city strategy view mode #247
Conversation
game/state/tilemap/tilemap.h
Outdated
| @@ -76,6 +77,8 @@ class TileMap | |||
| private: | |||
| std::vector<Tile> tiles; | |||
| std::vector<std::set<TileObject::Type>> layerMap; | |||
| // Cache for the strategy view mode. | |||
| std::vector<sp<Surface>> strategyViewCache; | |||
There was a problem hiding this comment.
I'm not sure if I like the cached images being stored in the game/state - it feels very much like a UI-specific thing. Perhaps this is the best place to keep the "dirty" state though.
There was a problem hiding this comment.
I understand your point.
Possible approach may be to create cache in the TileView. But in this case the TileObjectScenery and the TileObjectBattleMapPart should to know about TileView (or at least about the cache). It's not so easy to find a clever way to do this.
The TileMap lies in the key place which can be easily accessed as for CityTileView and for the BattleTileView and for TileObjects too. Thus the cache easely accessed for each who should to use it.
game/state/city/scenery.cpp
Outdated
| @@ -1486,6 +1488,7 @@ void Scenery::updateFalling(GameState &state, unsigned int ticks) | |||
| { | |||
| auto fallTicksRemaining = ticks; | |||
| auto newPosition = currentPosition; | |||
| state.current_city->map->setViewSurfaceDirty(currentPosition.z); | |||
There was a problem hiding this comment.
Perhaps the setViewSurfaceDirty() should be moved to the TileObject parent class? So that at TileObject add/remove/move it can mark the correct dirty bit? Perhaps have a dirty bit per "layer" (TileMap::layerMap) to
This will still need special handling for sprites that can change (if you want to handle more than the scenery layer) -
e.g. doodads/animations changing frame, vehicles/agents/projectiles when they rotate - or just not enable caches for those layers?
There was a problem hiding this comment.
Yes, its a good architectural approach.
I think only Scenery and BattleMapParts should be drawn to the cache. Thus only these classes can set the cache dirty.
Vehicles, units, projectiles etc should be handled separately because they movable.
|
The same for the battle strategy view mode. |
|
Hey redv great work |
|
It's a GOOD question. Possible a mess of dark and light layers. Need to find a way to avoid this. |
|
You could store off the palette for the last time the cache was created, compare it at the beginning of the render and if it's changed invalidate it? The palette values will change by (worst cast 0->255 palette swing) 255 over 3 in-game hours (from what I remember), so there should be ~40 ingame seconds between each palette change - still likely worth this optimisation for everything but the fastest turbo mode. |
|
The palette changes every update. First of all because of the colorCurrent. Possible to check colors inside palette, but in this case from time to time will be need to redraw whole map. This behavior will lead to jerks which will looks annoying. In the other hand, dark palette for strategy view is good as an option but not for regular game. I think the sprites for the strategy view mode were not designed for dark palette. BTW recalculate interpolated_palette every update not so good idea. Even in worst case the interpolated_palette should be recalculated every 6h * 60min/h / 256 = 1,4 ingame mins (once per 3000-5000 updates at normal speed). Last 4 color easy to set during each update. |
|
Please see issue #339 for another problem that slows cityscape performance. Many thanks. |
FilmBoy84
added
the
STALLED
The city strategy view mode on steroids.