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.
This replaces the fragile ShaderRef construction in StdMeshMaterialPass, and
it allows to re-use shaders and/or programs between different materials. This
is some more preparatory work for custom shaders.
"gdk_pixbuf_unref has been deprecated since version 2.0 and should not be
used in newly-written code. Use g_object_unref()."
sys/timeb.h isn't used anymore since 2005.
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.
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.
Pre-computed floating point numbers can be safely used in the comparison
function, whereas recomputation every time the sort function is called might
lead to a crash when the computed number is slightly differently every time,
because the sort function would return different results for the same faces.
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.
I believe a possible cause for this is a object's model with a very low completion. However, I am not sure where the right place is to make sure everything goes alright in that case.
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.
The movement code relies on itofix(a + 1) == itofix(a) + 1, which requires
always rounding in the same direction. Since negative numbers are rounded
less often (Objects rarely are outside the landscape), change the behavior
for them.
This might make the rendering a bit quicker, since the whole texture
environment setup that we do every frame is no longer required --
instead only the shader is bound and a few variables uploaded. However,
this was not the main motivation behind this change.
It also simplifies the code a bit. The texture environment setup is
replaced by GLSL code generation. Another small benefit is that for
texture units in material scripts that do not use an actual texture
image no hardware TIU is being used. This reduces the number of hardware
TIUs required for rendering the Clonk from 3 to 2.
The main benefit of this change, however, is that material specific
and clonk specific color variations can be applied correctly. This mainly
concerns ClrModulation and MOD2 drawing. Before, the ClrModulation was
mixed with the material color, which could lead to incorrect results
depending on what the texture units were doing. Now it is being applied
by the shader after all texture units in the material scripts have been
processed.
Another motivation of this change is to implement support for custom
shaders, which is already foreseen by OGRE material scripts. The
specification has only to be implemented. With this change in place,
both custom shaders and "fixed" processing can share the same code in
the engine, since both end up using a shader for the mesh rendering.
The shader currently works only for directional lights, but should be
easy to extend to also support point lights.
This mostly simplifies things, since most other places use an 32 bit
integer to store colors, but might even improve performance through better
cache locality.
Since U+003F QUESTION MARK is a potentially valid character in a unicode string,
have the text iterator return U+FFFD if it can't decode its input instead. This
way the caller can be certain that the input isn't a proper question mark and
doesn't accidentally use it, e.g. as a wildcard.
gcc 4.6 generates better code for FIXED_EMULATE_64BIT disablen for both
32 and 64 bit. It properly recognizes that the 32,32->64 multiplication
instruction of the x86 is the right choice for the job whereas the more
complicated FIXED_EMULATE_64BIT version requires multiple multiplications
Thanks Günther for checking this! :)
This would happen when the product of the lower significant part, which is
between 0 and 65535 (even though C4Fixed is a signed data type!) exceeds
2^31, for example for val=36864, fVal2=61440.
These are the ones that the blender 2.6 exporter sets automatically. We don't
support them yet but we want to be able to load the material script
nevertheless. Many of the additional options are set to their default values
anyway.
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.
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.
The base64 decoding lookup table uses '\xff' to denote an invalid
value. On compilers where char is signed, this results in a value of
-1, which cannot be converted to an unsigned char in an aggregate
initializer [dcl.init.aggr p2].
Otherwise loading a savegame with an attached def mesh fails if the mesh
has neither attached meshes or animation nodes since the [ChildInstance]
section ends up empty in which case StdCompilerIniWrite does not write the
section at all.
This fixes a bug where sequences were incorrectly accepted when they ended with
a multibyte sequence, the end of which was beyond the passed string length.
MultiByteToWideChar doesn't do anything when it gets a buffer length of 0,
so it doesn't nullterminate the memory, so EnumerateDisplayModes fails because
of an invalid monitor id.
Internally, strings are UTF-8 as before, but GetChar returns an
Unicode code point instead of a byte from the UTF-8 encoded string,
and Format("%c") takes an Unicode code point as well.
This ensures that classes that inherit from these have their destructors
called even if they are deleted with a pointer to the base class.
Though at the moment, this just silences a warning.
Instead, retrieve the number on demand during serialization. This saves
lots of unnecessary code and makes serialization actually not modify the
objects. At least with the exception of nInfo, but that should be save.
The BitfieldAdapt had a builtin default of 0 for serialization, so it needs
that default when deserializing. Also remove that builtin default.
When AnimationNodes were loaded out of order, some of them were thrown away
when their vector was shortened. Don't shorten the vector during load.