This is a parser for a very simple language to allow for execution of
dynamic expressions with return values for use as action parameters. The
only "dynamic" part this currently supports are random ranges but more
features are planned for the future.
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.
This is basically the tutorial from vulkan-tutorial.com adapted to using
VulkanHpp and with some refactorings that extract some locigally
self-contained code.
Currently only draws a simple colored triangle.
This is an effort to be able to use the same GLSL code for both Vulkan
and OpenGL. This is done by first compiling the Vulkan GLSL code to
SPIR-V and then using a custom tool (which uses SPIRV-Cross) to convert
that back into GLSL 1.50 compatible code.
The required tool will be downloaded by CMake when glslc is found in the
path. This is included in the Vulkan SDK. To avoid having a hard
dependency on this, the generated files are included in the VCS and are
only regenerated when glslc is found on the system.
I have been thinking about some shader related techniques for the Vulkan
renderer and for that we will need to add embedded files in a different
environment than they are right now since the actual shader code will
not be needed in the engine.
For this reason, I extracted the "default file" mechanism to be more
generic so that all that is necessary to include a file is to just call
a custom CMake command and the function keeps track of what needs to be
done.
Also, since the "generic" code has worked pretty well so far I see no
reason to keep around two systems which just increases the amount of
code we need to maintain. So, I just removed the windows exclusive
implementation. Now all platforms use the same "generic" way of
embedding files.
This gives every document their own environment instead of using the
global environment. Previously it was necessary to store variables in
the global namespace since otherwise they could not be accessed by event
listeners.
This creates a separate environment table for every document so that all
<script> blocks and event handlers share the same "global" environment.
This can be used by script code for reliably storing Lua values without
having to build a custom serialization format.
The C++ code can also be used by other code modules that want to
serialize data. The new classes simply return a byte array with an
unspecified format.
At the moment this uses a plain JSON encoding but could be extended in
the future to include either compression or BSON encoding if necessary.
The format is future compatible by using a simple header to identify
different kinds of formats.
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.
This allows a script to create its own execution context so that it can
control when a coroutine is valid to play based on custom data.
Also adds a function which causes a coroutine to end in an error.
This emulates the "scrolling text" effect that is present in briefings.
It is not exactly the same since it just goes pixel wise and not by
character but it looks good enough.
The previous API only allowed very limited access to the audio stream
system. These changes add full support for playing all types of audio
streams via a dedicated API.
1) Upgrade the pilot file code to correctly save flags whether entries are added *or* removed
2) Make the tech-db/tech-db-multi ship flag handling consistent
3) Add scripting support for intel entries
4) Add scripting support for adding and removing entries from the tech room
5) Minor cleanup
This adds a "clear-debris" SEXP with a new system for declaring SEXPs
outside of sexp.cpp. This makes it easier to keep code modules self
contained since they do not need to export previously private
functionality just for having missiong being able to interface with it.
This is mostly a proof-of-concept which only supports basic parameter
types (booleans and integers).
This adds access to the command briefing data parsed from the mission
file to the scripting API so it can be used by the UI scripts for the
high res UI.
Also switches the animation support to using the generic anim to use
streaming to improve performance.
I added a pretty generic container structure for the scripting
documentation when adding JSON output. However, I did not use that new
structure for the HTML output since that was just too much work.
This moves the HTML output over to the new structure so now the
scripting API handling code is independent from how the resulting
documentation is generated. I also moved that code out of the main
scripting code which removes quite a lot of clutter in those files.
This is mostly a straight port of the old code with no significant
changes (except the changes to make it use the new data).
This adds an Antlr grammar for parsing argument lists instead of using a
hand written parser. This allows to write much more complicated syntax
constructs and have all the code being auto-generated. It will also
produce a much more correct parser instead of having all those hacks in
the hand-written one.
This also adds (in addition to supporting the previous syntax) support
for function types along with support for them in HTML and JSON output
formats.
The ANTLR generated parser is included in source form so that it is not
necessary to have an ANTLR installation around if you are not going to
change the grammar. Also includes the necessary runtime code from Antlr.
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 adds a simple parser that takes the existing argument
documentations and parses them so that better documentation can be
generated from that information. This should be sufficient for providing
proper documentation generation for the most common and simple cases of
argument lists (type, name, possible default value, and optional
groups).
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 adds a Lua API for representing asynchronous operations and running
coroutines based on those operations comfortably. This is very similar
to features other languages have introduced such as C# or JavaScript. In
fact, the whole "promise" thing is derived from how JavaScript
represents these operations.
This is the initial and very basic system for supporting async
coroutines in Lua. There is no native support for running these
operations at specific points (they run whenever the awaited promise
resolved) or making sure they do not leak through different game states.
This adds the capability to have a Lua script that does not need to use
our table syntax at all but instead defines the hooks by calling API
functions. This also makes it possible to add hook functions at runtime
if the script requires that.
Also clean up some unused debug stuff.
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 does some refactoring to make it possible to cimpile and run FSO
without needing to link to FFmpeg. Since that eliminates support for
cutscenes or sound this is mostly useful for running a standalone server
which has no need for this anyway.
This reduces the image size of the standalone Docker image to only 20MB
and also resolves any licensing issues that might have existed.
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.
asarium