Turns out we actually can't optimise out the second texture normal
lookup - it makes a noticeable difference in-game. Also there was
possible slice collision, it might be worth warning about this kind
of stuff.
Also removed unused variable, and made error messages more consistent
in terms of whitespace.
The idea here is that we compose shaders out of "slices", which can
come from the engine ("built-in"), from files or possibly even from
models. This should allow us to more easily share the code between
different rendering shaders (e.g. for lights / normals).
TODO: Workarounds not yet implemented, so this might degrade less
gracefully.
This introduces a new texture, an ambient light map, that is generated
automatically at the beginning of the round by the sky portion of the
landscape. This basically makes everything that is close to sky visible
by default.
The shaders have been adapted so that they deploy direction-independent
lighting for the ambient component, and the current (diffuse) behaviour
for the diffuse component. This makes the shaders use an additional
texture unit that represents the ambient light. We can think about merging
this information into the light texture, but the coordinate systems are
different at the moment, so this could be performed at the stage of light
texture generation.
For meshes, the ambient material is not actually used, but instead a
diffuse light from the front is used. This makes many meshes look more
interesting, maybe also because the ambient material setting of most
meshes are not set correctly at the moment.
* added some class and method documentation, removed some superfluous comments like
void C4FoW::Update(C4Rect r)
{
// Update all lights
...
* added ASK comments that need clarification before proper documentation
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.
Direct3D hasn't worked for more than a year now, and there don't seem to
be any efforts to revive it. Remove it and concentrate on better OpenGL
support.
The LandscapeRender Init() proc loads graphics from the main graphics group, which is already closed when a section is loaded. So just keep the renderer around on landscape recreation now.
Also set default to 8. This might be a pretty controversial change, but
the amounts of screenshots we have at zoom levels beyond 4 just calls for
a more high-res approach.
Pretty awkward compromise, but the array version seems to confuse a lot of
drivers, without causing an actual error. So this is probably better in
practice until better drivers are more common.
Also set default to 8. This might be a pretty controversial change, but
the amounts of screenshots we have at zoom levels beyond 4 just calls for
a more high-res approach.
Pretty awkward compromise, but the array version seems to confuse a lot of
drivers, without causing an actual error. So this is probably better in
practice until better drivers are more common.
- The light direction change isn't really consistent, as I can only give
GL the vectors at the triangle edges. So for deep rays, the light
distribution often ends up being significantly different than for short
rays.
- I *am* distorting the normal map vectors, quite badly actually. I'll leave
it for the moment, because it definetely looks best for the light vectors,
but I will have to correct that a bit once I have the time.
Some compilers are less strict about this than others, unfortunately.
The Gallium one complains with
preprocessor error: Macro names starting with "GL_" are reserved.
beliar reports that his driver doesn't support the number of fragment shader
uniforms that we're using in the landscape scaler. By making the reported limit
available to the GLSL code, it can use a workaround using a 1D texture to
transfer data.