Reference from other functional RGSS implementations

[Nathan-MV]

C++ SDL2

Most complete: https://github.com/mkxp-z/mkxp-z https://github.com/thehatkid/mkxp-z-android

Uses some fancy libraries: https://github.com/gxm11/RGModern

C++ SFML

It is divided into LiteRGSS2 and LiteCGSS: https://gitlab.com/pokemonsdk/litergss2 https://gitlab.com/NuriYuri/litecgss

https://github.com/Scorbutics/litergss-android

Unmaintained below

C

https://github.com/qnighy/tapir

Java libgdx

https://github.com/CameraBroke/JRGSS/tree/glrw

Ruby SDL

https://github.com/zh99998/OpenRGSS https://github.com/zh99998/OpenRGSS-RPGMaker

[Admenri]

Since mkxp is under the GPL license, I won't dwell on that. The original RGU, which I wrote during high school, was too messy in structure, so I didn't open source it. Now that I have some time, I've decided to refactor the architecture. The plan is to write it in an asynchronous multithreaded mode. As for referencing RGM, I actually know the author of RGM, and the inspiration for asynchronous multithreading came from him. Considering that I also have another commercial project to maintain, I will only maintain this project sporadically.

[Nathan-MV]

The developer of LiteRGSS2 said at some point that he implemented SpriteMap in C++, tilemap uses SpriteMap, which is a collection of Sprite objects, but exposes only one sprite in the ruby world, which makes z-sorting faster because you divide the number of sprite needed by 22 with this optimization

(Well, i think that for an RGSS implementation, something low-maintenance like Raylib would be better instead of SDL2/SFML)

[Admenri]

There is a reason for not using third-party graphics libraries. My plan is for RGU to support extensible plugins, with upcoming plugins for Live2D and Spine. These third-party libraries directly invoke the OGL graphics API. Simultaneously, creating a custom rendering process allows for better optimization of the draw call flow. Additionally, the new RGU is planned to be cross-platform. The cross-platform behavior of third-party libraries is challenging to accurately predict and control. Therefore, the optimal solution, considering these factors, is to write the rendering part ourselves.

[Nathan-MV]

There is a reason for not using third-party graphics libraries. My plan is for RGU to support extensible plugins, with upcoming plugins for Live2D and Spine. These third-party libraries directly invoke the OGL graphics API. Simultaneously, creating a custom rendering process allows for better optimization of the draw call flow. Additionally, the new RGU is planned to be cross-platform. The cross-platform behavior of third-party libraries is challenging to accurately predict and control. Therefore, the optimal solution, considering these factors, is to write the rendering part ourselves.

I'm not saying that RGU would be better with Raylib, i was just expressing my thoughts because Raylib is the de facto low-maintenance being a game framework cross-compatible for Windows, macOS, Linux, ChromeOS, FreeBSD, Raspberry PI, Android, Web and has everything that RGSS uses already implemented in it by default, and its popularity on github is only below Godot's while being the only game framework with more than 60 programming language bindings, you can use it anywhere you like https://github.com/raysan5/raylib It seems someone already implemented Live2D and Spine in Raylib https://github.com/pure01fx/raylib-live2d https://github.com/WEREMSOFT/spine-raylib-runtimes The disadvantages of using it are that it is limited to any version of OpenGL and Angle