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, wrapped instances of mkxp core classes were
stored as RData ivars inside the actual object. This turned
out to be pointless as RData objects themselves are perfectly
valid objects that can carry ivars and have parent classes.
Therefore, the RData objects are now exposed directly to
the user scripts, effectively halving the amount of object
allocations.
What can I say. I made a pact with the devil, and paid dearly.
Almost a whole day's worth of debugging, actually. Not again.
If this turns out to be slow we can always optimize the critical
parts (with no variable param count) later, or completely remove it.
Jonas Kulla
cremno