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).
This looks like a pretty major change, but in reality,
80% of it is just renames of types and corresponding
methods.
The config parsing code has been completely replaced
with a boost::program_options based version. This
means that the config file format slightly changed
(checkout the updated README).
I still expect there to be bugs / unforseen events.
Those should be fixed in follow up commits.
Also, finally reverted back to using pkg-config to
locate and link libruby. Yay for less hacks!
This replaces the previously directly bound #clone
methods, which weren't really the "the Ruby way".
Rubys default Object#clone will call into our #init_copy
methods instead.
Partly incorporates pull request #3 by /cremno.
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
Edward Rudd