Otherwise the default pack alignment is 4, and when the horizontal window dimension
is not a multiple of 4, glReadPixels() would read past the end of the buffer we
provided.
Otherwise, we would partly write files with uninitialized data, such as the
padding bytes in a BMP, or the palette if not specified explicitly. This
mostly fixes corresponding valgrind warnings, but also makes sure we obtain
the same BMP files everytime we store the same StdSurface8 object, bit-by-bit.
Otherwise, ResolveAutoParameter() does not set the correct parameter type, and
the code would try to set a sampler2D parameter as a float4. It does not matter
in principle since the shader would not use the texture anyway, but it
generates a GL error that is avoid this way.
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.
This was not working anymore correctly, since it now operated on unzoomed
coordinates. This could have been worked around by only applying it in the
unzoomed case, however I don't think the code is actually used much anymore.
In other cases of the rendering code, such as the mesh rendering, manual
clipping was never implemented and this did not seem to cause any problems.
Therefore, it can probably be removed safely.
This makes blits with overlays to actually use a single pass only, and
applies the GLSL shader also to standard object blits, which might come
handy when the lighting calculations in the lights branch are applied
on sprite objects.
It also removes the last user of C4Draw::PerformBlt, which will be removed
in a subsequent commit.
The support is not yet fully implemented; there are some transformations
missing. However, since the FoW support at the moment seems to be broken
(#1168) this feature cannot be tested properly.
This might break some scenarios which for example change the color modulation
of a clonk and then expect that also its shovel or other objects get colored.
Such scenarios need to be fixed by also coloring the attached objects. This
might not be very convenient, and maybe we should introduce an option for
attached meshes to use the old behaviour (take blit parameters from main
object).
However, let's see how this change turns out in practise and then we see
whether further modifications are needed.
This replaces the fragile ShaderRef construction in StdMeshMaterialPass, and
it allows to re-use shaders and/or programs between different materials. This
is some more preparatory work for custom shaders.
C4Group::Open would sometimes overwrite more specific error messages or
not mention the problematic path. DirectoryIterator::Read also now mentions
more detail. Two superfluous messages were removed to make space.
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.
4e875f4 didn't quite catch all instances of C4BltTransfor::SetRotate
being called, and silent conversion from int to float meant that those
rotations were incorrect by a factor of 100.
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.
ResTable (the main system string table) was a home-grown hashmap that
did not cope with collisions at all. Since we already have a proper
dictionary in C4LangStringTable, use that instead.
Rotation was still stored as an integer and as a fixed point number.
Compute the integer on demand from the fixed point instead, like the
position. Rewrite the movement code where the two variables were
temporarily out of sync.
Armin Burgmeier