Auto-detecting UPnP might fail when CMake was invoked multiple times.
This would result in a broken build because the compiler would not find
<natupnp.h>.
Partially reverts cf474e99aa.
Cmake starting to whine about usage of a deprecated feature is no excuse
for regressions. The cmake warning even explained how to do this!
CMake remembers the variable in subsequent runs, so setting it to true
if the copy from thirdparty/natupnp needs to be used will prevent that copy
from being used after a rerun of cmake.
The idea here is that we compose shaders out of "slices", which can
come from the engine ("built-in"), from files or possibly even from
models. This should allow us to more easily share the code between
different rendering shaders (e.g. for lights / normals).
TODO: Workarounds not yet implemented, so this might degrade less
gracefully.
This introduces a new texture, an ambient light map, that is generated
automatically at the beginning of the round by the sky portion of the
landscape. This basically makes everything that is close to sky visible
by default.
The shaders have been adapted so that they deploy direction-independent
lighting for the ambient component, and the current (diffuse) behaviour
for the diffuse component. This makes the shaders use an additional
texture unit that represents the ambient light. We can think about merging
this information into the light texture, but the coordinate systems are
different at the moment, so this could be performed at the stage of light
texture generation.
For meshes, the ambient material is not actually used, but instead a
diffuse light from the front is used. This makes many meshes look more
interesting, maybe also because the ambient material setting of most
meshes are not set correctly at the moment.
* intermediate fade triangles are now calculated in C4FoWLight
* rendering takes also place in C4FoWLight, using different C4FoWDrawStrategies
* solved an old TODO from Peter (int -> int32_t)
* refactor and simplify portions of the light vertex calculation code
Add a new cmake option WITH_SYSTEM_TINYXML=ON that allows to use the system
tinyxml library and header instead of the bundled copy. Adjust the include
path in the single source file referencing the header and add the thirdparty
path to the include search path if the use system option is unset or off.
* added some class and method documentation, removed some superfluous comments like
void C4FoW::Update(C4Rect r)
{
// Update all lights
...
* added ASK comments that need clarification before proper documentation
Remove the two dependencies to ::Game from C4MapScript, so that ::Game
does not need to be linked into mape, which would basically drag the
whole rest of the engine after itself.
There's no point in splitting the audio library selection into multiple
CPP macros, since there can always only be one anyway. Merge all of them
into a single macro AUDIO_TK (for "toolkit") and have CMake select one
for the user, instead of making him choose (and potentially failing).
Recent MinGW releases ship a pthread implementation for Windows. So while
CMake is technically correct in finding pthread, we don't want it to, and
instead use the standard Win32 threading.
The -std=gnu++0x-Flag was removed from the compiler flags before
testing the <regex> header, and so just re-confirmed that <regex>
didn't work in previous C++ standards.
f897e95071 broke this by reusing the macro with the path to the binary
as the binary name, which doesn't work if the path contains directories.
Also, 0dcfe72148 moved the binaries, but the LOCATION property still
pointed to the old location. Luckily, CMake also has a non-broken option to
pass target file paths to custom commands.
The distinction between the "aul" and "non-aul" parts of
the script engine are mostly historical accident, and the
current organization of the source code does not use
sub-subdirectories. I'd like to keep it that way.
This reverts commit 69ba06b8d0.
This makes CMake use the dynamic library instead of the static library on
my system. The latter doesn't link on today's Debian unstable due to a
missing libmad.a.
Recent versions of MinGW do no longer declare vasprintf in <stdio.h>,
but they ship a compatible function called __mingw_vasprintf. Use this
function if vasprintf isn't available.
CheckFunctionExists only checks for the function to be linkable, it does
not require any declaration in a header. CheckSymbolExists requires a
declaration and also linking to succeed.
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.
The new type C4TimeMilliseconds behaves for the most part like a uint32_t but is overflow-proof in comparisons.
In some places, a 0-value (or uint_max) of the variable storing the time had the special meaning "not set yet". This has been resolved by having it as a pointer to C4TimeMilliseconds with NULL meaning that it has not been set yet.
Telling Windows that we support Windows 7 means it will stop catching
unhandled exceptions that occur in a callback from kernel mode, and
allow our own crash handler to catch then.
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.
A large number of g++ versions ship a <regex> that declares all of the
required functions, but don't actually implement them, making using them
result in a linker error.
Fallback to Boost.Regex if the host C++11 <regex> implementation is
broken; the interface is the same anyway, only differing in the
containing namespace.
Unfortunately, Boost.Regex is not a header-only library, but this is not
a big deal because all major Linux distributions ship it, and Visual
Studio implements <regex> since 2010 (the oldest version we still
support).
ResTable (the main system string table) was a home-grown hashmap that
did not cope with collisions at all. Since we already have a proper
dictionary in C4LangStringTable, use that instead.
Since FindFreetype.cmake already extracts the version of freetype
from its header files, I have no idea why they're not automatically
using that info to look for the proper library name in lieu of
hardcoding a single version.
Previously, MSVC builds did only allow static linking of libogg,
libvorbis and libvorbisfile. If there was a reason to do so, I have no
idea what it was, because it isn't documented in either VCS or a
comment. So I'll allow both dynamic and static linking.
In practice, other libraries pulled pthread in, except for the USE_CONSOLE
build. But since there are direct calls to pthread in our code, we really
shouldn't rely on that.
Also, this should fix the USE_CONSOLE build on windows.
Metacity started to display bigger icons in the window list, so the higher
resolution is now actually useful for me. While at it, use gdk-pixbuf-csource
to generate the .h at build time from the .ico instead of duplicating the
data in the repository.
GTest does not ship precompiled binaries anymore. They are now compiled
using the CMakelists.txt from gtest.
Add basic unit tests for C4Value, DirectExec and C4StringTable.
Since the name of the game is OpenClonk, having the binary named
differently is at least confusing. At worst it conflicts with the
trademark license granted by RedWolf Design.
The Mac build will still have to be fixed because the installer
template .dmg file is not editable on non-Macintosh systems.
Ignoring CFLAGS/LDFLAGS makes GTK+ not work correctly
if the libraries are compiled with -mms-bitfields (as
is the case with the prebuilt binaries from gnome.org).
In practice, only the xrandr code path received any testing. Since Clonk
works fine without changing the resolution, this will not terribly
inconvenience anybody still stuck on old systems without xrandr.
Also only minimize the window when the resolution was changed.
The minimization is there to prevent accidental focus restoration
resulting in unwanted resolution switching.
Change the .sln file to make Visual Studio reload that; this also implies
reloading all of the child projects. This way, we don't get a reload prompt for
each loaded project.
On non-Express versions of MSVC, the CMake macros still run. I don't think there
is a way to disable them, but you can copy the macro body of StopBuilds to that
of ReloadProjects to only get a single dialog box.
Updates work only when the game data is at the same location as the binary.
If this is not the case then the game was probably installed differently,
for example via the distribution or with make install. In this case we
cannot do automatic updates but we also want to use a different system path.
This fixes the linux development snapshots and release tarballs. They were
broken in the sense that they didn't find their game data.
The usage of timsort instead of std::sort at this point is twofold. First,
it's faster in our case where the array is already sorted in many cases
(remember this is called at least once a frame). And it's not just a bit
faster either but a lot. I have measured a factor of 7 on my system.
Second, in our Windows autobuilds there is a crash within std::sort which is
very hard to debug because it's hardly reproducible with anything other than
the autobuilds (I tried hard). If the crash goes away with timsort then
great, if not then maybe it's easier to debug since the code is in our tree.
With this change, MSVC will build binaries in ${CMAKE_CURRENT_BINARY_DIR}
without adding any more subdirectories. It will also expect its data in a
directory called "planet" immediately below the binary directory.
Since MSVC allows building multiple configurations from the same input file,
the resulting binaries will be suffixed by the configuration type. An exception
is RelWithDebInfo, which will have no suffix; this was chosen over plain Release
to aid in debugging.
Building OpenClonk will work out of the box for in-source builds, but
out-of-source builds will have to create a symlink or a directory junction.
We consider this an acceptable drawback; it was proposed that if you use the
non-default option of an out-of-tree build, you will also know how to create a
link or a junction to, or copy the planet directory.
This changeset also revives looking for game data in the same directory as the
binary, which was part of c3fc1ee1ec8c [Peter Wortmann].
This time, the relocation code checks for a "System.c4g" in either
the executable path or a "data" folder directly below. CMake makes
sure that this points somewhere sensible for normal builds.
TODO:
* Check whether this actually works under Unixes. Can "ln -sf"
delete important stuff? Is there a safe alternative?
* Further unify with the Mac Os solution. Other platforms might
auto-pack for release builds too, for example - and it might
be a good idea to have a proper data subdirectory in Mac bundles
as well.
This fixes make install, which previously tried to install nonexistant
packed groups from the source directory. Make it use the ones from
the build directory and build them during make all.
The various small utilities do not use the engine Log implementation but
one that simply prints to stdout. Instead of duplicating that one, link a
common one into the utilities.
Although the code already uses boost, boost/uuid hides the sha1
implementation in a deeply nested namespace, which is just too bizarre to
use. Also the name of that namespace suggests that it is just an
implementation detail that could go away without notice.
This replaces the BUILD_TO_PLANET option and makes in-tree Makefile builds
run without further work. Out-of-tree builds need a symlink to planet from
the build directory.
This makes it possible to ship the bundle stand-alone. Also
note that CMake will automatically pack the game data for
release builds, but sym-link the game data for debug builds.
Note this means you will only see the parts of planet/ that
are mentioned in OC_C4GROUPS in CMakeList.txt! This is equivalent
to the behaviour of the shipped build, so I don't see this as
a problem.