This was 20.1 since I erronously thought that the "current" nightly
version was lower than that. This updates the version to a release that
has not been built yet.
* Expose disposing FBO's (with the option to keep the Bitmap Alive) to scripting
* Modernize nullptr
* Moved RenderTarget clearing to own public API
* Fixed Obsolete Comment
* Fix bad deletion of FBOs
* Resolve Memory Leak
* Change FBO cleanup to not reuse old ID's
* FIx oversight
* FIx oversight 2
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 was the last thing that was missing for complete support of all
function parameter declarations.
To ensure parameter lists stay valid a unit test was added that will
validate the argument lists and cause the test to fail if they cannot be
parsed.
Previously, if a script called a function that called another scripting
hook, some hook variables might be removed. This was the case since
after executing the hook the code would remove the set hook variables
again. If these variables had the same name as previously set variables,
they would overwrite and corrupt the state the original script expected.
This was unexpected behavior for script writers so this puts values on a
stack and only adds or removes from the stack instead of overwriting
values. This should make the hook variable state consistent for scripts
even if scripting hooks are called indirectly.
The scripted code previously didn't check to see if a weapon bank was valid before firing it, which could have led to memory problems and starting March 15 would actually crash the game. This adds a few safety checks.
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.
JohnAFernandez