Jump to content


Do Not Ask if RPG Maker Games Can be Made to Run on Your DS, PSP, Whatever


  • This topic is locked This topic is locked
4 replies to this topic

#1 BigEd781


    undefined method 'stupid_title' found for nil:NilClass

  • Admin
  • 943 posts
  • LocationSan Diego, CA
  • Primarily UsesOther
  • First LanguageDothraki

Posted 12 April 2012 - 02:45 PM

We have far too many threads asking if a game made with RM can be ported to DS/PSP/whatever gaming console. Going forward, these threads will be closed immediately with no explanation.

If you don't like that, well, tough, but here is a quick synopsis on why it won't work and why you can't do it if you have to ask the question in the first place.

Some Technical Considerations
RMVX and the executables that it generates are heavily based on the Win32 API. In order to play games generated by VX in a non-windows environment, you need to emulate *ALL* of the API calls that the game will make. You also need to create a PE format executable loader for the PSP (you do know that different operating systems use different formats for executable files, right?) Hard? Yeah. You are implementing virtual machines on the PSP. Possible? Of course, most things in software are. Practical / Possible for *you*? Probably not.

You would also need to create a Ruby runtime that works on PSP hardware. Possible? Again, yes. For you? No way in hell.

Now how about space and time requirements (Memory and CPU for you non-CS folks out there)? VX uses a relatively inefficient engine by gaming standards, you need to make sure it would even work at all on XXX gaming system.

CPU architecture? Do you know how to program in assembler? Are you familiar with programming for specific, relatively exotic CPU architectures? How do you plan on emulating Windows and porting the Ruby runtime if you don't know a lick of assembler and couldn't make it past page 2 of a CPU architectural specification?

Regarding Platform Emulation
Emulation is a multi-faceted area. Here are the basic ideas and functional components. I'm going to break it into pieces and then fill in the details via edits. Many of the things I'm going to describe will require knowledge of the inner workings of processors -- assembly knowledge is necessary. If I'm a bit too vague on certain things, please ask questions so I can continue to improve this answer.
Basic idea:

Emulation works by handling the behavior of the processor and the individual components. You build each individual piece of the system and then connect the pieces much like wires do in hardware.
Processor emulation:

There are three ways of handling processor emulation:

* Interpretation
* Dynamic recompilation
* Static recompilation

With all of these paths, you have the same overall goal: execute a piece of code to modify processor state and interact with 'hardware'. Processor state is a conglomeration of the processor registers, interrupt handlers, etc for a given processor target. For the 6502, you'd have a number of 8-bit integers representing registers: A, X, Y, P, and S; you'd also have a 16-bit PC register.

With interpretation, you start at the IP (instruction pointer -- also called PC, program counter) and read the instruction from memory. Your code passs this instruction and uses this information to alter processor state as specified by your processor. The core problem with interpretation is that it's very slow; each time you handle a given instruction, you have to decode it and perform the requisite operation.

With dynamic recompilation, you iterate over the code much like interpretation, but instead of just executing opcodes, you build up a list of operations. Once you reach a branch instruction, you compile this list of operations to machine code for your host platform, then you cache this compiled code and execute it. Then when you hit a given instruction group again, you only have to execute the code from the cache. (BTW, most people don't actually make a list of instructions but compile them to machine code on the fly -- this makes it more difficult to optimize, but that's out of the scope of this answer, unless enough people are interested)

With static recompilation, you do the same as in dynamic recompilation, but you follow branches. You end up building a chunk of code that represents all of the code in the program, which can then be executed with no further interference. This would be a great mechanism if it weren't for the following problems:

* Code that isn't in the program to begin with (e.g. compressed, encrypted, generated/modified at runtime, etc) won't be recompiled, so it won't run
* It's been proven that finding all the code in a given binary is equivalent to the Halting problem

These combine to make static recompilation completely infeasible in 99% of cases. For more information, Michael Steil has done some great research into static recompilation -- the best I've seen.

The other side to processor emulation is the way in which you interact with hardware. This really has two sides:

* Processor timing
* Interrupt handling

Processor timing:

Certain platforms -- especially older consoles like the NES, SNES, etc -- require your emulator to have strict timing to be completely compatible. With the NES, you have the PPU (pixel processing unit) which requires that the CPU put pixels into its memory at precise moments. If you use interpretation, you can easily count cycles and emulate proper timing; with dynamic/static recompilation, things are a /lot/ more complex.
Interrupt handling:

Interrupts are the primary mechanism that the CPU communicates with hardware. Generally, your hardware components will tell the CPU what interrupts it cares about. This is pretty straightforward -- when your code throws a given interrupt, you look at the interrupt handler table and call the proper callback.
Hardware emulation:

There are two sides to emulating a given hardware device:

* Emulating the functionality of the device
* Emulating the actual device interfaces

Take the case of a hard-drive. The functionality is emulated by creating the backing storage, read/write/format routines, etc. This part is generally very straightforward.

The actual interface of the device is a bit more complex. This is generally some combination of memory mapped registers (e.g. parts of memory that the device watches for changes to do signaling) and interrupts. For a hard-drive, you may have a memory mapped area where you place read commands, writes, etc, then read this data back.

If all of this seems much over your head (which it will if you asked the question) you are in no way capable of getting RM games to run on a non-Windows gaming platform. Good day.
  • Mihel, Zeriab, Omnimental and 1 other like this
- Getting offended is a great way to avoid answering questions that make you sound dumb.

While sloppy writing does not invariably mean sloppy thinking, we've generally found the correlation to be strong -- and we have no use for sloppy thinkers. If you can't yet write competently, learn to.

profile for Ed S. on Stack Exchange, a network of free, community-driven Q&A sites

#2 amerk


    Advanced Member

  • Early Adopter+
  • 1,416 posts
  • Primarily UsesN/A
  • First LanguageEnglish

Posted 01 May 2012 - 09:23 AM

Not that I have any intent on this at all, but does this only apply to VX, or does it also apply to the other makers, as well? The reason I ask as this is in the "All Maker" section, but the majority of this focuses on why it can't be done in VX.

#3 mobychan



  • Members
  • 308 posts
  • LocationBaden-Würrtemberg - Germany
  • Primarily UsesRMVX Ace
  • First LanguageGerman

Posted 01 May 2012 - 09:51 AM

It's the same for each executable, and so for each maker.
VX here is just an example.
Posted Image
Posted Image

#4 Kaiser


    *Violent ECHs*

  • Members
  • 721 posts
  • LocationSomewhere between the 0s and 1s
  • Primarily UsesRMVX Ace
  • First LanguageEnglish

Posted 01 May 2012 - 04:39 PM

Even though you put this here to warn others, sorry if I'm being negative but there will be that one person that will ask if rpg maker will work on ds, psp, xbox, ps3...n64....there will be that one person that will multiply to two...then..four...then six etc etc.

*insert signature here*

#5 GrandmaDeb


    Modern Exteriors Posted!

  • Member+
  • 3,145 posts
  • LocationEast Coast, USA
  • Primarily UsesN/A

User's Awards


Posted 01 May 2012 - 04:52 PM

"kill 'em, kill 'em, before they multiply!"

fair warning, say I.

Edited by deb, 01 May 2012 - 04:53 PM.

  • BigDrew and ookami_lord like this

Also tagged with one or more of these keywords: posting-guidelines

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users