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.
For now this will just crop the texture. In theory, we could try to
reduce the size in future, maybe by scaling the texture down? We'll
have to see what works best.
+ Refactored the ShakeFree, BlastFree, DigFree, DrawQuad etc. functions and
removed unused functions ClearRectDensity, DigFreeMaterial,...
+ Moved the polygon fill algorithm from StdSurface8.cpp to C4Landscape.cpp
+ Clearance functions which used to subtract a circle now subtract something
that looks more like a chunk
+ Pickaxe works with BlastFree now
+ Removed Dig2ObjectRequest
Using the walkaround mechanism we can now safely try whether the
driver has a problem with texture2DLod getting used in the
fragment shader. It might be against the standard, but I see no
reason why I shouldn't try - it did improve things for my old
driver.
They were actually caused by the scaler texture only rarely truly
reaching RGB(255,255,255), instead maxing out somewhere in the
RGB(248,252,248) region. This caused pixels that had only remote
contact with another material still taking over about 3% of the
material's texture. That was obviously most noticable for high-
contrast edges like Sky.
For now this tries to fix it in pre-processing of the scaler. Might
want to look into the scaler generation sooner or later though. Still
no idea where that color error came from.
Now using the best algorithms I could think of, meaning that quite
a lot of information is stashed into the scaler texture in order to:
1. Reliably find the "other" pixel to interpolate towards using the
scaler. The approximation used before would use invalid texture
coordinates when interpolating.
This now allows us to calculate the shading for this "other"
pixel as well, which actually caused even more visible artifacts.
2. Decide how to calculate the shader for the point rendered. In
case we are in the middle of a material, we want GL to interpolate
the normal so we get a nice smooth sub-pixel gradient. On the
edges, however, we would get interpolation between normals of
different materials, which looks ugly.
Now especially has a few debugging options that make it easier to
spot when texture coordinates are not calculated accurately. Use
DEBUG_SEPERATOR_TEXTURES to add nasty stripe textures that should
(in theory) never be visible. Set DEBUG_SOLID_COLOR_TEXTURES on top
of that to replace all materials with dark solid colors to make the
stripes more clearly visible.
Otherwise the addressing using floats will not be entirely exact,
maybe leading to some bad implementations trying to interpolate
between 3D texture layers. That would be a very hard-to-spot
performance hog, therefore let's play it safe in exchange for having
to allocate a bit more texture memory.
At least some site on the Internet claims that this is better. I
don't see a difference, but it's probably a bit less blurry, which
should be the right direction.
Implemented manually, as 3D textures didn't work here properly with
automatic mip-mapping ones. That's no loss, as we can easily swap out
the full texture set for each drawing call.
For example, deleting an object in an effect callback for that object would
delete the effect, causing some usage of freed memory. Instead, let the
effects get deleted together with the object in ~C4Object(), and only mark
them as dead in AssignRemoval.
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.
Previously, they were stored in the configuration and written to the
config file by default. So they still had the old .c4f file extension and
weren't displayed in the scenario selection dialog. Approximately nobody
changed this configuration, and those that do can simply use symlinks
instead.
Script functions using ... or Par() still take all 10
parameters, but those are the exceptions now. This makes
calling functions with few parameters faster.
Find_Or(Find_InRect(), Find_AtRect()) still needs to search the whole
object list, and Find_And(Find_InRect(), Find_AtRect()) simply uses one
of the two bounds to limit the search, though.
At the moment, the majority of hash tables has at most one element, so
allocating more is wasteful. There needs to be at least one unused bucket
in the table, so the initial size is 2.
Also, increase the maximum load factor to 3/4.
Integer and boolean constants aren't wrapped in a temporary C4Value. The
overflow check is reduced to one subtractions and comparison to a compile
time constant. C4Value::Set(const C4Value&) doesn't duplicate the check for
the setting to the same value in C4Value::Set(C4V_Data, C4V_Type).
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.
It has long since been replaced by the StdCompilerConfig* classes. A few
of the Registry functions are still used in other code, and a few are now
implementation details.
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.
The Melee rule is the interface to distinguish Melee- and Cooperative
scenarios for various purposes. Using a separate flag might be cleaner, but
would violate the do-not-repeat-yourself-rule.
C4Object::ObjectCommand was not updated for the C4Value-in-C4Command change
and still exposed the raw pointer values. Given that SetCommand works just
fine for "Call" commands, simply change the Tx parameter to int.
Particles were always drawn centered around their position, and the
"used because stup" comment explaining the use of C4TargetRect instead of
C4Rect is probably outdated.
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.
This is done with the new C4ValueNumbers class. Every array and proplist
with the exception of objects, definitions and effects gets a number
when the game is saved and is restored via that number on load.
Previously, the application would try to go into startup because the
editor was active, but then try to start a scenario because the startup
mode flag wasn't set. Check both the start flag and the editor flag in both
places.
Everything is more important than the next game tick: network activity,
user input or editor redraw.
On windows, the ordering is still delegated to (Msg)WaitForMultipleObjects.
Sven Eberhardt