Either of these would previously crash (same for VX):
tm = Tilemap.new
at = tm.autotiles
tm = nil
GC.start
at[0] = Bitmap.new(1, 1)
tm = Tilemap.new
at = tm.autotiles
tm.dispose
at[0] = Bitmap.new(1, 1)
Funnily, this makes RMXP itself crash too, but crashing is
never acceptable except for possibly resource exhaustion.
Fixes Window_NameBox visual appearance in Skyborn.
Also nuke the second SceneElement constructor that has been
obsolete since the Tilemap mapViewport rewrite.
Replacement: ZLayer
I'd really have loved to have used something alluding to physical
roof tiles (as that's the closest image I have to them), but without
reusing the word "tiles".. yeah, impossible.
Instead of replicating the RGSS Disposable interface in C++
and merely binding it, redefine the 'disposed' state as the
entire core object being deleted (and the binding object's
private pointer being null).
This makes the behavior more accurate in regard to RMXP.
It is now for example possible to subclass disposable classes
and access their 'dispose'/'disposed?' methods without
initializing the base class first (because the internal pointer
is simply null before initialization). Accessing any other
base methods will still raise an exception.
There are some quirks and irregular behavior in RMXP; eg.
most nullable bitmap attributes of disposable classes
(Sprite, Plane etc.) can still be queried afterwards, but
some cannot (Tilemap#tileset), and disposing certain
attributes crashes RMXP entirely (Tilemap#autotiles[n]).
mkxp tries to behave as close possible, but will be more
lenient some circumstances.
To the core, disposed bitmap attributes will look
identically to null, which slightly diverges from RMXP
(where they're treated as still existing, but aren't drawn).
The Disposable interface has been retained containing a
single signal, for the binding to inform core when
objects are disposed (so active attributes can be set to null).
Previously, on creation, we would parse the entire map data,
translating it into and uploading vertices once, then rendering
the entire map on every draw (to keep the draw calls minimal).
This worked great for smaller and medium sized maps, but starting
with larger maps (200x200+) it doesn't scale as the GPUs vertex
processing/culling is overwhelmed by the amount of data each frame.
This rewrite instead changes the strategy to only processing and
uploading a small subregion of the map (the currently visible part)
and regenerating all buffers if this subregion changes. The amount
of data transferred is small enough that it can be done every frame
without causing lag.
The changes also have the convenient side effect that we no longer
require 32 bit indices in mkxp, easing the road to possible GLES2
support in the future.
Previously, we would just stuff the entire tilemap vertex data
four times into the buffers, with only the autotile vertices
offset according to the animation frame. This meant we could
prepare the buffers once, and then just bind a different offset
for each animation frame without any shader changes, but it also
lead to a huge amount of data being duplicated (and blowing up
the buffer sizes).
The new method only requires one buffer, and instead animates by
recognizing vertices belonging to autotiles in a custom vertex
shader, which offsets them on the fly according to the animation
index.
With giant tilemaps, this method would turn out to be a little
less efficient, but considering the Tilemap is planned to be
rewritten to only hold the range of tiles visible on the screen
in its buffers, the on the fly offsetting will become neglient,
while at the same time the amount of data we have to send to the
GPU everytime the tilemap is updated is greatly reduced; so a
net win in the end.
GL entrypoint resolution is now done manually. This has a couple
immediate benefits, such as not having to retrieve hundreds of
functions pointers that we'll never use. It's also nice to have
an exact overview of all the entrypoints used by mkxp.
This change allows mkxp to run fine with core contexts, not sure
how relevant that is going to be in the future.
What's noteworthy is that _all_ entrypoints, even the ones core
in 1.1 and guaranteed to be in every libGL, are resolved
dynamically.
This has the added benefit of not having to link directly against
libGL anymore, which also cleans up the output of `ldd` quite
a bit (SDL2 loads most system deps dynamically at runtime).
GL headers are still required at build time.
This bit was deprecated/removed in core GL.
There was only one place where this was used (flash tiles
in Tilemap), and since the full shader rewrite, it was
effectively a no-op anyway (flash shader doesn't sample texture).
Previously, any font names requested by RGSS would be translated
directly to filenames by lowercasing and replacing spaces with
underscores (and finally doing some extension substitution).
To make this whole thing work smoother as well as get closer to
how font discovery is done in VX, we now scan the "Fonts/" folder
at startup and index all present font assets by their family name;
now, if an "Open Sans" font is present in "Fonts/", it will be
used regardless of filename.
Font assets with "Regular" style are preferred, but in their
absence, mkxp will make use of any other style it can find for
the respective family. This is not the exact same behavior as
VX, but it should cover 95% of use cases.
Previously, one could substitute fonts via filenames, ie. to
substitute "Arial" with "Open Sans", one would just rename
"OpenSans.ttf" to "arial.ttf" and put it in "Fonts/". With the
above change, this is no longer possible. As an alternative, one
can now explicitly specify font family substitutions via mkxp.conf;
eg. for the above case, one would add
fontSub=Arial>Open Sans
to the configuration file. Multiple such rules can be specified.
In the process, I also added the ability to provide
'Font.(default_)name' with an array of font families to search
for the first existing one instead of a plain string.
This makes the behavior closer to RMXP; however, it doesn't
work 100% the same: when a reference to the 'Font.name' array is
held and additional strings are added to it without re-assignig
the array to 'Font.name', those will be ignored.
This gets rid of the "batch/flush" semantics for #set_pixel
and instead just directly uploads the pixel color to the
texture, circumventing the float conversion entirely.
Also makes a lot of code simpler in many places as calling
'flush()' is no longer required for bitmaps.
An exception is made of TexPool, which will need a
bit more testing before transitioning to std containers.
Also replace 'int' with 'size_t' where it is used only
as an array index.
The general rule I'm aiming for is to <> include
system wide / installed paths / generally everything
that's outside the git managed source tree (this means
mruby paths too!), and "" include everything else,
ie. local mkxp headers.
The only current exception are the mri headers, which
all have './' at their front as to not clash with
system wide ruby headers. I'm leaving them be for now
until I can come up with a better general solution.
Releasing a Tilemap atlas into the pool on every map switch
will blow out tons of smaller textures for very little gain,
as atlas textures are already pretty much impossible to
recycle anywhere but in new Tilemaps.
Using "SDL2/SDL_xxx.h" instead of "SDL_xxx.h" caused
the include paths provided by pkg-config to be ignored,
and headers from a standard include path to be used instead.
If consecutive scanrows in the scene list have no foreign
elements in between them, we batch them up and draw them
in one glDrawElements() call.
This should reduce the Tilemap induced draw calls on
average by at least 50 percent.
The atlas packing algorithm has been reworked to pack autotiles
and tileset very efficiently into a texture, splitting the tileset
in multiple ways and eliminating the previous duplication of image
data in the atlas across "frames". Animation, which these frames
were designed for, is now done via duplicated buffer frames,
ie. each animation frame has its own VBO and IBO data. This was
not done to save on VRAM (hardly less memory is used), but to
make place for the new atlas layout.
Thanks to this new layout, even with a max texture size of 2048,
one can use tilesets with up to 15000 height. Of course, such
a tileset couldn't be stored in a regular Bitmap to begin with,
which is why I also introduced a hack called "mega surfaces":
software surfaces stored in RAM and wrapped inside a Bitmap,
whose sole purpose is to be passed to a Tilemap as tilesets.
Various other minor changes and fixes are included.
Jonas Kulla