Bridges make water think it is falling
andybalaam opened this issue · comments
A bridge below seems to make water think it is falling when it shouldn't be. I'd expect the above screenshot to show a full-looking cup of tea.
Are the cells full? If you pause the overlay shows the amount of water in each cell. Knowing this will help to show if the bug is in engine or render.
I have a hunch this is in render.
Really enjoyed generating this screenshot because water is so cool.
Yep, definitely looks like rendering is the problem.
I've had a few goes at making a simple level that I can just run without user interaction to demonstrate the problem. I can't reproduce it. Can you post a simple level, or a solution to a level that shows the problem?
Interesting. When I make the bridges be there at the start of the level it doesn't seem to happen...
Ah, got one:
#r# i #
### #
#P (#
# #
#r #
#iri #
#######
:solution.1=until:LOST
I love just watching water flowing.
I hacked SwingGraphics.tacticalOverlay to show WaterRegionRenderer.isFalling. is does report that the water is falling where it should not be. then ran out of time...
isFalling() looks uses isFull() for the cell below. isFull needs the height and targetWaterHeight to reach 32. In the cell with the bridge in above the solid block these get stuck at 19. WaterRegion.getContents() returns 622 (622/32=19). Now need to figure out why that is stuck. Problem actually seems to be in engine...
@tttppp ?
in setTargetWaterHeight() WaterRegionRendered.getContents() is used, and returns 622 for the cell. When the overlay is drawn WaterRegionRenderer.contents is 1616. Need to understand why this number is changing within 1 time step.
If it's a problem in the engine then it'll be because bridges are being treated like slopes for some reason. We should fix this before releasing a load of levels with solutions that depend on the current behaviour :-)
I've just checked the code and I'm pretty sure it's not a problem with the slopes being confused with bridges. Perhaps it might be an issue with the code that re-evaluates the WaterRegion grid when changing the block type (i.e. none -> bridge).
I can observer the issue in WaterAnimation.step. There are a list of WaterRenderers that each maintain a reference to a WaterRegion. I've added some debugging around the cell at (3,5):
/**
* Game step. Usually ten animation steps per game step.
*/
public void step( World world )
{
if ( null == world || null == lookupRenderer )
{
return;
}
moderateParticleCount();
List<WaterRegionRenderer> currentRR = lookupRenderer.getListCopy();
for ( WaterRegion w: world.waterTable )
{
if ( w.getContents() == 0 )
{ // Empty regions do not need renderers.
continue;
}
WaterRegionRenderer r = lookupRenderer.getItemAt( w.x, w.y );
if ( null == r)
{ // Create renderer for region that does not have one
lookupRenderer.add( new WaterRegionRenderer( w, world, this ) );
}
else
{ // Remove renderers that are being used from temporary list.
if (w.x == 3 && w.y == 5)
{
System.out.println("#Remove r: w: " + w.getContents()); // 1120
System.out.println("#Remove r: r: " + r.region.getContents()); // 622
}
currentRR.remove( r );
}
}
// Remove renderers that no longer have regions
lookupRenderer.removeAll( currentRR );
for( WaterRegionRenderer wrr: lookupRenderer )
{
wrr.setTargetWaterHeight();
}
}
If we add the following hack at that point, to set the region in the WaterRenderer then the animation looks better:
if (r.region != w)
{
r.region = w;
}
I started looking at your PR. It's quite a big diff! I ran out of time.
As it was, with a WaterRegionRenderer for each WaterRagion, it was quite complicated. It sounds like a good idea to simplify this.
I merged it since the cod looked sensible. I will re-run the animation above to check whether this but is fixed.
@colonelfazackerley I really want to encourage people other than me to review, so now regret merging this without your go-ahead. I will do better in future.
Fixed!
I will still try to have a look. The original problem was my fault, I think.
I can still enjoy posthumously whining about @tttppp 's PR :)
2 things that would have have made it easier to merge this @tttppp :
- If I had established an automatically-enforced code formatter there would be no whitespace in the diff
- If you had made the code formatting a separate PR.
Awesome work from both of you, thank you!
Agree about making the code formatting a separate PR. Unfortunately I made my change on an old copy of the code, and then had to rebase across a massive reformatting change. I decided it was easier simply to reformat the whole file again, which then caused a whole load more things to get formatted.
Anyway - thanks for merging!
Thanks for the good fix.