A single player now receives four times more wave bounty than before, scaling up to four players. It's still challenging but I believe now doable.
Enemies should no longer jump off airships when being shot at.
Fixed a typo in the airship appendto script.
Fixed a possible null pointer when changing weapons.
This would crash for me when starting a game in developer's mode. Not sure if this is the best place for the fix. Maybe there is some other underlying issue. ck?
The player interface is now similar to how picking up works. This should increase acceptance. Also it was pretty fucked up before. The action bar is gone.
The script logic is now outsourced into a new library similar to the other stuff.
Objects can overload the selector for the new interaction (see "call elevator case").
Additional issues hit and resolved when working on this:
Shifting a cursor did not cancel certain actions (and there was no callback for that). This is now solved by adding two new callbacks.
Issues hit and not resolved:
Certain interactions (calling an elevator case, flipping a construction) are in some control library. They should be in the respective objects (and shown via callbacks etc.). Meh.
The internal interface (declaring interactions etc) has a few places where proplists are just translated because the properties are called differently. This is also a fuckup (i.e. a.interaction_object = b.Object) where the properties should just have been called the same in all places from the beginning.
The name "Action Bar" is pretty misleading now as it is no bar. But that's not something visible to the players. todo: cleanup.
Search less often. Search for less. And use the proper inventory interface.
Before (first number is relative to MovingBrick.FxMoveVerticalTimer, because that's relatively constant (I guess?)).
59x 00826ms Global.FxBlessTheKingTimer
38x 00537ms Global.FxDeathByFireTimer
1x 00014ms MovingBrick.FxMoveVerticalTimer
After
41x 00328ms Global.FxBlessTheKingTimer
27x 00213ms Global.FxDeathByFireTimer
1x 00008ms MovingBrick.FxMoveVerticalTimer
In doing so, refactor the way C4FoWDrawStrategy works slightly. Get rid of
immediate mode OpenGL, and instead populate a vertex array and an index array
as vertices are added to the draw strategy. Then render everything as
triangles.
The actual rendering is then performed in C4DrawStrategy::End(). It passes
the accumulated vertices to the GL. Also get rid of the notion of multiple
passes in C4DrawStrategy. Instead, C4DrawStrategy::End() can simply just draw
the bunch of vertices multiple times. This allows us to do the vertex
generation and GPU upload only once, instead of repeating it for every pass.
This allows the strategy to keep some state between invocations. I want to
use this in order to store a VBO in the draw strategy, and to avoid having
to re-create the VBO for every rendering.
We are already using VBOs for meshes, so we can rely on them being available.
VBOs are shared between contexts, so #1195 is not an issue, either. However,
keep the workaround in place for the VAO, which is not shared between
contexts.
I don't expect much of a performance benefit from this, but it works toward
removal of legacy OpenGL usage. Note that we are already using VBOs for
meshes, so this does not require any functionality that we don't require
already.
The error rarely happened when the clonk was attached to a wall solely with its head vertex. CheckScaleTop (Animations.ocd/Script.c) only checked the shoulders and hip vertices.
I also made sure that this.dist (FxIntScaleTimer, line 616) cannot exceed the animation length of "ScaleTop" although that shouldn't have posed a problem.
Changing the mesh material to something that does not use alpha blending
restores the originial face order. This caused a crash for meshes with
Completion below 1, since all original faces were copied, but the buffer
in the mesh instance was only large enough to hold the number of faces of
the incompleted mesh. To fix this, simply run the standard
select-faces-for-a-given-completion-value procedure.
This probably enlarges the maximum landscape height for borderbound objects.
The "infinity" constant +1000000 is larger than the biggest C4Fixed, so
would have been truncated to 16960.
The DynamiteBox sets the PictureTransformation to a degenerate matrix, to
prevent it from being rendered. Exit early in this case, since we are not
going to render anything anyway, and avoid the assertion when inverting the
matrix.
I think C4Game::InitKeyboard relies on the callback targets outliving the
keybindings and every other class is prepared to be deleted before
C4KeyboardInput::Clear(), so needs to hold a ref to the keybinding to
delete that in its destructor.
C4KeyBinding is the class that is used for that, and it sets the reference
count to 1 in the constructor, to represent the reference held in the
owning class.
On the other hand, C4CustomKey gets immediately forgotten by C4Game and the
only reference is held in the keymap.
To prevent this from happening again, make the C4CustomKey constructors
protected and C4Game a friend of the class.
Also remove an unused C4CustomKey constructor.
Replace the hardcoded VAI_ constants with that. The VAI constants are now
moved to C4DrawGL as C4SSA_ constants, similar to the C4SSU ones. This allows
to introduce other attributes to replace vertex positions, normals, colors
and texture coordinates with attributes in later commits. This, in turn, is
needed because the built-in attributes are no longer available in the OpenGL
core profile.
Also, while at it, cleanup C4Shader a bit. Use std::vector<> instead of
maintaining an own array of uniform names. Delete the vertex and fragment
objects after the full shader program has been linked. Make sure that
C4Shader::Init keeps the old program in place if the new one cannot be
compiled or linked.
Surfaces are initially created in locked state, and only when unlocked the
memory buffer with the surface data is uploaded to the GPU. The FoW code
however never unlocks the surface but instead operates on the OpenGL texture
directly. To fix this, introduce a new flag for C4Surface to create it in an
unlocked state.
This is not a memory leak in the traditional sense as a pointer to the buffer
is still available and is being freed when the surface is being destructed
at the end of the game. However, during the game there might be several
megabytes allocated that are never used.
I'm not really sold by this Lock/Unlock mechanism. Instead, there should
simply be a function to obtain the current texture data, and a function to
upload new texture data. That's for another time though...
For some reason, the C4TexRef constructor first uploaded a set of nulled
texture data, just to be replaced by the actual image data when Unlock()
is called. Skip the unnecessary step and instead just reserve the video
memory in the constructor.
Removed the windbag from the chest (might also remove it from the buy menu).
The chest below the base will now sometimes contain a gold bar, giving extra money to the player picking it up.
Made sure that no airship remains after fade out.
Armin Burgmeier