The old LineFeed constant caused problems with Qt. Using \n directly is
easier and I don't think there's a reason left to use \r\n anyways.
We've always converted the files in the repository. Nowadays, even
notepad.exe works with unix file endings.
A follow-up on a previous PR GH-41. The discussion in the forum can be
viewed at http://forum.openclonk.org/topic_show.pl?pid=33086.
Run clang-tidy (without auto, pass-by-value and using checks) to fix the
header files not modified in the previous PR.
Summary of the changes:
- C++11 member initialization.
- nullptr instead of 0 for pointers.
- override for functions declared virtual in base class.
- default trivial special member functions
Consolidate the include statements scattered across the code in accordance
with the comment in C4Include.h. The advantages are listed in the same
comment.
Furthermore, it follows llvm-include-order which is the logical
extrapolation of the project's style guideline wherever possible
(C4Include.h being the most-frequent exception).
The GTK code does not work with the Qt editor. The simpler SDL2 platform
does, so we have little reason to keep the GTK code.
Note that GTK is still a dependency for mape.
Discussion: http://forum.openclonk.org/topic_show.pl?tid=3328
This is an emergency fallback for older Intel drivers on Windows, which
do not support OpenGL 3.2. As we're creating 3.2 contexts mostly to
access the Core profile, which was not available in earlier versions,
falling back to 3.1 should be fine; I don't think we're using anything
specific to 3.2.
a) make sure the context is deselected on destruction, so that
CStdGL::Clear() destructor doesn't try to deselect a non-existing context.
b) Calling Clear() in CStdGLCtx::~CStdGLCtx() does only call
CStdGLCtx::Clear(), even though Clear() is virtual. The reason is that by
the time the CStdGLCtx destructor is executed, the CStdGLCtxQt part of the
object has already been destructed. Therefore, make CStdGLCtx::Clear() safe
to be run without the context ever having been initialized, and explicitly
call CStdGLCtxQt::Clear() in CStdGLCtxQt::~CStdGLCtxQt(). This is certainly
not the most elegant way to handle this, but it should do the job for now.
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.
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.
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.
To create debug contexts, we have to use glXCreateContextAttribsARB. To use
that, we have to initialize GLEW, which means creating a dummy GL context. To
create a dummy context with the same FB config as the final one, we need to...
initialize GLEW, because it suppresses the GLX 1.4 function declarations.
So instead we'll just manually initialize the three function pointers we're
going to need.
The GL driver is allowed to use different entry points depending on the
context. This means that we can't just initialize GLEW once and use it
all the time, but we must refresh the entry point list every time we
create a new context.
Some resources can't be shared across different rendering contexts while
others can. Additionally, the standard GLEW library does not support
multiple rendering contexts (that's what GLEX MX is for), even though it
might work on some (or even most) cards. WGL supports reuse of a
rendering context across multiple windows as long as the pixel formats
are the same.
The MSDN reference for wglMakeCurrent states that the first (hdc)
parameter is ignored when the second one is NULL. This is incorrect: it
checks validity of the hdc parameter before doing any work. Since we
have a DC anyway, it's no problem to pass that to wglMakeCurrent.
This introduces a new command line parameter "--debug-opengl", which
will create special debug OpenGL contexts and attach a callback that the
driver will invoke when it detects a problem. The callback will then
write the error message to the logfile, and break into the debugger if
one is attached.
Currently only works on Windows.
This gets rid of GL state changes for questionable gain. It also fixes drawing
of fade sky backgrounds in global viewports (where, for some reason, the shade
model was set to GL_FLAT instead of GL_SMOOTH).
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.
Direct3D hasn't worked for more than a year now, and there don't seem to
be any efforts to revive it. Remove it and concentrate on better OpenGL
support.
Lukas Werling