If the gamepad code initialized the SDL video subsystem, GTK+ crashed in
libX11. Or something along those lines.
Making the optional subsystems using SDL for gamepads and audio use
SDL_InitSubSystem and only the SDL Application port do the full SDL_Init
is the proper way to do things in any case.
It used a mix of tabs and spaces for indentation, and tabs to separate the
columns, which doesn't work with variable tab sizes and variable column
widths. Use tabs for indentation and spaces for column separation.
Which means that you can
1) Drag around the tree / nest in editor mode
2) Shoot zapnests that were put into a catapult by a scenario designer
3) Can RemoveObject a tree and the nest will fall down (instead of keep floating)
4) Can put zap nests in earth (just like in CR!)
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.