If PhysFS fails to open a path, fall back to simple FILE* handles.
Not sure yet if this is a good idea, but from observation
RMXP allows load_data() to operate on paths outside the game
directory as well, so we have to support this.
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!
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.
We override 'Marshal::load()' via alias and call it with
a custom auxiliary proc in the alias which sets the encoding
of all demarshalled strings to UTF-8. The case where a user
himself provided a proc to 'load()' is not implemented.
This is definitely a better solution than patching the ruby
source tree. Thanks to github.com/cremno for hints and help!
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.
Ancurio
Jonas Kulla
cremno