Visual Glitch in Sobigo Levelset by Jurgen Bonhagen

[Vikits]

I am trying to play Sobigo levels (from Rnd Jue V8) in the latest release, 4.4.0.0. I am able to load the level, but I get visual corruption after the player character appears. Control works, and the level can technically be played, however. Screenshots explain the issue better.

How level looks when loaded before player appears


How level looks after player appears


Link to imgur in case the images don't show up.
https://imgur.com/a/20qQnrb

[Holger]

First of all, I wish you a happy new year!

Thank you for reporting this bug, which in fact exists since quite some time (at least since version 4.3.7.0).

I have just debugged and fixed this issue!

[Vikits]

Wish you a very happy new year 2025 as well. Thank you for the fast fix.

[TheOnyxGuy]

Yeah, it seems like the game doesn't exactly save position of the camera itself and instead just aligns it with player's position when loaded a tape, and since some levelsets prefer to have a forced camera offset that goes all the way to the edge of the screen for some tricks to work (I also used it several times myself). The thing is, I don't remember if it aligns the camera depending on what camera offset user has in their settings or if it centers the camera no matter what.

[Holger]

Initially, the "camera" (playfield focus position) is centered on the player. However, in the level mentioned above, there is no player at all in the playfield when the level starts, but the player is dynamically created using a custom element right after the game starts. The bug was caused by relocating the player which initially did not have a valid playfield position.

[TheOnyxGuy]

Huh, even no "Level start element"? That's strange. Oh well then...

[Holger]

Indeed it has a level start element! So everything is well-defined level-wise.

But the player that is appearing right after the level has started causes the game engine to change the focus to that player (which by intention and by level design should not change the scroll position). However, as the newly created player has no previous playfield position (but internally uses position (-1, -1) to indicate "not there"), a bug was triggered that attempts to calculate the new scroll position with this invalid position as if it was a valid playfield position, causing that strange bug that leads to a bad scroll position.