* Engine will now use it to render terrain
* Added directional light source
* Added dynamic shadows
* Moved visibility computation to CEngine
* Removed uniform buffers
Fix mistakes after previous merge and make it compile.
Rewrite the function interpolating between time stamps as it was
written after the original pull request was created. Add unit tests
for it.
I couldn't help myself and also changed some enums to enum classes and
did some renames.
The issue is that the \button fragments in SatCom are replaced with
invalid UTF-8 bytes, hence those bytes need to be handled as a special
case when checking for UTF-8 character length.
When the text is processed e.g. in `Gfx::CText::Justify`, there are
generally two arrays: `text` and `format`. The second one is interpreted
as a font for a given character, e.g. `text[i]` has font `format[i]`.
Now, in the loops the index for `text` is increased by the length of
the character, e.g. 1 to 4 bytes, whereas index for `format` is
only incremented. It seems there's an assumption that `format` treats
multibyte characters as one byte, which doesn't seem to be true by
looking at the process of filling up the `format` array. This can result
in using wrong font e.g. FONT_SATCOM for the \button character which
should be FONT_BUTTON, hence the `StrUtils::Utf8CharSizeAt` method
complains about unexpected continuation byte via exception, causing
the crash.
Incrementing the index by the UTF-8 length seems to have fixed the
issue. However, I am not sure if I haven't broken anything else by this
and if I analyzed the intended behaviour correctly.
Gfx::CText needs a major refactor IMHO.
Signed-off-by: suve <veg@svgames.pl>
Jeff's patch was written for the 0.1.12 stable release.
Adapted to work with the "dev" branch (as of commit 13098ee).
This fixes the issue with objects and terrain being darker than they should be. As it turns out, most levels have not normalized light direction which happens to make light brighter and this is the expected result. To keep in line with GL14 engine, newer engines should use the length of the vector to make light brighter.
Moved list of mods logic to a new CModManager class.
The list of enabled mods is now managed by a flag instead of directory
names of mods.
Mods are now disabled by default.
Also general cleanup, fixing issues from the code review in
https://github.com/colobot/colobot/pull/1191 and fixing linter issues.
Regression: the state of enabled/disabled mods is now not persistent.
The plan is to use some kind of config file for this.
F12 is used by Visual Studio debugger to trigger a breakpoint and apparently it cannot be changed:
"The F12 key is reserved for use by the debugger at all times, so it should not be registered as a hot key. Even when you are not debugging an application, F12 is reserved in case a kernel-mode debugger or a just-in-time debugger is resident."
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/ms646309.aspx?f=255&MSPPError=-2147217396
It's unused, and it's a bad idea - it's important for authoring tools
and for performance that vertex formats are well-defined instead of
dynamically created.
When rendering the shadow map offscreen using framebuffer objects, it's
not necessary to create a color renderbuffer. Currently
FramebufferParams only lets you choose between a renderbuffer and a
texture for both color and depth attachments. This changes that, and now
you can ask for a texture, a renderbuffer, or nothing.
This improves performance. On my computer, with an 8192x8192 shadow map,
this improves overall frame time by 8.0%.
Shadow shimmering is a visual artefact where the outlines of shadow
mapped objects don't stay stable when the camera is moved or rotated.
The reason is that as the shadow map's origin moves, the objects
rendered to the shadow map have temporal aliasing around their edges.
The solution is to only move the shadow map in texel-sized increments.
Because the shadow map's projection is orthographic, moving the shadow
map origin in texel increments ensures that objects that aren't moving
don't show any temporal aliasing, as the position of the samples of the
object in worldspace stay the same.
If CONFIG_QUALITY_SHADOWS is defined (which it always is) then the
fragment shader code that samples the shadow map will take five samples
in a cross shape around the point to be sampled, to apply antialiasing.
Currently, the offset of these samples is hardcoded to 0.00025× the
shadow map resolution. This is very inconsistent: if the shadow map
resolution is 128×128, then these samples are 0.032 texels apart, which
is a waste of four texture samples, and essentially means that no
antialiasing is applied. If the shadow map resolution is 8192×8192, then
these samples are 2.048 texels apart, which causes visual artefacts
around shadow edges, instead of giving smoother shadows.
The correct thing to do is to always sample exactly one texel away from
the original position. This is easy in GLSL 3.30, as it includes a
textureOffset function which offsets a texture fetch by an exact number
of texels. This is faster than manually calculating an offset ourselves,
it fixes visual artefacts at high resolutions, and it properly applies
antialiasing at low resolutions.
Tomasz Kapuściński
immibis