MapleShrine
/
mkxp
1
0
Fork 0
Code Issues 32 Pull Requests 11 Projects Releases Wiki Activity
mkxp/binding-mruby/disposable-binding.h

118 lines
2.9 KiB
C
Raw Normal View History

Initial commit
2013-09-01 14:27:21 +00:00
/*
** disposable-binding.h
**
** This file is part of mkxp.
**
** Copyright (C) 2013 Jonas Kulla <Nyocurio@gmail.com>
**
** mkxp is free software: you can redistribute it and/or modify
** it under the terms of the GNU General Public License as published by
** the Free Software Foundation, either version 2 of the License, or
** (at your option) any later version.
**
** mkxp is distributed in the hope that it will be useful,
** but WITHOUT ANY WARRANTY; without even the implied warranty of
** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
** GNU General Public License for more details.
**
** You should have received a copy of the GNU General Public License
** along with mkxp. If not, see <http://www.gnu.org/licenses/>.
*/
#ifndef DISPOSABLEBINDING_H
#define DISPOSABLEBINDING_H
#include "disposable.h"
#include "binding-util.h"
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 16:35:01 +00:00
#include "mruby/array.h"
Transition from QtCore to stdc++ / STL / boost 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!
2013-12-11 19:46:54 +00:00
#include <string.h>
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 16:35:01 +00:00
/* 'Children' are disposables that are disposed together
* with their parent. Currently this is only used by Viewport
* in RGSS1.
* FIXME: Disable this behavior when RGSS2 or 3 */
inline void
disposableAddChild(mrb_state *mrb, mrb_value disp, mrb_value child)
{
mrb_sym sym = getMrbData(mrb)->symbols[CSchildren];
mrb_value children = mrb_iv_get(mrb, disp, sym);
if (mrb_nil_p(children))
{
children = mrb_ary_new(mrb);
mrb_iv_set(mrb, disp, sym, children);
}
/* Assumes children are never removed until destruction */
mrb_ary_push(mrb, children, child);
}
inline void
disposableDisposeChildren(mrb_state *mrb, mrb_value disp)
{
MrbData *mrbData = getMrbData(mrb);
mrb_value children = mrb_iv_get(mrb, disp, mrbData->symbols[CSchildren]);
if (mrb_nil_p(children))
return;
for (mrb_int i = 0; i < RARRAY_LEN(children); ++i)
mrb_funcall_argv(mrb, mrb_ary_entry(children, i),
Bindings: Fix inconsistency in Viewport dispose (RGSS1) As noted, on Viewport dispose, RMXP always calls the core dispose method for child objects regardless of whether user scripts override it in sub classes. Implement this behavior in mkxp to prevent infinite recursion.
2014-10-24 16:29:08 +00:00
mrbData->symbols[CS_mkxp_dispose_alias], 0, 0);
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 16:35:01 +00:00
}
Initial commit
2013-09-01 14:27:21 +00:00
template<class C>
MRB_METHOD(disposableDispose)
{
Revert Disposable concept back into core Pretty much a revert of e858bbdcf5cc8120dd169d7efb8ae8d13ab0b5c5. We need this in core to properly implement F12 reset.
2014-09-23 19:12:58 +00:00
C *d = static_cast<C*>(DATA_PTR(self));
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 16:35:01 +00:00
Revert Disposable concept back into core Pretty much a revert of e858bbdcf5cc8120dd169d7efb8ae8d13ab0b5c5. We need this in core to properly implement F12 reset.
2014-09-23 19:12:58 +00:00
if (!d)
return mrb_nil_value();
if (d->isDisposed())
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 16:35:01 +00:00
return mrb_nil_value();
Bindings: Viewport: Don't dispose children in RGSS2/3
2014-10-24 16:55:03 +00:00
if (rgssVer == 1)
disposableDisposeChildren(mrb, self);
Initial commit
2013-09-01 14:27:21 +00:00
Revert Disposable concept back into core Pretty much a revert of e858bbdcf5cc8120dd169d7efb8ae8d13ab0b5c5. We need this in core to properly implement F12 reset.
2014-09-23 19:12:58 +00:00
d->dispose();
Initial commit
2013-09-01 14:27:21 +00:00
return mrb_nil_value();
}
template<class C>
Revert Disposable concept back into core Pretty much a revert of e858bbdcf5cc8120dd169d7efb8ae8d13ab0b5c5. We need this in core to properly implement F12 reset.
2014-09-23 19:12:58 +00:00
MRB_METHOD(disposableIsDisposed)
Initial commit
2013-09-01 14:27:21 +00:00
{
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 16:35:01 +00:00
MRB_UNUSED_PARAM;
Initial commit
2013-09-01 14:27:21 +00:00
Revert Disposable concept back into core Pretty much a revert of e858bbdcf5cc8120dd169d7efb8ae8d13ab0b5c5. We need this in core to properly implement F12 reset.
2014-09-23 19:12:58 +00:00
C *d = static_cast<C*>(DATA_PTR(self));
if (!d)
return mrb_true_value();
return mrb_bool_value(d->isDisposed());
Initial commit
2013-09-01 14:27:21 +00:00
}
template<class C>
Remove optnone
2019-05-08 11:46:32 +00:00
static void disposableBindingInit(mrb_state *mrb, RClass *klass)
Initial commit
2013-09-01 14:27:21 +00:00
{
mrb_define_method(mrb, klass, "dispose", disposableDispose<C>, MRB_ARGS_NONE());
Revert Disposable concept back into core Pretty much a revert of e858bbdcf5cc8120dd169d7efb8ae8d13ab0b5c5. We need this in core to properly implement F12 reset.
2014-09-23 19:12:58 +00:00
mrb_define_method(mrb, klass, "disposed?", disposableIsDisposed<C>, MRB_ARGS_NONE());
Bindings: Fix inconsistency in Viewport dispose (RGSS1) As noted, on Viewport dispose, RMXP always calls the core dispose method for child objects regardless of whether user scripts override it in sub classes. Implement this behavior in mkxp to prevent infinite recursion.
2014-10-24 16:29:08 +00:00
Bindings: Viewport: Don't dispose children in RGSS2/3
2014-10-24 16:55:03 +00:00
if (rgssVer == 1)
mrb_alias_method(mrb, klass, getMrbData(mrb)->symbols[CS_mkxp_dispose_alias],
mrb_intern_lit(mrb, "dispose"));
Revert Disposable concept back into core Pretty much a revert of e858bbdcf5cc8120dd169d7efb8ae8d13ab0b5c5. We need this in core to properly implement F12 reset.
2014-09-23 19:12:58 +00:00
}
template<class C>
inline void
checkDisposed(mrb_state *mrb, mrb_value self)
{
if (mrb_test(disposableIsDisposed<C>(0, self)))
raiseDisposedAccess(mrb, self);
Initial commit
2013-09-01 14:27:21 +00:00
}
#endif // DISPOSABLEBINDING_H