Since LTCG is enabled now, we don't have to define every function inside
the headers for ~xXx super speed xXx~, which means we can strip the
headers down to their bare minimum and reduce interdependencies and
therefore recompilation times by a lot.
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.
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>
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.
Instead, compute the projection, modelview and normal matrices explictly
and upload them as shader uniforms. This is one step towards using the
OpenGL 3 core profile.
The problem was caused by every window using an own OpenGL context and certain objects not being shared between those.
The best solution would still be to make all windows use ONE OpenGL context. But this would probably need a more or less large rewrite?
This solution has to be considered a workaround with basically no negative side-effects, as the loss of speed is most likely irrelevant in editor mode.
This should improve cache coherency by having all surface tiles adjacent
instead of strewn across the heap. This will also remove an indirection
in the common case of only using one tile.
Particle chunks were removed from the list (in the particle thread), but never deleted. They must be deleted from the main thread since it will delete GL objects. So simply delete empty chunks in the drawing proc.
As discussed in http://forum.openclonk.org/topic_show.pl?tid=2917, I
have merged all copyright notices into a single file and referenced that
merged file from each source file.
For the updated source files, the timeline has been split into three
parts:
1. Pre-RWD code (before 2001)
2. RWD code (2001 through 2009)
3. OpenClonk code (2009 and later)
All pre-RWD copyright notices have been left intact, as have RWD-era
copyright notices where the file did not have a RedWolf design copyright
notice but only individual author ones. All copyright notices of the
OpenClonk era have been replaced by a single notice ranging from the
first recorded year to the current year (2013). Mape code did not get a
OpenClonk Team copyright notice because it is somewhat separate from the
main OpenClonk codebase and has only been touched by Armin Burgmeier.
This should fix an error with incorrect particle lists after loading. This is also a cleaner way overall, since only a fraction of all objects will ever have particles attached to them
Even though the whole data is (still) transmitted every frame, I get a pretty high (2x) performance increase on my system. I suspect that the graphics card has to allocate less memory every frame.
4e875f4 didn't quite catch all instances of C4BltTransfor::SetRotate
being called, and silent conversion from int to float meant that those
rotations were incorrect by a factor of 100.
Lukas Werling