Just for sanity's sake. This just displays a Warning without modifying the dockpoint name. I considered an nprintf but figured a Warning was more appropriate.
Having recalled that other SCP folks stated pow shoud not be used to do simple squaring, I figured it might be a good idea to update the two instances I found where that was the case.
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
The (length > base_length) conditional was redundant with the other conditions. Additionally, the code from the ID_FUEL case (thruster points) checking for "$engine_subsystem=" was making the exact same mistake, so I made the same changes there.
In a Release build, there was absolutely no code making sure that the text "$glow_texture=" was actually present in the properties field of a glow point bank, beyond a simple strlen() check. Even in Debug builds, there was no guarantee that the text was at the start of the properties field; it was just assumed (without even an assertion verifying it). Now, the assertions have been removed and the appropriate conditions are checked in both Release and Debug.
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 will make the error message clearer instead of just showing a
cryptic Assert message. This cannot be handled by a simple warning since
capping num_debris_objects to MAX_DEBRIS_OBJECTS would then cause issues
when reading the rest of the header.
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.
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 makes it easier to determine what takes the most time while loading
the mission (loading models) and how we could optimize that load time
(optimize model loading).
This is not a bug fix but it also shouldn't cause any regressions since
there are no actual code changes so this could be merged before the
release of 3.8.
These checks were from a time when we supported lower OpenGL version
than 3.2. Since we don't do that anymore and show an error if the
drivers don't support that, these conditions always evaluated to true
and could be removed.
asarium