Epoxy automatically fetches the extension functions on demand, including
the GLX context creation functions. This means that you can't test the
function pointers for NULL anymore, because they're always set to a
resolver function until the first call. Instead, you have to check for the
availability of an extension by the extension's name. Thanks to Isilkor for
catching these.
On windows, epoxy invalidates all extension function pointers when the
GL context changes. This means we need to have an active context at all
times we call an extension function (like wglGetPixelFormatAttribivARB)
or else the code will jump to an invalid pointer. On the other hand, we do
not need to make it reinitialize the pointers ourselves.
Epoxy automatically uses an alias for a function if the requested name is
not available, like glDebugMessageCallbackARB instead of
glDebugMessageCallback. It also does not have the problem with varying
parameter types for that function. So switch to it while removing
GLDEBUGPROCARB_USERPARAM_IS_CONST.
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.
Günther Brammer