Cogito
commented
6 years ago Ok thanks, I hadn't noticed this yet.
There are probably a few things I can do to make this better.
Firstly, every chunk is iterated over when the flood updates, though I try to be quick when deciding if a chunk is likely to be flooded. I could potentially keep a list of which chunks exist and need checking, but would need to profile to work out if this makes much difference.
Spreading the actual flooding over multiple ticks is a good idea.
Something that might look cool is to do the flood in a 'wave'. Flood just 1-2 tiles at the centre of the flood front, and each tick flood the tile either side of them. Alternatively, flood x number of tiles each tick, or x ticks. This would make the flood 'push in' at the middle, and spread the update over multiple ticks. Once the flood front is wide enough (once it is flood_speed, or flood_speed / x number of tiles wide) there will actually be an update every tick, but it should be small.
I suspect the performance hit is coming in the call to change the tiles to water. The game runs a 'fixup' after changing the tiles, to make the boundaries of everything look nice. Things like fixing cliffs that have changed, or decorations that are overlapping water etc. That is one reason to change multiple tiles at a time, as this fixup happens across all of them together.
Another way to improve performance is to reduce the number of fixup calls that happen down to just one. At the moment I have one fixup call per chunk, per flooding event. It would be easy to change this to just one per flood event.
@judos what kind of map were you seeing the lag spikes? As in, what is the easiest way for me to reproduce this? I can probably just get a map with lots of chunks exposed is my guess.
judos
Nice idea this mod! But there is a big lag spike every 10s because the update is done in 1tick. If you spread the work into all the different 600 ticks (10seconds) I figure there wouldn't be any noticeable lag.