What's up, RMers?

[Kain Nobel]

Currently updating my old game project, which is starting to outgrow RMXP. Not that RMXP is bad, it will always have a special place in my heart, but this migration has been going on for a minute. There are certain limitations related to the XP engine that make it desirable to build a newer engine for it. I don't WANT to build an engine from scratch, but that's OK I'll do what I have to for this thing to run better. Aside from that, there is a bunch of things that have been completely rewritten which make the original RMXP implementation redundant and, soon, unnecessary.

The problems I encounter are related to time and frames per second. The math and execution time, tying your engine to the FPS, start to get a little fuzzy and I start noticing complications. For instance, to run the game at 60 FPS takes more than just Graphics.frame_rate = 60; it required a re-write of the Sprite_Timer and the Interpreter conditional branches too as 1 second (FPS) does not necessarily equal 1 second (Real Time). Plus other time related issues I can't really remember off the top of my head for which I've had to implement. Aside from that, I notice that after 6 hours of play the Game.exe starts eating up more memory and CPU and I don't know how to clear that in a closed black box system such as RGSS. Shutting down the game and starting it back up is the only remedy. Occasionally the computer needs a restart too so I can only guess what is going on behind the scenes.

Aside from that, I read the Steam reviews for RMXP games and they all have the frame rate issue as a common complaint. The frame rate issue has poached especially good games that would've had better review scores had it not been an issue. It would be wonderful if we could get an XP Ace with fixed / more features but I'm not holding my breath, just moving forward!

(NOTE: I've specifically focused on RMXP games on Steam due to the fact that's what I use. I have no idea of VX, VXAce, MV or any of the releases after XP have a frame rate / time issue or if their engines are tied to Graphics.frame_rate. As much as I love RPG Maker, this is a bad design choice.)

There are so many (boring) details behind this migration, but I've been running on a hybrid in-between system of Ruby 3.0 and RMXP (Ruby 1.8.4) for awhile and am starting to layer and branch the project more. If I write an engine that is compatible with RMXP, it is only because that is what my game was built on but I have no true desire to faithfully remake RGSS in C++ and use SWIG/RICE/whatever for Ruby extensions. The only thing left that is "RMXP" in my project is the Map/Events system, Database/Common Events, Database/System and the Game.exe to run it. I no longer use the database for Actors, Enemies, Skills, Items, etc, all of that is set via load scripts written in Notepad++.

Some of the stuff was going to go "ReGaL" but some of it is too specific from my game to be considered. If I ever do a "ReGaL" style project, I don't want it to be too specific like that, more "general purpose/agnostic" related to a generic JRPG structure that can be expanded on by the end user. Then again, that's what RPG Maker is for...

Currently I'm studying C++, Ruby, RICE, and general application development. I've not posted a project on GitHub yet because I'm trying to simplify the logistics of deployment and portability. The project was portable 6 months ago, I could move it from my C drive (desktop computer) to my D drive (laptop with a removable SSD chip) with minimal configuration changes and no issues but I've acquired some new "hard coded" filepaths that I need to purge and move to the RGL::Config module.

EDIT: I just posted my C++/SFML Audio module in the Scripts database. If anybody knows how to directly implement this so the C++ and Ruby can communicate (perferably not via Win32API / Win32::API) that would be awesome. I'm going to try to figure that out within the next couple of weeks if I'm not too busy with work/life.