This way Meson will automatically keep the Git hash updated as you make
new Git commits, rather than forcing you to reconfigure the build again
every time you make a new commit to keep the commit hash updated.
I've decided to stop gambling with ways to make `-e` not crash Ruby on
startup in libretro builds (see commit
1473416a5a for context). Making Ruby load
a dummy script seems to work better.
Guys, I think I'm going insane. Every time I build the libretro Ruby
sandbox with a different version of Ruby, or even when I build Ruby at a
different path on my computer, there's some chance that the builds
produced with that version of Ruby and/or that path on my computer
result in Ruby crashing on startup in libretro builds. I've been
tweaking these command-line arguments that are passed to Ruby for a
while now, and I *think* these are the correct ones that will stop Ruby
from crashing.
In RGSS, uninitialized disposable objects (and Fonts, sort of) are technically disposed, and other objects (Tone, Color, Rect, and Table) are created with all values set to 0. It's also possible to reinitialize them, although reinitializing disposables leaks memory.
This commit causes MiniFFI and FileInt objects to improperly raise disposed errors if used while uninitialized, but that feels acceptable to me.
While this does close small memory leaks, this is mostly for threading reasons. We're not supposed to call rb_raise with the gvl released, and calling rb_raise prevents GFX_UNLOCK from being called, which would cause problems for any games that want to call graphical operations in multiple threads should the user reset.
We're also now calling Graphics.__reset__ and Audio.__reset__ via eval instead of directly calling the functions, in case a game wants to hook them.
rb_raise calls longjmp, which bypasses C++ destructors, and also keeps the error for catch blocks from being unallocated if passed by reference, which we do for exceptions.
Some of the calls I left can still jump out of try blocks, which you're not supposed to do, but there shouldn't be any objects with destructors initialized at those points so it's probably fine.
It's currently not (much of) a problem because few or no games use multiple threads, but I believe that ruby can run its garbage collector while the GVL is released, which means that Graphics.update and Graphics.wait are currently not thread safe.
Moving the call to GFX_LOCK into dispose() should fix this.
I don't really plan on putting out another "release tag" anytime soon,
so the hash for the current git commit is being added to the version string
to help tell the difference between one build and the other.
+ Time is now measured in fractions of a second, not microseconds
+ Viewports in RGSS1 will now only retain weak references to their children
+ Invalid Sprite bitmaps found during Graphics.update will be treated as null
+ Bitmap#mega? and Bitmap#animated? are properly rescued
* MiniFFI: Use MINIFFI_MAX_ARGS instead of literal
* MiniFFI: Document lines that need changing if MINIFFI_MAX_ARGS changes
* Bump MINIFFI_MAX_ARGS to 12
Fixes https://github.com/mkxp-z/mkxp-z/issues/2
* Bump MINIFFI_MAX_ARGS to 16
last minute thought I had, in order to try and avoid
conflicts with any other global constants that happen
to be called "CONFIG". Also looks nice next to "ENV".
- `System.config` has become `CONFIG.to_hash`
- `CONFIG[]` can be used to look up settings
- `CONFIG[]=` can be used to add/change settings
- When reading settings, user settings are preferred over defaults
- Changes are immediately stored in the user settings file
