[BUG][EDITOR] Background not updated when loading a level of the same size

[Dullstar]

Found in latest stable; did not test in latest experimental.

Updated OP with more accurate steps.

To replicate:

1) Load or create any level.
2) Load a level that is the same size as the current level, but has a different background.

Result: The background from the first level will be shown. This is purely visual and only affects the editor: the correct background will be shown in the player, and if the second level is re-saved, it will keep its original background (unless you change it yourself, of course). This only happens the second level is loaded; a new level will not be affected, even if the first level is the default size.

This size requirement means that in a fresh editor session, you can't properly display the background of a default-sized level with a background other than the default solid black without first taking other actions, such as resizing the default blank level, loading another level (of different size) first, or manually selecting the correct background.

The earlier report had some incorrect observations as a result of the at-the-time unknown size requirement.

Old report (click to show/hide)

To replicate:

1) Load or create a level that has a background.
2) Load a level that does not have a background (i.e. the default solid black).

Effect: The background from the first level will remain displayed in the editor. This appears to be a rendering bug in the editor: if the level is played or saved, the level will not contain the background. This will only happen if the first level has an image for a background, not a solid color provided by the level theme (e.g. the solid blue from L2 Sports). However, a solid color provided by the level theme does count as a background for the second level, and will be displayed properly. EDIT: This observation on my part was due to another requirement, found by namida - the level must be the same size for the bug to occur. I tested with a solid color background level I already had lying around, which was a different size than the level I found the bug with, which led to the expected behavior rather than the bug behavior, and when I tested new levels, I didn't run into the issue because none of my recent levels use the default size, and I didn't think to try changing it in the test levels.

This also does not appear to happen when creating a new level instead of loading an existing one. EDIT: Retested this with the new knowledge about the size requirement; this observation holds.

I think that should be understandable, but I'll provide more concrete examples just in case:
For all examples, when I say "using [style]" assume the level theme is set to this style.

Example 1:
1) Create or load a level using orig_marble and the style's included background image. You do not need to save this level.
2) Load a level that uses orig_marble or orig_crystal (it probably happens with the other orig sets too, but I can personally confirm it happens with these two), but does not use the included background.
Result: the loaded level will show the orig marble background in the editor.
3) Save and/or play the level
Result: the level will have no background

Example 2:
1) Create or load a level using L2 Sports. Make sure to set the level theme so you get the solid blue background!
2) Load a level that uses orig marble or orig crystal, but not the included background images (again, this just happens to be what I tested with).
Result: the expected solid black background will be displayed.

Example 3:
1) Create or load a level using orig_marble and its included background image.
2) Load a level that uses L2 sports (and its solid color blue background).
Result: the expected solid blue background will be displayed.
EDIT: These observation is a result of the level size difference.

[namida]

Okay so, it seems to be quite inconsistent as to whether or not this occurs, but I seem to have found steps that consistently reproduce it for me - and have confirmed it still happens in V1.25 (the experimental).

If I create a new Marble level, and first select the background, then add two terrain pieces, then an object, and then open "Just Walk" from LPI, it seems to consistently trigger this issue. This is the only sequence of steps, so far, that has managed to reproduce the issue for me - including that opening other Dirt levels doesn't seem to trigger it.

EDIT: Okay, I think I've found the key detail that was missing. There is an additional requirement for this bug to trigger: The level with the background, and the level that you load, must be the same size (or at least the same width - haven't tested differing heights yet). EDIT 2: Yes, it applies to height as well. Expected as much, but always good to test.

[Dullstar]

Okay, I think I've found the key detail that was missing. There is an additional requirement for this bug to trigger: The level with the background, and the level that you load, must be the same size (or at least the same width - haven't tested differing heights yet). EDIT 2: Yes, it applies to height as well. Expected as much, but always good to test.

That would explain how I missed this detail: when I first create a level, I start by resizing it to the largest size that fits my screen without scrolling (1920x1080, low-res mode, 5x zoom, so a level size of 384x184), then expand as needed. Thus, 384x184 is the most common size among my levels.

One of those levels (using L3 Biolab) had a background image - this level hasn't been released anywhere. The other test levels have been released - Barrier Bypass (orig_crystal), Shimmier Sort (orig_marble) and Athletic Rescue Operation (L2 Sports). Further testing shows that the size difference, not the background difference, is the cause - of these 4 levels, Shimmier Sort, Barrier Bypass, and the L3 Biolab level are all 384x184. If I create a 384x184 L2 Sports level, it behaves just like the Marble background image.

I've updated the OP and thread title.

[namida]

I haven't at any point explicitly fixed this, but it appears that other changes have caused this bug to disappear in the latest code (haven't tested current stable release to see if the same is true there).