This system adds the code necessary for letting content creators specify
complex events by specifying a simple, program-like sequence of
operations that will be executed by the engine when a certain event is
triggered.
Since instance-specific fields have been moved to polymodel_instance and submodel_instance, the gun_submodel_rotation field should also be moved. This is also reworked a bit to keeping track of the rotation via the normal submodel instance angles.
This removes an unnecessary look_at field as well.
Retail has a hud_find_target_distance function that returns the distance between the player position and a bounding box. This is useful for the HUD because it shows the distance to the perimeter of an object like a jump node or a large ship. However, this function was re-used for the `distance` SEXP, resulting in the awkward situation where the distance is measured from one ship's center to another ship's bounding box. This can lead to unexpected results and it also means that the SEXP returns a different distance when the arguments are swapped.
This PR deprecates the original SEXP and introduces the new SEXPs `center-distance` and `bbox-distance` which use consistent methods for both ships. It also renames the `distance-ship-subystem` SEXP to `center-distance-subsystem` and adds a new `bbox-distance-subsystem` SEXP.
Add a submodel property that overrides the hard-coded distance
multipliers applied to the distances at which details boxes & spheres
are rendered. The distance multipliers are set by the "model detail"
setting in the options screen. Note that this is different to the LOD
distance multipliers which are not hard-coded.
This allows some more creative uses of detail boxes & spheres, e.g. to
stop models subobjects from being rendered when they're out of player
view. Past testing showed a reasonable performance improvement with
complicated models.
This is a submodel property rather than global, or a ship flag, to allow
flexibility, i.e. a single model could choose this option only for the
submodels that want to use detail boxes/spheres in this fashion, which
other detail boxes/spheres use the conventional approach.
Code & ideas originally from zookeeper, I've just packaged it up for
the PR.
This has been rebased & squashed based on feedback in the PR
This maintains the type information which can be used for enforce
const-correctness and also for implementing more advanced ways of
handling the type information.
This adds a new class which allows to create type safe resource handle
types. At the moment, the engine uses ints pretty much everywhere for
providing handles to resources created by the specific subsystems. Since
all ints are the same to the C/C++ typesystem it is perfectly legal to
pass a sound handle to the graphics API as a buffer handle which will
obviously cause issues.
This adds a new type called "ID" which is a wrapper class for a generic
handle but with added type safety. An instance of this class cannot be
passed to a function expecting another type of handle which provided
compile-time type safety for these APIs.
As an initial test I converted the game sound handles to this new type.
I already found a bug in the mainhall system thanks to this new type.
The mainhall used the game sound handles as sound instance handles which
probably meant that that specific code never really worked right. I
removed the code since there was no better alternative for fixing it.
There were actually multiple issues here. The addition of color mask and
stencil state to the material system overwrote the state set by the
hardpoint renderer so the stencil buffer was never written or read
correctly. I fixed this by introducing three new model render flags
(there were a few open slots in the bit mask so I used those) which set
the correct state using the material system. That also makes setting up
the rendering environment much easier.
Second, gr_opengl_stencil_set used mixed up parameter values which were
probably broken when I introduced more detailed stencil state tracking.
I restored those values to how they were in 3.8.
This fixes the other issue reported in #1640.
This changes the model loading code such that all index and vertex data
is packed in a single GPU buffer for each data type (index and vertex
data are still in separate buffers). This reduces the amount of buffer
rebinding needed when rendering a scene which will reduce the CPU
overhead. Furthermore, this opens up possibilities of future
improvements for which it is beneficial if all data is in the same
buffer (e.g. MultiDrawIndirect rendering).
To manage where to put the data in the GPU buffer I implemented a
custom HeapAllocator which manages where data can be put. It uses a very
primitive first-fit algorithm but that is sufficient for this usage
type. This does add quite a lot of overhead while allocating GPU model
data (I did some tracing and some allocation calls took as long as
130ms).
This fixes#1457.
This is a renaming of the Dumb_rotation infrastructure, which is now called Intrinsic_rotation. Intrinsic rotations are automatically applied to submodels without the need for an associated subsystem. Dumb rotations are now a type of intrinsic rotation, and look_at rotations will be added in a future PR. The same code will handle both; the only difference is in how the intrinsic rotation is calculated. (In the case of dumb-rotation, it is calculated the same way as normal rotation; in the case of look-at, it will be calculated using submodel_look_at.)
asarium