Selecting a GL context during SolidMask initialization is not a very good solution. But as long as SolidMasks are stored in graphics surface we have no choice.
A better solution would be to generate a dedicated (non-OpengL) surface for SolidMask data on object loading. But then objects that have SolidMasks would need to be tagged somehow.
Direction is randomized at creation and there's no good way to find out if the user wanted that specific direction. So just always save it, because that's what scenario designer usually wants.
The power system isn't written in a very failsafe way when it comes to object destruction. Why are "helper objects" needed now that we have proplists to store such things?
Building OpenClonk with GNU autotools has been broken since early August
at least (9ceb692). Since nobody complained so far, I'm assuming nobody
has used it recently, and opted to remove the broken code.
I merged most of the three separate README files into a single one. I
also assumed that people trying to build OpenClonk from source have a
rough idea of how their build system works, so I removed the tutorial
from there. People who are completely new to this should consult the
wiki or ask on IRC.
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.
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.
Turns out changing prop list numbers while they are still indexed by number in the hash map was a bad idea. Existing prop lists are now de-numbered, pushed to an external shelve and re-numbered when added after section load.
We're implementing parts of <stdint.h> ourselves for old compilers, and
these macros aren't part of our compatibility interface.
Additionally, [C99 §7.18.2] (unfortunately, MSVC ignores this):
"226) C++ implementations should define these macros only when
__STDC_LIMIT_MACROS is defined before <stdint.h> is included.", which it
wasn't, so it wasn't portable in the first place.
Sven Eberhardt