Implement resizable GUI

[Quipyowert2]

The resizing is a little buggy but it mostly works. One bug I noticed was that the buttons on title screen get mangled during resizing or the button disappears and only the text of the button shows. Another bug is the game sometimes flashes red when resizing, not sure why.

The way this works is the main thread spawns a secondary thread and then opens the window, listens for events and adds to an events queue until told to stop. The second thread handles events, logic and rendering. When exiting the game, the second thread tells main thread to quit the event loop. Then the main thread joins the secondary thread, closes the window, and exits.

SDL_PollEvent will block the thread calling it during resize on Windows, so that's why I had to start another thread to handle everything else. I changed SDL_PollEvent to el->poll so that the resize doesn't block the event loop.

Just tested this in a Linux VM and it crashes in SDL_GL_SwapWindow. It works on Windows 10 though.

TODO:

• Refactor the drawing code in MapEdit::run into a separate draw method.
• Implement support for painting MapEdit and Screen objects in EventListener.
• Fix textures turning white when resizing
  • Fix globules flickering
  • Fix cursor flickering
  • Fix tutorial message flickering
• Fix bottom of window not being drawn sometimes after resizing
• Fix blank frame sometimes being drawn on title screen and in tutorial
• Cursor and clouds animations are too fast when resizing the window.
• Optimize drawing routines

[Quipyowert2]

The crash in SDL_GL_SwapWindow on Linux is because of Mesa bug #7875, where the reference count of a resource was too low so it was freed before it should have been and then Mesa tries to use the freed resource.

[Quipyowert2]

After fixing the Mesa bug, I get a black screen with a white dot in top left corner when I resize Glob2 on Linux:

[Quipyowert2]

Fixed the black screen issue. I think the glOrtho call was conflicting with the gluOrtho2D call in GraphicContext::setRes or something like that. Removing the call to glOrtho but keeping gluOrtho2D makes the game stop being blank when resized.

On Linux, the right side of the game doesn't get drawn for a second when dragging the left border of the window to the left. On Windows, the vertical white line on the right side of the game in tutorial seems to be drawn multiple times at different horizontal positions when enlarging the window.

This happens when resizing on Windows 10 but then quickly fixes itself as soon as I stop resizing the window:

When that bug is fixed, this PR will be ready to be merged. There might be bugs on macOS with this PR but I don't have a Mac to test with.

[Quipyowert2]

I had to make these changes to Globulation 2 to get it to compile on MSYS2: https://gist.github.com/Quipyowert2/d2e1d3077efdbbc6b161a505445f1bce with the addition of prepending "/msys64" to each of the files in source_files.extend in src/SConscript.
And these changes to SCons to get Globulation 2 to configure successfully with SCons 4: https://gist.github.com/Quipyowert2/f6258728fd365464d8e1384d7b3dc79a

@stephanemagnenat how do I fix the resize glitch?

[Quipyowert2]

Part of the reason why I can't seem to get this to work right is because the game draws too slowly. When I measured the time for one frame, it was 41ms, but that might have been the result of too much locking/unlocking of mutexen. My laptop's screen runs at 60Hz, so it would have to draw in 16ms or faster to be able to live resize the window without draw lag on Windows 10.

[Quipyowert2]

Rebased on latest master so I could develop the PR in Visual Studio and extracted drawing code from MapEdit::run into MapEdit::draw.

[Quipyowert2]

When trying to compile this PR in Visual Studio, I keep getting the error "xtime: ambiguous symbol" pointing at the condition_variable header and saying it could be either "xtime" or "boost::xtime". https://gist.github.com/Quipyowert2/10923de2138d5f4faf63e2e5cc7c802a

The above compile error has been fixed by PR #83.

[Quipyowert2]

I have rebased again to fix xtime error and added another commit. I think I fixed the flickering of the globules, but the custom cursor flickers sometimes and the cursor animation goes too fast when resizing. When maximizing the window and then dragging the window downward on Windows 10, part of the tutorial message turns white and stays that way.

[Quipyowert2]

I've partially solved the globule, land, and tutorial message flickering problem during resize. After letting go of the mouse button when dragging the window border, some textures turn white. Fixed. Probably what I need to do is to consider the texture "dirty" if resizing happened during this frame or the last one.

[Quipyowert2]

Oops, forgot to initialize resizeTimer. This was causing Conditional jump or move depends on uninitialised value errors in Valgrind. Should be fixed now.

The main problem with this PR now is that the CPU load bar always goes into the red when starting the tutorial. The reason might just be that my computer has been running slowly lately.

[Giszmo]

I tried this out and it looks very glitchy. I think the rendering needs to be paused until the resizing is finished or something but even the edge I'm grabbing jumps around and doesn't stick to the mouse cursor.

Screencast.from.2023-11-15.21-22-56.webm

[Quipyowert2]

Maybe the reason for the persistent solid white flickering is that when calling SDL_GL_MakeCurrent in GraphicContext::createGLContext, it errors with wglMakeCurrent(): The requested resource is in use. I've tried changing the type of GraphicContext::context to be a thread_local variable, but then the game has different graphical glitches where all the textures are scrambled. Turns out I can't make the OpenGL context current from the main thread while the same GL context is current on the other thread.

The reason I am trying to render from the other thread is that the master branch of the game freezes when I drag or resize the window. There is probably a simpler solution I am overlooking. Also, sometimes the game deadlocks when I resize or move it, because EventListener::paint is waiting for the renderMutex to be unlocked, but the main thread is trying to call SDL_SetWindowSize.

The edge of the window moving around when resizing might be caused by the setRes calls I added in various places to handle resizing. setRes calls SDL_SetWindowSize which ends up calling SDL_SetWindowPosition.

[Quipyowert2]

The SDL bug with freezing when moving/resizing the window is reportedly fixed in SDL 2.30.