This revealed that the code for setting Par.i was wrong before, but didn't
matter because the jump target for all CONDN was set afterwards. But the
jumptarget for COND was set directly, and must be adjusted to account for
the bytecode that gets optimized away.
It pointed always to Pars + Func->GetParCount(). The only users were
VARN_CONTEXT, which can be replaced with PARN_CONTEXT that way, and
FOREACH_NEXT, where the parser can do the math and simply give a number
relative to the current stack position, like regular variable usages do.
This can happen when an engine function is made to call a script function
when the stack is almost exhausted. Since there was nothing catching that
exception, it'd mean a program abort. Move the bulk of the exception
handler to the outer Exec function, and only keep the saving of the exact
code position in the inner one.
While at it, simplify the pushing of the parameters to simply push the
right amount of parameters instead of pushing ten and then popping the
excess. Also move the creation of dummy parameters for DirectExec into
DirectExec().
In earlier C4Script versions, there were multiple variants of expressions,
all followed by the same operator options, but nowadays everything is more
uniform.
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.
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.
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.
This bug manifested itself in mysteriously growing PropLists with nil keys.
Some usages of Clear were simply to clean the newly-allocated table, and
need to continue to do so.
It isn't clear whether that call is necessary since the C4AulScriptEngine
constructor already does this, but it is clear that duplicating the call
all over is a bad idea.
This allows the removal of quite a few return C4Void();.
Also stop pretending that Nillable<void> is the same class as Nillable<T>.
Its only function was as an implementation detail for C4Void, which doesn't
need any implementation details anymore.
This avoids duplication of code in C4AulObjectFunc and C4AulEngineFunc
at the cost of boilerplate code working around the lack of partial
function template spezializations.
Instead of ThisImpl and ExecImpl, we could have multiple C4AulEngineFunc
spezializations deriving from a common template, but that would require
even longer and duplicated boilerplate.
This allows one to use the C4Value constructor instead of
C4ValueConv. To avoid unintended implicit conversions like
const char * to bool, add a private template constructor that
catches everything not in the list of intended constructors.
In the long term, there is no reason DirectExec should be concerned with
C4AulScript/C4ScriptHost. In the meantime, the lookup code from Fneval can
be moved into the function.
This allows eval in scenario script to access scenario script locals, but
that seems harmless.
Instead of tracking the status with a variable, simply test the loop-end
condition directly, and reduce code duplication between empty and non-empty
array contents.
Most of the changes are for exception safety. The parser references the
function stored in Fn when the function body contains a syntax error, so
the function has to stay around. In order to avoid memory leaks, store the
function and its containing proplist in their destinations before they get
fully parsed.
This doesn't allow functions directly in static constants or arrays.
Future work: Putting the owning proplist in the scope chain.
The C4AulScript containing the source of the function was already mostly
used to get the relevant proplist or available from context. This will
allow more than one proplist plus the global one per scripthost to contain
functions.
Apparently, this wasn't done already because of compatibility concerns. The
beginning of a release cycle is the perfect moment to finally complete the
prevention of using deleted objects from script.
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.
Günther Brammer