That solves some errors related out of bounds access.
Sometimes it happens when drawing a tile, others when checking passability.
It may differ from how maniacs deals with this (I suspect maniacs have an extra blank tile, with locked passability, just for OOB tiles).
The change doubles the amount of sprites on looping maps but this fixes all the rendering issues, especially with big charsets ($).
Most of the sprites are culled because they are out of bounds on larger maps, so the performance implications are small.
Fix#3149
For this a new render_ox and render_oy are introduced whose only purpose is storing this offset.
Could not use ox/oy as these are already used by the sprites for other purposes.
- Panorama is now set to 0 when no panorama is set (regression introduced in a recent commit)
- reset_panorama were already set to true in ChangeBG when clearing
- panorama_on_map_init was cleared too early
In some cases (not scrolling or looping) the position is reset after loading the panorama.
Here was the bug: Multiple ChangePanorama commands overwrote the reset indicator.
Added a async yield op to the event and made the panorama image important to ensure that the image is loaded.
Refactored Spriteset_Map to prevent deletion as the panorama change is otherwise a dangling reference.
Fix#2195
The reason for this is another edge case in the previous commit: The lower layer star tile can be partially transparent and the upper layer tile below, too.
In this case there will be a smear because the background is not drawn. This is not fixable without additional book-keeping but a screen clear solves it.
Store a reference to map_info and just trigger OnSubstitution()
to regenerate cached values.
This allows loading saved games with tile changes to actually
render correctly.
ToneBlit is very heavy performance-wise, which forced us to use two different ways to implement tintscreen in our screen:
- 1st method: "ToneBlit for individual elements (tiles, background, weather, sprites, etc.) when they're drawn": when tintscreen remains static it was more efficient, but slower when the tone screen gradually changes. This method allows us to fix a Sprite flash bug (a sprite flash shouldn't be tinted by the screen tone; i.e. a white flash with a dark tintscreen should stay white).
- 2nd method: "After all the drawables are drawn, ToneBlit to the screen": it's used during battles and when a tintscreen gradually changes, in this last case to improve performance.
The ideal solution would be using the 1st method to fix the flash bug. To implement it:
- Sprite: We invert the positions of ToneBlit and BlendBlit. This way the flash color will have priority and not be tinted in the 1st method.
- Spriteset_Map: Now in all the cases it uses the 1st method, so the code that allows the 2nd method is deleted.
- Spriteset_Battle: We change from the 2nd method to the 1st one. We set the tone for the background and the battler sprites.
- Background: We include the option of setting and getting a tone, and then draw it.
- Screen: We eliminate the tone functions since no other class uses them.
Refactor parallax handling into a dedicated namespace in Game_Map.
Treats SaveMapInfo::parallax_* info as an override and uses the
RPG::Map parallax fields as fallback when they are empty. This
fixes#1071.
Mauro Junior