Releases: 20kdc/gabien-app-r48
v2.0: Calling it
Is this the v2.0 release I wanted? Close enough? Obviously everybody wants their releases to be all-singing all-dancing. All I can really hope for is that if this isn't the final time that it's worth calling an R48 release a major release, then it's because of something truly amazing I couldn't even conceive of.
Over the last RC, it doesn't add much (improves the tips a little and adds a volume control to the audio player), but that's what RCs are for, and v2.0 had to be called at some point.
For all changes, see:
v2.0-rc3: Minor fixes/improvements over last RC
See: https://github.com/20kdc/gabien-app-r48/releases/tag/v2.0-rc2 and https://github.com/20kdc/gabien-app-r48/releases/tag/v2.0-rc1.
But also...
- Engine/encoding name shown on system tools menu.
- The weirdness with medicine item parameters in 2k/2k3 is more documented.
- On RVXA and RXP, textbox width can be set. The monospace font can be 'adjusted' to fit like with 2k[3]. R48 now has a dedicated
zR48ProjectConfigdata file that it uses to store project-specific configuration options for these targets. - Jump-to-entry is now implemented on RXP/RVXA.
- The 2k/2k3 passability overlay was flipped left/right. It is now not flipped.
v2.0-rc2: more D/MVM power, even more improved compatibility
For the most part, check v2.0-rc1's changelog: https://github.com/20kdc/gabien-app-r48/releases/tag/v2.0-rc1.
Some key notes:
- Fixes a missing call to
eglBindAPI, fixing support for later versions of Ubuntu which for some reason chose not to ship OpenGL ES 1 support. - Fixes broken audio.
- D/MVM can now create its own independent object roots (not tracked by undo/redo), and display them to the user.
- "Find common events by condition switch ID" button.
- RM-Tools has become Engine Tools; a central place for engine-specific buttons.
- As part of cleaning up the Datum spec for general use,
'syntax was removed from Datum. There are a few other Datum changes.
v2.0-rc1: Undo/Redo, improved compatibility
Undo/redo has kinda been just, like, a thing R48 didn't have for the longest time.
It was quite a pain. The problem is, there were technical challenges implementing it.
Even now there will be issues. There will be jank. There will probably be ways to crash R48 using undo/redo.
But I've done what I can, I think.
Yes, I know, there is no instant Control-Z keyboard shortcut. Not sure how to implement it without stepping on the toes of the Swing textboxes.
Measures have also been taken to help with compatibility with future versions of Android, though they are... pretty bad measures.
No Google-ordained Android veteran would ever approve of them, but they keep the R48 experience usable and avoid the pitfalls of jank and lost URL access and goodness knows what that seem to be common in my experience using applications built with the "Storage Access Framework".
Despite being a "release candidate" I've set it as the latest release; undo/redo has been a big sticking point with R48 for so long that allowing some instability in the public release of the project is worth it.
Other stuff, other stuff...
- BadGPU was fixed to work on more systems. In particular, BadGPU even works in containers! (This may allow R48 to work in containers under special circumstances. Good times.)
- R48 now attempts to load more class files during startup to improve post-launch game load times on Android.
- All DBLoader formats have been transferred to a sort of DBLoader/Datum hybrid, and changes have been made to make the bigger cases of format jank less janky.
- The help system is currently living in a kind of 'deprecated state' while it's figured out how to replace it with something easier to edit, maintain, and generally do anything with. The DBLoader based mechanism was bad and the Datum-based mechanism is actually worse here. The help files themselves need a rewrite too.
- The splash screen is now animated.
- The R48 logo is now vectorized in all uses inside the application. Honestly, this is showing off some tech that might become more useful later as UI resources get vectorized. Right now it's just showing off.
- Developers are no longer required to edit an image file every single time they create a release of R48.
- There is an environment variable to test error handling,
R48_DEBUG_PLEASE_FAIL_BRUTALLY. - The UIObjectDBMonitor has been removed to avoid memory/font thrashing. It got replaced with bitmap engine font text on the new no-tab screen.
- The no-tab screen has been replaced with a somewhat more soothing
and cheaper on the CPUnoise effect. - The 4px symbol set has been removed.
- When a Target is being drawn on a map at a tile size of 32 and the zoom level is at half, the low-resolution version of the Target will be used. This is a special rule intended to improve R48's usability for RXP games that use a 16-pixel tile size like R2K, i.e. remakes of such games.
- The "Magical Binding" functionality was finally removed from the codebase. Good riddance.
- D/MVM now has limited support for static typing. This is intended to catch bugs as functionality moves to D/MVM.
v1.6-3: Small UI fix, update natives again
This fixes the "replace EGL with ANGLE" emergency fallback and makes a small UI fix to the command finder (i.e. makes its UI work at all).
**Android 14 users: Next release will fix things for you. For now, see https://developer.android.com/about/versions/14/behavior-changes-all#minimum-target-api-level **
v1.6-2: Fix command finder, fix Windows 32-bit natives
Pretty much all it says on the tin.
v1.6-1: A bit more media support, RXP fixes
RXP is the oldest backend, so it turns out it needed a bit of modernization, go figure...
Also, the filesystem handling has been rewritten somewhat. What this means in practice is that you can now select Secondary Image Load Location assets in the selector.
v1.6: the beginning of the branch split
So from this point forward some changes are going onto the master branch, which is separate to this branch.
The main goal of the v2.0 stuff will be to clean up the internals. If that's possible... who knows.
Big changes:
- Ogg & MP3 support for audio preview!
- Improve searching
- New 'hopefully-faster' layout algorithm
v1.5: Accelerated Rendering
Rough changelog
- Fancy new hardware-accelerated batching renderer
- Reworked internals of theming system
- Find/replace of IDs (i.e. for creating variants of events)
- Very early stage of introduction of Scheme-like language for extending R48
- Translation now uses said language
- Fixed build system signing the APK incorrectly because jarsigner will apparently just do that for "security"
- Various stuff I presumably missed
Compatibility Notes
v1.5 uses a new renderer which may be less or more compatible with some systems. Specification, should help for technical details
I have tried my best to make sure it's as compatible as possible.
Users on Android have been seeing performance improvements, so I think I've succeeded.
However, I can't absolutely guarantee that everything will all work, especially if the renderer is "pushed" with for example absurd image sizes.
As for hardware compatibility, if your hardware is compatible with OpenGL ES 1.1 with the OpenGL ES 1.1 Extension Pack, you'll be fine. In practice, due to the use of FBOs, you will need to use hardware from roughly 2004 or later or to use Mesa software rendering.
Unfortunately, due to issues with the natives builds, it may turn out that Android users before API level 9 - Android 2.3.0 - may be affected. R48 will still attempt to support API level 7, but it might not work.
As for architectures:
- Android: 64-bit architectures require an API level 21 NDK platform. Therefore the 64-bit natives are built against API level 21 and may not be compatible with earlier devices.
- Windows is only supported for x86 and x86_64.
- Due to build system limitations and general Apple tomfoolery, Mac OS X is only supported for x86_64 and aarch64 targets.
- In an attempt to improve compatibility with older glibc versions, most desktop Linux builds (x86_64, aarch64, riscv64) of the natives are compiled with
-nostdlib. The 32-bit x86 build did not compile properly this way, so was compiled normally. There is no 32-bit ARM build because it's almost impossible to correctly define what 32-bit ARM is outside of a contained context like Android.
I would also like to note that even this level of compatibility would not have been possible without the existence of https://github.com/ziglang/zig/ - used as a key element of, for example, the Mac OS X build. (As far as I know the Zig Software Foundation does not endorse or support this project and so forth. I'm just noting Zig's existence because it's a key element.)
v1.5-rc1: Accelerated rendering
Big Scary Warning!
This is a release candidate, not final.
Rough changelog
- Fancy new hardware-accelerated batching renderer
- Reworked internals of theming system
- Find/replace of IDs (i.e. for creating variants of events)
- Very early stage of introduction of Scheme-like language for extending R48
- Translation now uses said language
- Fixed build system signing the APK incorrectly because jarsigner will apparently just do that for "security"
- Various stuff I presumably missed
Compatibility Notes
v1.5 will use a new renderer which may be less or more compatible with some systems.
I have tried my best to make sure it's as compatible as possible.
Users on Android have been seeing performance improvements, so I think I've succeeded.
However, I can't absolutely guarantee that everything will all work, especially if the renderer is "pushed" with for example absurd image sizes.
As for hardware compatibility, if your hardware is compatible with OpenGL ES 1.1 with the OpenGL ES 1.1 Extension Pack, you'll be fine. In practice, due to the use of FBOs, you will need to use hardware from roughly 2004 or later or to use Mesa software rendering.
Unfortunately, due to issues with the natives builds, it may turn out that Android users before API level 9 - Android 2.3.0 - may be affected. R48 will still attempt to support API level 7, but it might not work.
As for architectures:
- The current release does not target MIPS. A build attempt will be made for the v1.5 release, but if it doesn't work then it doesn't work, I'm afraid.
- 64-bit architectures require an API level 21 NDK platform. Therefore the 64-bit natives are built against API level 21 and may not be compatible with earlier devices.
- Windows is only supported for x86 and x86_64.
- Due to build system limitations and general Apple tomfoolery, Mac OS X is only supported for x86_64 and aarch64 targets.
- In an attempt to improve compatibility with older glibc versions, most desktop Linux builds (x86_64, aarch64, riscv64) of the natives are compiled with
-nostdlib. The 32-bit x86 build did not compile properly this way, so was compiled normally. There is no 32-bit ARM build because it's almost impossible to correctly define what 32-bit ARM is outside of a contained context like Android.
I would also like to note that even this level of compatibility would not have been possible without the existence of https://github.com/ziglang/zig/ - used as a key element of, for example, the Mac OS X build. (As far as I know the Zig Software Foundation does not endorse or support this project and so forth. I'm just noting Zig's existence because it's a key element.)