Previously, the calculation thread was initialized before the event it was
going to wait for after it is launched. However, since the thread starts its
execution in its constructor, it might access the event before the event
itself has been constructed.
This is fixed by making sure the event is fully constructed before the thread
is constructed (and launched).
This code is only used for the low-resolution landscape that is hardly in use
anymore. The code was mostly a duplicate of the standard C4Surface blit
function, CStdGL::PerformBlt, with some added code for blitting material
textures with higher resolution. However, that code was not enabled anymore
by the classic landscape renderer either, so it seems safe to remove it.
The landscape is now simply drawn by C4Draw::Blit.
Solid/Liquid/Background depend on PixMaps in C4Landscape being updated to currently loaded materials.
PixMaps should really be functions of C4MaterialMap and C4TextureMap. It's probably still broken in mape.
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.
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.
<Sven2> Your fix of the parent check for points in the landscape.txt parser. if (!(pToNode->Type() == MCN_Overlay))
<Sven2> It should also allow the poly algo in maps
<Sven2> i.e., make it if (!(pToNode->Type() == MCN_Overlay) && !(pToNode->Type() == MCN_Map))
<Sven2> Actually, better make it if (!pToNode->Overlay())
If an object moves and other objects are attached to its SolidMask, only objects in front of this plane are moved along with it. Defaults to Plane if zero.
This makes sure texmap entries look correct, thus avoiding a crash that
happened when the entry referenced a material without specifying a
texture.
Closes#1060.
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.
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.
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.
The warning is nothing that should bother the average player (mainly because they possibly can't do anything against it anyway). However, it might turn out to be useful for debugging purposes.