USE_WIN32_WINDOWS was previously defined in PlatformAbstraction.h. Move it
to CMakeLists.txt and config.h like its peers. Replace USE_X11 with USE_GTK
or GDK_WINDOWING_X11 as appropriate.
Min/Max with array parameter will return the smallest/largest value of
all elements of the array. If any array element is not an integer, nor
convertible to integer, the function will fail.
I guess the UI elements expect their position to already be corrected by cgo.X/Y. Or they never cared because they were in front of the upper board.
I am not sure, maybe the correct solution would be to actually position all elements lower (instead of adjusting for it when passing mouse input or drawing)? Currently the position is relative to the upper board's edge.
Anyway, this works for now.
Otherwise, if a window was GUI_FitChildren and the text would NOT trigger a scrollbar, the window height was set to 0 (because the text height was only taken into account when rawTextHeight - 1 > rcBounds.Hgt).
Previously, text windows would just change their own size and leave cropping and scrolling to their parent. This made the code easier, but was apparently unintuitive for scripters.
Now text windows do not change their size but show a scrollbar themselves (unless GUI_FitChildren or GUI_NoCrop of course).
This implied some other changes, because now parents without a scroll bar need to clip, too. (Or the clipping needs to be moved to the child window. But then it would have to be made sure that menu decoration can still go out of the bounds.)
And this also needed some script fixes where scripters assumed the text windows would not scroll (and thus made them smaller than 1em).
related to https://git.openclonk.org/openclonk.git/commit/46ad28ea652fad34814a866f3b9c305aa7cc6faa
Not sure why this broke, maybe glGetIntegerv does not return the current
polygon mode anymore. Either way, we don't need to remember the previous
setting but can just always reset it to GL_FILL afterwards.
The buffer offset was encoded in the VAO which would be shared across all
submeshes. Instead, don't encode the buffer offset into the VAO but apply it
with glDrawElementsBaseVertex().
glDrawElements needs an IBO when using a core profile. The particle
system's IBO is actually quite static since it's always a triangle
strip with 2 triangles followed by a PRI. Therefore, this reduces the
amount of data we have to send to the GPU compared to the previous
solution.
Also, remove the workaround when glPrimitiveRestartIndex is not
available since it is always available with OpenGL 3.1 and when using
a core profile we are guaranteed to have OpenGL 3.1 anyway.
This is required for glDrawElements() with a core profile. Furthermore, for
meshes that have a fixed face ordering (non-transparent meshes at 100%
completion), this puts more static data on the GPU that we don't have to
upload every frame.
For meshes with non-fixed face ordering, we still have to upload faces every
frame, since the ordering might change if the mesh rotates. We could still
improve this by figuring out if the order actually changed after the sort
step, and only update to the GPU if it has. In many cases it hasn't, so there
is some potential for more optimization there. But that's for later.
This code was basically never used anyway, since the
ARB_non_power_of_two extension is always available since OpenGL 2.0.
The GLEW check for the extension fails however as soon as we select
a OpenGL 3 core profile, and the texture sizes will be unnecessarily
adjusted again.
Basically add another layer of indirection around accessing VAOs. The problem
is that VAOs are not shared between OpenGL contexts. This mechanism allows to
treat them mostly as if they were shared if they are only accessed through
the API defined in CStdGL.
This is accomplished by caching all existing VAOs per context. If a VAO is
being accessed, it is checked whether that VAO exists in the currently
selected context. If yes, return it, otherwise create a new VAO and return it,
together with a flag that indicates that the VAO needs to be initialized.
The former is not available in a OpenGL 3 core profile, but glGenerateMipmap
is available since OpenGL 3.0, and so is always available when we have a
core profile.
This prevents a crash when an incompatible engine function is used as an
engine callback function.
Unfortunately, this breaks any scripts that have wrong type information in
engine callbacks and only worked because those were ignored.
The engine has a few more usages of the operators, but they don't look
prone to overflowing. The other operators in Script already used SetInt,
which always truncates to 32 bit.
Since mesh instances can now be attached to attached definitions, attached
definitions need to denumerate pointers recursively to make sure that the
reference to the mesh instance is restored correctly.
I am not sure why the 'isMainWindow' was there. It wasn't there in 7319f7b3cc and got introduced in the major rework in 049088be78 - I guess it was just an oversight that was not noticed because usually the UI windows have the text or other things that need to scroll on a deeper level.
Anyway, checking whether the window is a script-root window does not make any sense as far as I can see now.
Gamepad support is currently not working properly as many menus cannot be
navigated with a gamepad. Simply don't load any control assignment sets that
have gamepad enabled.
Otherwise the font chooser in the startup options shows those fonts, but
loading them will fail. Ideally we replace this by enumerating the system
fonts at some point.
Some sort of smooth scroll information was passed down to the engine which
didn't handle it properly, or the units with which they were reported to us
were different from what the engine expected. For now, just use fixed scroll
offsets until we implement proper delta-y-aware scrolling in C4MouseControl.
The fix for #1574 might have also helped with this in recognizing when Control
is pressed and when it isn't.
For example, keydown events when pressing/releasing the shift, alt, or control
keys. With this version this is needed ingame e.g. to pick up objects with
Shift.
Reuse the windows code for this. Both versions had three parts: Enabling
the right menu items, adding the selection-specific ones, and showing the
menu. The second part is now common code, with the platform code in a new
function, since it grew big enough to be worth sharing.
glObjectLabel would result in invalid VBOs if called on a not-instantiated object. glGenBuffers does apparently only reserve the name and not create the buffer itself.
For me the landscape and some objects were drawn completely black.
More information: http://stackoverflow.com/questions/26614130/opengl-debug-extension-with-globjectlabel
Found via --debug-opengl
which lead to
gl: high severity API error: GL_INVALID_VALUE error generated. ObjectLabel: unknown buffer object <name>
In earlier versions, DrawPatternedCircle was a fairly complicated function.
Nowadays, it just copies pixels in memory, bounded by a circle. Since we
need to convert our surfaces to a format GTK+ can use anyway, combine that
step with the circle boundaries. Also use a cairo surface instead of a
GdkPixbuf. Cairo uses almost the same pixel format, except for
premultiplied alpha. Ignore this for now.
Specifically, GtkGrid. For most cases, this is an increase in lines of
code, but the landscape tools dialog can now be done with just three layout
widgets.
While at it, use a toolbar and move the mode buttons into it, too.
9e771ac moved the Win32 ClearInput implementation into SetInputFunctions,
but broke at least GTK while doing that. 9a7d57c0d2 fixed the assertion
failure in GTK that resulted, but failed to restore the removal of the old
completions.
Fix this by folding ClearInput into SetInputFunctions in all implementations.
This reverts commit 790219ac7e.
This commit broke support for Mac OS X since Apple only supports OpenGL 3.0
with a core profile, not a compatibility profile. Revert this commit
temporarily for the 7.0 release, until we port all OpenGL usage to the core
profile with 8.0.
This fixes#1495.
This would crash for me when starting a game in developer's mode. Not sure if this is the best place for the fix. Maybe there is some other underlying issue. ck?
In doing so, refactor the way C4FoWDrawStrategy works slightly. Get rid of
immediate mode OpenGL, and instead populate a vertex array and an index array
as vertices are added to the draw strategy. Then render everything as
triangles.
The actual rendering is then performed in C4DrawStrategy::End(). It passes
the accumulated vertices to the GL. Also get rid of the notion of multiple
passes in C4DrawStrategy. Instead, C4DrawStrategy::End() can simply just draw
the bunch of vertices multiple times. This allows us to do the vertex
generation and GPU upload only once, instead of repeating it for every pass.
This allows the strategy to keep some state between invocations. I want to
use this in order to store a VBO in the draw strategy, and to avoid having
to re-create the VBO for every rendering.
We are already using VBOs for meshes, so we can rely on them being available.
VBOs are shared between contexts, so #1195 is not an issue, either. However,
keep the workaround in place for the VAO, which is not shared between
contexts.
I don't expect much of a performance benefit from this, but it works toward
removal of legacy OpenGL usage. Note that we are already using VBOs for
meshes, so this does not require any functionality that we don't require
already.
Changing the mesh material to something that does not use alpha blending
restores the originial face order. This caused a crash for meshes with
Completion below 1, since all original faces were copied, but the buffer
in the mesh instance was only large enough to hold the number of faces of
the incompleted mesh. To fix this, simply run the standard
select-faces-for-a-given-completion-value procedure.
This probably enlarges the maximum landscape height for borderbound objects.
The "infinity" constant +1000000 is larger than the biggest C4Fixed, so
would have been truncated to 16960.
The DynamiteBox sets the PictureTransformation to a degenerate matrix, to
prevent it from being rendered. Exit early in this case, since we are not
going to render anything anyway, and avoid the assertion when inverting the
matrix.
I think C4Game::InitKeyboard relies on the callback targets outliving the
keybindings and every other class is prepared to be deleted before
C4KeyboardInput::Clear(), so needs to hold a ref to the keybinding to
delete that in its destructor.
C4KeyBinding is the class that is used for that, and it sets the reference
count to 1 in the constructor, to represent the reference held in the
owning class.
On the other hand, C4CustomKey gets immediately forgotten by C4Game and the
only reference is held in the keymap.
To prevent this from happening again, make the C4CustomKey constructors
protected and C4Game a friend of the class.
Also remove an unused C4CustomKey constructor.
Replace the hardcoded VAI_ constants with that. The VAI constants are now
moved to C4DrawGL as C4SSA_ constants, similar to the C4SSU ones. This allows
to introduce other attributes to replace vertex positions, normals, colors
and texture coordinates with attributes in later commits. This, in turn, is
needed because the built-in attributes are no longer available in the OpenGL
core profile.
Also, while at it, cleanup C4Shader a bit. Use std::vector<> instead of
maintaining an own array of uniform names. Delete the vertex and fragment
objects after the full shader program has been linked. Make sure that
C4Shader::Init keeps the old program in place if the new one cannot be
compiled or linked.
Surfaces are initially created in locked state, and only when unlocked the
memory buffer with the surface data is uploaded to the GPU. The FoW code
however never unlocks the surface but instead operates on the OpenGL texture
directly. To fix this, introduce a new flag for C4Surface to create it in an
unlocked state.
This is not a memory leak in the traditional sense as a pointer to the buffer
is still available and is being freed when the surface is being destructed
at the end of the game. However, during the game there might be several
megabytes allocated that are never used.
I'm not really sold by this Lock/Unlock mechanism. Instead, there should
simply be a function to obtain the current texture data, and a function to
upload new texture data. That's for another time though...
For some reason, the C4TexRef constructor first uploaded a set of nulled
texture data, just to be replaced by the actual image data when Unlock()
is called. Skip the unnecessary step and instead just reserve the video
memory in the constructor.
This also fixes objects which previously jumped out of the water continuously, by adding an extra check to also capture faster moving objects. It could be made speed dependent, but that seems to be overkill for the situation.
The only use of C4RTF in its final moments was parsing out plain text
from RTF files anyway, so why even go to all the trouble instead of just
storing plain text in the beginning?
This was used to name snapshot releases of the Network2 branch, and has
seen almost no use since.
C4ENGINEINFO(LONG) was a duplicate of C4ENGINENAME and C4ENGINECAPTION.
Code outside of C4FoWRegion should not care about the internals of the
class. Therefore, we remove direct access to the backing surface (and
secondary buffer surface) and replace it instead with accessors that
return those few values that are required by outside code.
In order to avoid duplication, PlatformAbstraction.h has to be included at
the start of every source file, so that various headers can rely on it
being there. To avoid confusion, always rely on that, instead of sometimes
randomly including it or parts of it again.
Video recording and playback only worked on Windows, and recording only
handled video, not game audio. As such, it was of fairly limited use,
and there's lots of software available these days that handle both.
Günther Brammer