The old LineFeed constant caused problems with Qt. Using \n directly is
easier and I don't think there's a reason left to use \r\n anyways.
We've always converted the files in the repository. Nowadays, even
notepad.exe works with unix file endings.
A follow-up on a previous PR GH-41. The discussion in the forum can be
viewed at http://forum.openclonk.org/topic_show.pl?pid=33086.
Run clang-tidy (without auto, pass-by-value and using checks) to fix the
header files not modified in the previous PR.
Summary of the changes:
- C++11 member initialization.
- nullptr instead of 0 for pointers.
- override for functions declared virtual in base class.
- default trivial special member functions
Consolidate the include statements scattered across the code in accordance
with the comment in C4Include.h. The advantages are listed in the same
comment.
Furthermore, it follows llvm-include-order which is the logical
extrapolation of the project's style guideline wherever possible
(C4Include.h being the most-frequent exception).
Previously, it would just use first pixel of the texture image. With our
current textures, this is a pretty bad approximation. For example,
firestone ends up yellow rather than red.
Additionally, this helps tools like mape/ocmapgen which do not load any
texture graphics but just set the texture's average color.
This also fixes the sky color which was previously overwritten.
* Renamed from material shapes to textures shapes
* No per-texture, so the same material can use different shapes with different textures
* Load a shape image instead of text file with vector components
* Allow texture sizes that are not multiple of the map zoom
* Add minimum overlap parameter to draw shapes only when the given overlap is reached.
Instead of one draw call for each tile, do the whole operation with a single
draw call by setting GL_REPEAT on the texture. This affects sky, the upper
board and the background.
This also allows to remove some code that was making sure surfaces are big
enough.
The Default call from C4Game is issued before construction of all members, which causes a memory leak when TextureMap is actually constructed.
Just merge Default() into Clear(). The separation into two calls serves no other purpose than putting the class into an inconsistent state between them.
It actually does that in almost all other subclasses as well but they don't allocate memory.
This should simplify insertion of new textures at arbitrary drawing orders without reassigning palette indices (the latter would invalidate all old maps).
The new behaviour that allows 255 mat-tex combinations (once we increased
C4M_MaxTexCount...) is enabled with MapFg.bmp, and then MapBg.bmp can be
used to draw IFT or other fancy things.
This makes sure texmap entries look correct, thus avoiding a crash that
happened when the entry referenced a material without specifying a
texture.
Closes#1060.
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.
- 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.
This mostly simplifies things, since most other places use an 32 bit
integer to store colors, but might even improve performance through better
cache locality.
Lukas Werling