Do Not Ask if RPG Maker Games Can be Made to Run on Your DS, PSP, Whateverposting-guidelines
Posted 12 April 2012 - 02:45 PM
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.
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.
There are three ways of handling processor emulation:
* 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
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.
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.
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
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.
Posted 01 May 2012 - 09:23 AM
Posted 01 May 2012 - 09:51 AM
VX here is just an example.
Posted 01 May 2012 - 04:39 PM
*insert signature here*
Also tagged with one or more of these keywords: posting-guidelines
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users