Commit Graph

12 Commits

Author SHA1 Message Date
Jonas Kulla 9758e660c4 Tilemap/VX: Ensure proxy objects don't outlive their parents
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.
2014-09-26 18:21:50 +02:00
Jonas Kulla 81ac0780f8 Revert Disposable concept back into core
Pretty much a revert of
e858bbdcf5.

We need this in core to properly implement F12 reset.
2014-09-23 21:12:58 +02:00
Jonas Kulla f8c26fc515 Core/MRI: Fix handling of Etc/Font properties
The gist of it is that for Etc and Font props, the assignment
operator (eg. 'sprite.color=') does not take a reference of the
right hand parameter and replaces its previous one with it (this
was the old behavior). Rather, it keeps its internal property
object and copies the parameter object into it by value.
The getter is unchanged; it still returns a reference to the
internal property object.

s = Sprite.new
c = Color.new
s.color = c
p s.color == c # => true
p s.color.object_id == c.object_id # => false (true before)
c = s.color
p s.color.object_id == c.object_id # => true
2014-09-05 01:58:41 +02:00
cremno 173ee07959 get rid of INIT_TYPE() / initType()
A function to initialize rb_data_type_t variables is not needed.

Also fix a FIXME (WindowVX's name is now "Window") on the way.
2014-08-29 21:01:53 +02:00
cremno 0203e28436 use rb_data_type_t instead rb_data_type_struct
For some reason the struct tag and typedef name differ and
nobody uses rb_data_type_struct.
2014-08-29 14:13:40 +02:00
Jonas Kulla e858bbdcf5 Lift 'Disposable' concept from core into bindings
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).
2014-08-09 21:21:38 +02:00
cremno f06769b434 MRI: some minor optimizations 2014-01-24 22:30:19 +01:00
Jonas Kulla c504a383ba MRI-Binding: Optimize RB_ARG_END vaarg guard
It's enough to check this only in debug mode.
Make this an empty define in release mode.
2013-12-20 11:29:12 +01:00
Jonas Kulla f067e0eff8 MRI-Binding: Reduce number of object allocations
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.
2013-10-30 10:06:24 +01:00
Jonas Kulla dd25323cdd Ifdef out more RGSS2 functionality 2013-10-06 10:28:03 +02:00
Jonas Kulla 4ff563725b Make 'rb_get_args()' va_arg passing safer by introducing a termination marker
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.
2013-09-27 04:49:48 +02:00
Jonas Kulla ff25887f41 Initial commit 2013-09-01 16:27:21 +02:00