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.