One of the min reasons RPG Maker games run slower than most people would like is irrelevant to Ruby. It is true that ruby is interpreted and runs slower than a compiled language, however the way RM was designed, everything runs on the CPU, and if I had to take a guess I'd say one thread. What does that mean, exactly? Well, with running everything on the CPU, the actual graphics you see are not processed by your graphics card. The CPU has to take time to do that, which slows down everything else. Audio is also one by the CPU, however this behavior is much more common than graphics being processed by the CPU. As you can probably imagine, graphics drawing takes a lot more time than setting a little space in memory to a number, so that slows down processing considerably.
*If RPG Maker is run on a single thread (I am not sure of this), that means that everything is processed in a line. It will go something similar to
- Update Graphics
- Update Audio
- Update Scripts
This is logical programming behavior, and is expected. However, back to the CPU needing to draw graphics and drawing graphics taking a lot more time than simple variable comparison and setting, the audio will not be updated until the graphics are done. This leads to more time being taken to update each time, and if it is bad enough, visible lag would be the result.
I'd like to recommend RM gets rewritten to use the graphics card for graphical elements and the CPU for audio and script processing, as this would greatly reduce lag strain on the game. Additionally, as a programmer there are several improvements I'd like to see with the encrypted archives.
First, please allow us to add data into the archive during runtime. This can be used to allow us to save settings that should not be cleared into the archive where the user wouldn't be able to delete them unless they were to delete the majority of the data.
Secondly, it is common knowledge that there are decryptors available to get the contents of an encrypted archive out and available to users. Please allow us to create our own methods for encryption and decryption. This way, each game has the ability to use a custom encryption method so that creating a general RM decryptor would be more difficult, and would allow us to better protect our game data for a time. I am aware that a crack will be made eventually if people find it worth it, however I'm more concerned with having the time it takes to get that crack made be longer than releasing a game a year after the maker comes out and a ready-to-use decryptor can get all my game's data out immediately.
By all means keep a default encryption method, but allow the possibility for the developer to use a custom one if they are willing to put the effort in, or to pay someone else to make it for them.
*Upon writing the middle of the second paragraph/example I realized audio does continue to run when the game window is not selected and regardless of graphics lag, so it is probably multithreaded. However, it is still possibly both graphics and scripts are processed in the same thread (as both won't update unless the window is selected).