Clannad Side Stories Crash (Steam)

[JeodC]

Using the steam version of Clannad Side Stories, crashes during the Key logo.

(SEEN1000)(Line 19): std::bad_alloc

Happy to report that Clannad HD from Steam seems to run ok.

[Mickey-snow]

Hi JeodC!

Thanks for reporting the crash issue with the Steam version of Clannad Side Stories. It looks like the crash is caused by a memory allocation error (std::bad_alloc) that occurs because the parser gets confused during the handling of input. The grammar definitions for <string> and <tag> are leading to ambiguities, causing the parser to misinterpret the input from SEEN1001, which is needed by SEEN1000 Line 19, and exhausting all available memory.

I'm currently working on resolving this and several other unimplemented opcodes that are also affecting gameplay. But it's a complex issue and I can't guarantee a fix just yet.

[JeodC]

Hey I didn't expect it to even be worked on. Appreciate the update. :)

[JeodC]

Hello Serina, have you had any luck with this one?

[Mickey-snow]

Sorry JeodC, this is more complicated than I thought, but I'm still working on it.

[Mickey-snow]

Hey JeodC!

I've been working on some updates to rlvm to tackle the Clannad Side Stories crash problem. I've refactored a lot of the original code and added some new features that might fix this issue. You can find my changes in a new repo here.

If you're up for it, I'd really appreciate any testing or feedback to make sure everything works as it should. Cheers!

[JeodC]

Hey JeodC!

I've been working on some updates to rlvm to tackle the Clannad Side Stories crash problem. I've refactored a lot of the original code and added some new features that might fix this issue. You can find my changes in a new repo here.

If you're up for it, I'd really appreciate any testing or feedback to make sure everything works as it should. Cheers!

I'll have to build an aarch64 binary for it, but I'd be glad to! Hopefully within the next week. Thank you for your efforts!

[JeodC]

For context, the way I built rlvm for arm64 is to use a forked repository which contains some adjustments specific to the runtime environment, and forked that here. Adding another repository on top of that complicates things a tad, but I'll give building a try when I can. Summarily, it looks like I'll have to cherry-pick a few commits like the SDL-only build without gtk.

[Mickey-snow]

Got it. Is it the gtk platform specific code that's blocking your way? My current refactoring strategies include separating the abstraction from the implementation using the bridge pattern, and I've applied it to SDLSoundSystem, would that make the build easier?

The repository you mentioned also includes support for resolution independent devices, apparently. I plan to implement this in the graphics system as well in the future.

[JeodC]

Got it. Is it the gtk platform specific code that's blocking your way? My current refactoring strategies include separating the abstraction from the implementation using the bridge pattern, and I've applied it to SDLSoundSystem, would that make the build easier?

The repository you mentioned also includes support for resolution independent devices, apparently. I plan to implement this in the graphics system as well in the future.

I specifically built rlvm to run on linux arm handhelds that use low-end processors and mali blobs. They have no x11 or wayland, and most games just use sdl as their backend. It has resulted in many modern games being manageable on small handhelds like anbernic and powkiddy.

The resolution independence is a direct result of supporting a plethora of these handhelds. As we have no window manager, all of our ports scale to fill the display, and there are a lot of various resolutions and aspect ratios to cover.

You may find a partial explanation of my own commits here.

[Mickey-snow]

I specifically built rlvm to run on linux arm handhelds that use low-end processors and mali blobs. They have no x11 or wayland, and most games just use sdl as their backend. It has resulted in many modern games being manageable on small handhelds like anbernic and powkiddy.

The resolution independence is a direct result of supporting a plethora of these handhelds. As we have no window manager, all of our ports scale to fill the display, and there are a lot of various resolutions and aspect ratios to cover.

You may find a partial explanation of my own commits here.

Thanks for sharing. While I can't promise you an implementation for this porting, I'll try defining nicer platform-independent abstractions and promote them in the codebase. My main focus is to extent support for newer HD version games, and incrementally refactor along the way. I hope you'll find it useful.

