This is required for truetype fonts, otherwise it crashes during font
loading. It still wastes a good bit of memory however and will need
to be addressed with a more permanent solution in the future.
So #3007 is a larger bug than just trying to access the player's target. The real problem is that the game state is not changed from `GS_STATE_GAME_PLAY` during the mission load when restarting the mission. So the script thinks it's in the mission, tries to access the target and then crashes. But this won't be the only bug. Any script that tries to access data on Frame will run into possible problems on mission restart.
Since that function already has full support for UV scaling it makes
sense to unify the behavior in one function instead of having a separate
monochrome function that does weird things.
Also deprecates that function since all its use cases are now covered by
drawImage.
This will make it easier to have a graphics interface without relying on
global objects since the object can be kept alive in the function
object. No other functional changes since the existing syntax is also
valid for function objects.
This adds the Vulkan code for choosing a physical device, creating a
logical device from that and then initializing a swap chain.
This also contains code for filling out the graphics API pointers with
stub functions so that the API functions can be developed gradually.
These changes allow FSO to "run" with Vulkan but nothing is rendered
yet.
This can be used for producing even leaner builds for standalone
servers. It also provides a nice architecture verification since now
using internal OpenGL functions will cause a compilation or linking
failure.
Standalones would crash if they had an error dialog pop up because of a nullptr. This just checks for the nullptr and returns early to prevent the crash.
This adds a mechanism for running generic operations at specific points
of the frame execution. This can be used by any part of the code an not
just Lua since it simply executes std::functions. It also adds an
"execution context" concept that specifies in which situation an
operation should be executed.
This is then used by the Lua Coroutines code for resuming coroutines at
specific points instead of always when the awaited promise resolves.
This can be used by Lua code to trace the runtime of their code in the
same way the engine already is capable of doing for most in-mission and
mission loading code.
Also adds some tracing scopes to the libRocket code
This moves towards defining the hooks in the code module that executes
them. Also provides the API necessary for better documentation of hooks.
This only covers a few hooks as a test and demonstration of the new API.
If no issues are found with this it can be extended in the future.
This adds a new graphics type for the Vulkan graphics API. All this does
is to create a vulkan instance and a presentation surface with the help
of SDL.
The largest new feature is that it is now possible to include other
files into the RML by using the "include" tag. This is useful for making
markup files more modular.
Also added some more options for existing things (e.g. built-in detail
options).
This elimiates all of the remaining "old style" uniforms from our
shaders. This might not be optimal for all situations but I have
confirmed that it is at least not worse at the moment.
This is a generic way to get matrix data to shaders without using
(old-school) uniforms. This is another step towards more compatibility
with how new APIs (Vulkan) do things to increase the odds for a Vulkan
port at some point.
Three main changes in this PR:
1) The enums for the "easy settings" launcher options are now clearer and more explicit, and the enum assignments for a lot of graphics options are now fixed, as they were incorrect due to code rot.
2) Some of the command-line flags options have been recategorized: -window, -fullscreen_window, -nomotiondebris and -noscalevid are now Gameplay; and -fps is now HUD.
3) Since post-processing is required for nebula fading, it now defaults to on, and the flag has been changed to -no_post_process.
Persistent buffer mapping is an OpenGL technique where the contents of a
buffer object are mapped to a persistent pointer instead of having to
map and unmap a buffer every time it is modified.
This decreases the overhead for updating data in a uniform buffer object
which now only consists of a memcpy and a flush call.
This is in preparation for using persistently mapped buffers for uniform
buffers. Since that functionality is not available in the OpenGL version
we are targetting I implemented a fall-back which simply uses
glBufferSubData.
I did a benchmark with these changes and there was no change in
performance to the current master version.
This is a system for storing arbitrary data in the config file and then
easily retrieving it later on. This has full Lua support for exposing
the available options in a custom UI and changing the values of the
options. This ported some of the existing command line options over to
the new system which is opt-in for the moment by using a mod_table flag.
I added this hack a long time ago and it always bothered me why I didn't
come up with a better solution. This is the better solution which uses
the popup_active function for determining if gr_flip is called within a
popup.
This is mostly intended for total conversions to allow them to set
themselves apart from FS2 based mods. It uses the new in-memory
filesystem to support a default icon in case no icon was specified by
the mod.
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.
One of the main points of contention when adding the NanoVG based
TrueType text rendering was that it required an external Opengl
renderer which may interfere with our rendering engine by changing
OpenGL state without telling the rest of the engine. Since the rendering
interface for NanoVG is abstract and can be easily replaced, I did just
that and replaced it with an implementation that uses only generic
graphics functions without relying on the specific graphics API.
This will improve the interoperability of NanoVG with our engine and
should make later changes to the rendering engine easier since there is
no external rendering code which may interfere with our own code.
The original OpenGL Core changes only used a single vertex array object
for specifying the data layout of our vertex data. This uses the OpenGL
extension GL_ARB_vertex_attrib_binding to extend that so that each
vertex_layout uses a separate vertex array object which should improve
performance by reducing the CPU overhead while switching the vertex
layout. Since we need to use offsets into the vertex buffers at some
points this can not be done with the core functions since those do not
support specifying an offset when binding a vertex buffer.
GL_ARB_vertex_attrib_binding does support that and also features an
improved API for specifying the vertex layout. If that extension is not
available then the rendering engine will fall back to the current code.
In CPU intensive scenes I observed a frametime improvement of 1-2 ms.
This uses UBOs for building a buffer object of uniform data before
using that data to draw objects. This should reduce the CPU overhead by
reducing the amount of glUniform calls required for executing a single
draw call. This is especially useful if rendering is limited by the CPU
which should help performance for people with slower CPUs.
This fixes#910.
There is nothing specific to OpenGL in that code anymore since it's all
handled in the shaders at this point. This will make the lighting
information available in the normal graphics code which allows to use
those values when filling the uniform buffer for the model rendering.
All transformations are now handled by shaders so there is nothing
special going on in the graphics API specific code anymore. Since model
uniform buffers require access to these matrices I moved the matrix
handling out of the graphics API code.
This converts the deferred lighting shader to use uniform buffers for
the dynamic data sent to the GPU while rendering the lighting effects.
This doesn't affect performance but the deferred lighting code is a
nicely isolated piece of rendering code where I could test how the
rendering code could use the uniform buffers.
This is related to #910.
Goober5000