The GTK and OS X platforms already ignored the requested bit depth and
always used 32 bit. Windows and SDL would set a 16 bit color depth for
the screen, but still did all of the rendering short of the final
present in 32 bit.
In windowed mode, we shouldn't stop rendering just because we have lost
focus. However, we don't need to render at full framerate; throttling to
5 fps should be sufficient. Note though that we still have to calculate
game ticks at full speed so network games don't slow down when a player
tabs out of the game.
Even though we (might) change the resolution, that doesn't result in
loss of textures because we don't recreate the OpenGL context. Therefore
we also don't have to restore their data. I believe this code is a relic
from the DirectX renderer, which would lose textures when switching away
from a fullscreen window.
Previously, it was checked incorrectly whether the action was "Dig". Then the check was thrown out completely in https://git.openclonk.org/openclonk.git/commit/39e86474fccbd54eb357175d2b8fbec5c60639ab - which did remove the warning but not solve the defect.
This should be a proper fix. The shovel only does stuff when the user is digging AND actually using this very shovel for it.
When an UI element was only visible to a player (via the Player property), it still allowed ALL players to click on buttons.
I am wondering why noone else noticed that bug before. It's possible that it didn't show when the visibility was set via the menu's Target (instead of the Player property).
Maybe this was the cause of the "clicks sometimes do nothing" bug?
It isn't enough to check the top-level mesh, because attached meshes also
get a transformation from script. At least cotton branches sometimes do
that.
So check the matrix directly before using it and skip rendering.
"menu" is an error prone name in one of the most frequently used/overloaded objects of the planet. Actually, there was a bug in some other thing which disappeared now. So I guess something, somewhere uses the name "menu", too.
Anyway, this is more consistent (because the other control stuff is in this.control, too) and less error prone. So it's a good change regardless of whether it actually fixes an existing bug.
Unlike GLX, the OpenGL function pointers are context-dependant. Because we
need an extension function to create the context we're going to use, we
first need to create a temporary context. Since this is independent of the
library used to fetch the function pointers, decouple it from glewInit().
It's not clear that the glXCreateNewContext fallback does anyone any good
because it can't create the Core Profile Context we need, but better a
fallback message followed by Shader compilation errors than an obscure
X11 protocoll error. Probably.
Maikel de Vries