[WinSDL r6995] Stopped working error (was: An error here)

[Dwachs]

I do not remember exactly, maybe zooming is involved. At least valgrind complains a lot about reads out-of-range in the display_alpha_wc routine, when displaying water animation blended with slope lightmap.

One could of course force the water animation to be of the same size then the flat slope.

The code implicitly assumes already that this is the case. Hence the bug, crashes, and glitches.

[prissi]

This code would only have an impact when zoomed out, because only ten many tiles may need a redraw. Personally I would rather force the water tiles to have the same shape, and otherwise correct it on loadtime. But if there were that many valgrid complains, having a safe routine for now might be the more secure solution.

[Ters]

It's difficult finding out if and why the images don't fit if the only way to see that it happens is by running in valgrind (slow as $@!%), spotting random visual glitches or hoping for a random crash. But Dwachs' patch might at least offer a place to put a breakpoint.

[whoami]

This code would only have an impact when zoomed out, because only ten many tiles may need a redraw.

I use Pak128.Britain (nightly), usually with zoomed out display, and have seen the discussed crash on scrolling four times (the last was with r7003) in several hours of playing.

[Ters]

I've been able to reproduce, if not a crash, then definitively something that's not right. It only affects single tiles of land in the water, which clearly use random data as its mask. Happens predictably and immediately, and affects pak64 and pak128.britain alike. Zooming is not required, although I guess that might eventually lead to a random crash.

From the looks of it, this is not something to gloss over during rendering. Crashes might as well happen when creating the cached rescaled images. We must find the origin of this bug, whether it is in makeobj or simutrans itself.

Update:
When there is a flat one tile island, display_rezoomed_img_alpha gets called with alpha_n=0. I'm not sure what's at images[0], but I'm pretty sure it's not an alpha map for a ground tile. The image in that slot is only 4x4. Another call to display_rezoomed_img_alpha (picked at random) gets an alpha_n corresponding to an image with size 64x17, which sounds right for pak64.

[Ters]

I think the cause chain is as follows:

grund_besch.cc line 585 through 587 causes all_rotations_beach[80] to be left uninitialized.

A flat land tile has corners = 15, which means double_corners on 986 get set to 80. When all_rotations_beach[double_corners] is false, which it likely is since all_rotations_beach[80] was left uninitialized (and it's in static storage), alpha_water_bild[ x] gets left uninitialized for all x corresponding to a flat tile.

This means that when grund.cc calls display_alpha, it passes 0 as alpha_n, which is the image number for a likely completely unrelated image.

[Dwachs]

Thank you very much for this analysis! Revision 7008 now should bring the fix.

The problems with pak96-comic still happen, they need the patch for display_alpha_wc.

[prissi]

Sorry, it seems I was too keen on saving images (and time) when I added the patch to save images.