[V2 only bug] Borders not properly filled with black when maximized

[win98se]

On Ubuntu 20.04.

Notice the left part, there are some remnants in the supposed black border area after maximizing and clicking on menus.

[win98se]

Also hijacking this issue with another one - for V1 on Wine, the language is forced to be system language (Simplified Chinese in my case) - changing them to any other language just doesn't work.

Sounds are like trash, music also doesn't work, but it should be expected to, I guess.

If you think this can be considered as an issue (as running V1 on Wine isn't supported scenario, right?), and if necessary, I can create another one for it.

[parkerlreed]

V1 on WINE is a mixed bag. You need a MIDI daemon running and configured for music. Sounds are always going to be a miss with how WINE handles the old odd sample rate. Pretty much not worth trying to maintain V1 in WINE since the native port exists now.

The border issue may be due to SDL turning off your compositor on launch. Trying launching with it already off (if possible) to see if that issue persists. Maximizes and fullscreens fine on Plasma for what it's worth.

[win98se]

Pretty much not worth trying to maintain V1 in WINE since the native port exists now.

Good point, this is also why I didn't create a separate issue for it.

The border issue may be due to SDL turning off your compositor on launch. Trying launching with it already off (if possible) to see if that issue persists.

I'm using Ubuntu 20.04 with GNOME as DE. How do I manually turn off the compositor?

[parkerlreed]

Looks like Gnome doesn't have a manual option. https://www.reddit.com/r/leagueoflinux/comments/e0c6n5/how_can_i_disable_compositor_on_gnome_to_improve/

That's about my extent of knowledge on that front. Hope you can get that solved.

[win98se]

Looks like Gnome doesn't have a manual option. reddit.com/r/leagueoflinux/comments/e0c6n5/how_can_i_disable_compositor_on_gnome_to_improve

In fact I read the same Reddit post too. ;)

That's about my extent of knowledge on that front. Hope you can get that solved.

Thank you.

[k4zmu2a]

On leftovers in void: I use clear on every frame, if that doesn't work I don't know what will.
I suppose rendering full screen quad will wipe the screen, but that is just wasting bandwidth.
On wine:
Sound should be as good (or bad) as the original.
Language switch: I have code paths for XP and Vista+, I don't know what wine needs, might be just broken.

[win98se]

So for further testing, I've installed vanilla Debian 11 on Hyper-V with LXQt as DE (update: also TinyCoreLinux 12.0, but with another dependency bug), and that bug doesn't appear.

P/S: Compositing seems to be not enabled here (because in Session Settings I don't even see anything about compositing), even when querying with xfconf-query -c xfwm4 -p /general/use_compositing returns true.

Update 2: I've managed to reproduce the same bug on Ubuntu WSLg (Windows 11).

[k4zmu2a]

We can summarize that this void issue is exclusive to Ubuntu DE.
Possible cause – conflict of SDL and compositor.

I doubt that buffer clear is not working, hard to imagine OpenGL failing like that.
This means that the image shown in the window is somehow processed after SDL GL calls.
It looks like the final image is selectively assembled from game output, we can see two updated regions on top of the old buffer: game table and collapsed menu button.

I am not adding any hacks just yet, I need more information.
Maybe once I get WSLg on Win10 I will test it myself.

[li20034]

Actually, it gets worse. If you enable integer scaling, and drag one of the ImGui windows near the borders, this happens.

I'm using Linux Mint Xfce 20.2 (based on Ubuntu 20.04), and this occurs regardless of whether I enable or disable the compositor in Xfwm. And indeed if you replace SDL_RenderClear in winmain.cpp with SDL_DrawFillRect (which is the hack that was discussed here), everything works. Also, without any hacks, setting the environment variable LIBGL_ALWAYS_SOFTWARE=1 does not help, but setting SDL_RENDER_DRIVER=software does.

[k4zmu2a]

Alright, it is time to address this issue.
Added hack - second clear via full screen quad.

Running two clears might lower the performance.
I did not notice any impact in my tests with dx9 and opengl.

Source ports are advised to stick to one clear operation, probably original SDL_RenderClear.

[k4zmu2a]

The fix was released as part of 2.0.1

[win98se]

Finally got the chance to test whether this bug is fixed on Ubuntu (because I was too busy) - it's now fixed. Thank you!