Fix generation of sand worm passable sand regions.

[juj]

Also as result, this fix unfortunately uncovers some kind of bug in the rendering of the sand worm movement shimmer, which has some kind of blitting bug in it.

This causes the whole terrain layer to disappear whenever sand worm is moving, so disable the rendering of the shimmer for now.

Fixes #23.

[juj]

Made a video that shows how the terrain layer disappears while the sand worm is moving after fixing the sand region flood fill, but before disabling the rendering of the sand worm shimmer:

https://youtu.be/yRIPLx6yRNQ

Video that shows how the rendering looks after applying the temporary workaround:

https://youtu.be/WH0i8WeqZ7c

[juj]

The PR also adds a debug log print about the sand regions. In Harkonnen campaign level 6 it looks like this:

INFO    :   Generated Sand Region ID=0 with 3 tiles in it.
INFO    :   Generated Sand Region ID=1 with 2207 tiles in it.
INFO    :   Generated Sand Region ID=2 with 1 tiles in it.
INFO    :   Generated Sand Region ID=3 with 38 tiles in it.
INFO    :   Generated Sand Region ID=4 with 182 tiles in it.
INFO    :   Generated Sand Region ID=5 with 29 tiles in it.

that is helpful for validating that the algorithm runs correctly. Level 6 looks like

[juj]

One thing that caught me off for a moment is that it looks like the sand regions are not recomputed on savegame load, but only generated when a new level starts. (i.e. they persist in save games)

As result, reloading a savegame was not enough to test, but have to remember to reload and then restart a level.

[henricj]

Also as result, this fix unfortunately uncovers some kind of bug in the rendering of the sand worm movement shimmer, which has some kind of blitting bug in it.

Ugh. This is the same problem that occurred with the sonic bullet a few years ago (2057458). Back then, I put the "fix the sandworm rendering too," task on hold until I could come up with a better solution for the bullet.

I like the main part of the PR, but the SandWorm.cpp change probably belongs elsewhere. Besides, the dune::globals::screenTexture isn't really used anymore. I'm looking at adapting the sonic bullet hack for the sandworm right now. In the meantime, I'd suggest "#if 0"ing at least the whole section from SDL_GetRenderTarget() until the original rederer is restored (the renderer used to point to that screenTexture, but is now pointing directly to the window).

[henricj]

cab935f brings over the shimmer rendering work-around from Bullet.cpp. It is better than before, but it isn't great. Try playing the "Wormhole" or "Worm Investation" multi-player maps to see a lot of worms at the same time.

[juj]

cab935f brings over the shimmer rendering work-around from Bullet.cpp. It is better than before, but it isn't great. Try playing the "Wormhole" or "Worm Investation" multi-player maps to see a lot of worms at the same time.

Pulled this now - Looks quite noticeable and solid now to me - similar in effect from what I remember from the old days!

[henricj]

I updated it again. This time without crashes and the horrible rendering performance.

[henricj]

The bullet code might also cause problems if there are too many on screen at the same time. (At least, I suspect that is what was going wrong down in the bowels of SDL's DX11 code.)

Beyond tweaking the color, playing with SDL_ComposeCustomBlendMode(), and re-doing the mask texture, I'm not sure what simple things one might be able to do to get it to look better without killing the rendering performance or a bunch of work to re-render the relevant tiles through a mask, slightly offset from when they were first rendered.