This allows compiling and linking with it without pulling in whole
C4Game. This is useful for the mape map editor.
The only place where C4Game was used in C4Material.cpp was in
CrossMapMaterials where the name of the earth material is read from
Game.C4S. The code has been changed such that the earth material name is
now a parameter to the CrossMaterialMap function.
Technically this mark is incorrect; we do not handle things differently
on high DPI settings. On the other hand, marking OC DPI aware means that
Windows won't try to scale our drawing, clipping menus and rendering in
the process.
Somewhere in the future, OpenClonk should also add proper DPI awareness
and change the default zoom and menu scaling to match.
Right behind the other debug display modes - so it's
4 x Ctrl-F7 in debug mode now. Not sure it will become useful,
but it's sort of pretty, so why not.
- 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 makes Application.GetConfigWidth/Height simply return the appropriate
configuration value instead of mixing configuration and state in the same
function. The caller needing the state now uses C4Window::GetSize instead.
This avoids a previous assert() on player elimination from GetFunc()
being unable to handle the tilde in "~OnOwnerRemoved". FnOnOwnerRemoved
is gone so that shouldn't happen anymore.
This was partly broken by 427cf61d729a. However, already before that,
the size of the overlay was depending on the ingame size of the object
on whose picture the overlay was being drawn. This didn't make much sense
and now the size of the overlay is equal to the area on which the picture is
drawn in the first place.
Instead of having custom code drawing the picture in C4DefGraphics.cpp,
re-use C4Def::Draw().
This changeset changes the coordinate system on which draw transformations
are applied to sprite picture overlays. The transformation is no longer
applied in the frame of the overlay picture but in the frame of the object on
which the overlay is drawn. This was already the case before for mesh
graphics, so this change unifies the interpretation of draw transformations
for sprite and mesh graphics.
The Tools Workshop has been changed accordingly so that object is production
are properly displayed on the sign. This also fixes the pictures of some
objects being off the sign.
This requires replacing C4AulScript::Def with C4AulScript::GetPropList() and
C4DefScriptHost::Def, and making C4GameScriptHost::GetPropList return the
scenario proplist prototype.
Definition calls won't be able to change the local variables, of course.
Other proplists will be able to use local variables once they can have
functions.
So actually be29346165d6 turned out to be an incorrect fix. The actual
problem is much more subtle: the ordering of objects within the same
plane by their ID could cause the sector list order to not match the
main list order anymore. This has been fixed by re-arranging the code in
question.
I hope this really fixes#711.
Instead just attempt to load the filename given. This function is only
used from two places: C4Game::InitDefs and C4Game::DropFile. In both
cases segments and wildcard matching is neither needed nor desired.
This fixes a problem with loading definitions when the Clonk installation
resides in a directory with paretheses, such as C:\Program Files (x86)\.
This might well fix the problem in http://forum.openclonk.org/topic_show.pl?tid=905.
This means that if the Clonk digs Earth but has a full inventory at the time
(so we can't generate Earth chunks), digging another material later can never
yield more than one Earth chunk.
The behavior is still not perfect yet since the attachment of the object
to the SolidMask may re-position the object by 1 pixel. I am not sure
this can be solved correctly since there are three coordinates involved
who can be (and, generally, are) different on a sub-pixel level. These
are the object's position itself the position of the solidmask object
and the position of the solidmask (which is constrained to pixel boundaries).
However, the attachment code only knows the object and the solidmask, not
the solidmask object, so it possibly cannot properly account for this.
The NoNil variant thus has the shorter name, because most code should
use it. Conversion checks mostly secure code that uses the value and would
crash with a nullpointer. The exception are function parameters, which all
also accept nil and 0 and check for nullpointers in the function itself.
Scenarios are now loaded with the same flags they were saved with. Thus,
the objectlist is told to skip player objects while loading. But this can
be safely ignored, because the scenario shouldn't contain any player
objects that could be ignored in the first place. But checking that loading
and saving is done with the same flag would be nice.
Previously, smooth materials would get extra triangles at the top to create
slopes instead of steps. Now those also appear at the bottom.
Smooth also gets generally smoother at the bottom, while Rough gets rougher
at the top. The new Smoother material is somewhere between Flat and Smooth.
Octagon is like Flat but also gets straight slope triangles.
In OC, actually every material has its predefined set of textures, so the default texturing of >=CR is obsolete. The "Smooth" texture is a relic of that which is currently only used because of the "Vehicle" material.
This makes it easier to stay in sync to the TexMap, especially if
using an animated texture. I only changed it for Water, but I
think it would make sense for just about every material.
Actually more chatty than ever before, logging exactly what its
internal configuration was, together with some statistics. I feel
we might need them once we release.
Also we now test all *combinations* of workarounds.
The idea is that for some materials (e.g. earth chunks) it really
doesn't make sense to not immediately collect them - they would just
collide with something and recreate the material you just dug out.
So instead, this allows materials to specify that they want their
dug out objects to be collected immediately - if not, they simply
don't get created.
Note that this doesn't mean that material is lost, as it will simply
acumulate in the digger's material list instead. We might want to
cap that at some point though.
Just noise, as the previous liquid shader by Günther. It's quite
hard to find the right compromise between making it too subtle and
starting to get a "blinking" look. This is now three phases at
300ms each.
Use by having texmap entries of the form "Mat-Tex1-Tex2-...". Right
now the speed is hard-coded to one phase per second.
The general idea is that the 3D texture contains all texture
transitions somewhere in the form of two textures with neighbouring
3D coordinates. There's some room for optimization here, of which
the code exploits some. Being smart can be arbitrarily hard actually.
+ CustomMessage now uses a normal picture of a definition/object
+ BigIcon is now the small (and only) "Portrait" the player chan choose
+ In future, one could of course make the max size of the BigIcon bigger
Having the calculation in CPU actually allows us to perform more
clever checks. If we have three materials meeting at one point,
we can select one material and make sure that all others pick a
case that's at least consistent to the edge of that material. This
obviously means that the edges between the remaining materials
won't be scaled properly (essentially falling back to GPU scaling),
but that's less disruptive to the result than having the decisions
of neighbouring pixels in disagreement.
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.
For example, deleting an object in an effect callback for that object would
delete the effect, causing some usage of freed memory. Instead, let the
effects get deleted together with the object in ~C4Object(), and only mark
them as dead in AssignRemoval.
Find_Or(Find_InRect(), Find_AtRect()) still needs to search the whole
object list, and Find_And(Find_InRect(), Find_AtRect()) simply uses one
of the two bounds to limit the search, though.
The Melee rule is the interface to distinguish Melee- and Cooperative
scenarios for various purposes. Using a separate flag might be cleaner, but
would violate the do-not-repeat-yourself-rule.
C4Object::ObjectCommand was not updated for the C4Value-in-C4Command change
and still exposed the raw pointer values. Given that SetCommand works just
fine for "Call" commands, simply change the Tx parameter to int.
Particles were always drawn centered around their position, and the
"used because stup" comment explaining the use of C4TargetRect instead of
C4Rect is probably outdated.
Instead, retrieve the number on demand during serialization. This saves
lots of unnecessary code and makes serialization actually not modify the
objects. At least with the exception of nInfo, but that should be save.
This is done with the new C4ValueNumbers class. Every array and proplist
with the exception of objects, definitions and effects gets a number
when the game is saved and is restored via that number on load.
Julius Michaelis