[JeodC]

I specifically built rlvm to run on linux arm handhelds that use low-end processors and mali blobs. They have no x11 or wayland, and most games just use sdl as their backend. It has resulted in many modern games being manageable on small handhelds like anbernic and powkiddy.

The resolution independence is a direct result of supporting a plethora of these handhelds. As we have no window manager, all of our ports scale to fill the display, and there are a lot of various resolutions and aspect ratios to cover.

You may find a partial explanation of my own commits here.

Thanks for sharing. While I can't promise you an implementation for this porting, I'll try defining nicer platform-independent abstractions and promote them in the codebase. My main focus is to extent support for newer HD version games, and incrementally refactor along the way. I hope you'll find it useful.

That is exciting! Ever since adding rlvm to the ports library, people have asked about other various novel engines like katawa shoujo and steins;gate, but the primary question was if we would ever see the commercially available releases of these games be compatible.

I'll keep an eye on it! Thank you for picking up the mantle!

[Mickey-snow]

Got it. Is it the gtk platform specific code that's blocking your way? My current refactoring strategies include separating the abstraction from the implementation using the bridge pattern, and I've applied it to SDLSoundSystem, would that make the build easier?
The repository you mentioned also includes support for resolution independent devices, apparently. I plan to implement this in the graphics system as well in the future.

I specifically built rlvm to run on linux arm handhelds that use low-end processors and mali blobs. They have no x11 or wayland, and most games just use sdl as their backend. It has resulted in many modern games being manageable on small handhelds like anbernic and powkiddy.

The resolution independence is a direct result of supporting a plethora of these handhelds. As we have no window manager, all of our ports scale to fill the display, and there are a lot of various resolutions and aspect ratios to cover.

You may find a partial explanation of my own commits here.

Hey JeodC,

I've just introduced a patch that decouples the GUI platform implementations from the main RLVM executable. This simplifies adding and managing different GUI platforms, and allows for runtime selection of it, which might be beneficial for your use case. I hope you'll find it useful and easier to work on.

The patch breaks osx support though, currently I don't have the device to build and test it, but I'll probably fix it in the future.

If you plan to use this, I’d be eager to assist with tailoring these changes to better fit your scenarios.

[JeodC]

Got it. Is it the gtk platform specific code that's blocking your way? My current refactoring strategies include separating the abstraction from the implementation using the bridge pattern, and I've applied it to SDLSoundSystem, would that make the build easier?
The repository you mentioned also includes support for resolution independent devices, apparently. I plan to implement this in the graphics system as well in the future.

I specifically built rlvm to run on linux arm handhelds that use low-end processors and mali blobs. They have no x11 or wayland, and most games just use sdl as their backend. It has resulted in many modern games being manageable on small handhelds like anbernic and powkiddy.
The resolution independence is a direct result of supporting a plethora of these handhelds. As we have no window manager, all of our ports scale to fill the display, and there are a lot of various resolutions and aspect ratios to cover.
You may find a partial explanation of my own commits here.

Hey JeodC,

I've just introduced a patch that decouples the GUI platform implementations from the main RLVM executable. This simplifies adding and managing different GUI platforms, and allows for runtime selection of it, which might be beneficial for your use case. I hope you'll find it useful and easier to work on.

The patch breaks osx support though, currently I don't have the device to build and test it, but I'll probably fix it in the future.

If you plan to use this, I’d be eager to assist with tailoring these changes to better fit your scenarios.

Gtk seems to build just fine using wsl2 and a debian aarch64 env. Understandably, the other platforms aren't prepared yet. It looks great, and it was very easy to find which platforms were available to use. Nice work!

[JeodC]

Did some more looking, seems like adding a puresdl platform might be simpler than thought. https://github.com/JeodC/rlvm/blob/master/SConscript.sdl