Talk:System Emulators

Classifying Emulators

Howard C. brought up the idea of classifying emulators in a way that will make it easy to refer to which frontends will support these emulators. I'm adding some of the discussion here for further discussion.

As for classifying the emulators there are a few different requirements which we'd have to categorize (note these names mean nothing, I'm just throwing them out there).

As far as emulators that use the command line, there are four main types:

Command Line Type 1-Fully MAME compatable

They use the exact same syntax as mame to launch a game and set any required settings.

An example would be... well, mame.

Command Line Type 2-Fully command line compatable

These emulators don't use mame's syntax, but they use a syntax that has the same basic launching method (send the rom path or romname and rom path). These emulators require sending settings that aren't like mame's.

An example would be daphne. You just send the rom name to launch the game, but daphne won't run unless you also pass the "vldp c:\pathtoframefile\framefile.txt" for each game. This means your front-end has to let you "build" a custom command line string with different options sent for each game or else you need a wrapper.

Command Line Type 3-Translation required

These emulators don't use the romname to launch a game. Because of this emulators need specific code to support them or else you need a wrapper. Even if a front-end does support them natively, it might not always be such a good idea to use said support as you are dependant upon the fe author to update their fe whenever a new version of the emulator comes out.

The only example I can think of is zinc as it uses the romnumber instead of the name.

Command Line Type 4-Mounting/External app launch required

This happens a lot with console emulators. Basically the emu doesn't support roms, but rather iso images. The emu can't support genuine cds and thus everyone mounts their hacked isos to virtual drives. The emu doesn't mount them automatically and thus you have to call an app to mount it prior to launch. Or perhaps some misc, app/batch file has to be ran prior to get your pc ready for the emu (such as a key-remapper).

An example might be chankast, but it is a bad one as it's a hybrid (I'll explain that later). It would also apply to playstation emulators.

Windows Type1 - Listed

These emus, are completely compatable with my kepress simulator. They require a series of keys to get to a list/drop down box of all the games available. A key is pressed to naviagate to the appropriate game and another series of keys are pressed to launch the game and setup any generic settings. No game, specific keypresses are required and a mouse isn't required to navigate.

Final burn is the perfect example of this.

Windows Type2 - Non-Listed

These emus work exactly as above, but when it comes time to select a game, the old windows "browse for file" dialog opens up. Since there is not way of knowing a users file systems, it is impossible to use keypresses to navigate the box. However, since most of these "browse" boxes offer the option to manually type the path at the bottom. It would be possible to manually type the path there via keypresses. At this time there isn't such a wrapper available because of the increased difficulty, but it is possible to make a generic one that would handle these types of games quite easily.

A lot of your modern console emulators do this one (can't think of any off the top of my head).

Windows Type3 - Unstandardized

These emus only need keypresses to run, but there is no standardization on how to select the game. A custom keypress sequence is required for each individual game. Or the emu is type1 or type2 but keypresses are required to set individual settings as each game needs "tweaked" to run properly. Either way, these emus can't be handled by generic wrappers and a custom wrapper must be built for them.

Windows Type4 - Mouse Required

These emus can only launched with simulated mouse inputs or a combination of mouse and keyboard inputs. Again, usually a custom wrapper is required.

Hybrid Emulators

Hybrid emulators require a little of each and are absolutely impossible to launch without a custom wrapper.

The best example is chankast, which is the baine of my existance. Chankast supports command line launching, but only of homebrew games. For commercial games an image needs to be mounted via daemon tools/alcohol 120% prior to launch. Also every single game needs different tweaks to run well and the options are only accessable via the window menus. On top of that all the options are toggle options, meaning you can just send a keypress sequence to set them, so I write a "blank" cfg file for chankast prior to launch so I know all the options are off. I only explain in this much detail to make it understandable that a custom wrapper/script is the ONLY way to launch such emus and no fe author in their right mind would ever add native support.

There are three final categories, what I call "Easies", "Pinballs" and "S.O.L.s"

Easies just need a nudge. They are usually fully command line compatable, but lack a single, needed functionaly. The most common is that they launch fine but won't exit with escape or will only exit with escape. Generic Wrappers, Exe hacks, and even front-ends can all take care of this sort of thing quite easily.

Pinballs are basically visual pinball and future pinball. When black made these things he decided to associate the table files with the editor for auto-launch. Instead of just sending a tablepath to the simulator with the "shell" command you have to use the less-popular "createprivateprocess" command and send a "Play" command as the action rather than the normal "run" command or else the simulator will open up the table in the editor. In the case of visual pinball, the emu won't quit with a single keypress either. A few fe's support these apps natively, but it is usually better to use a wrapper.

With sols, you guessed it, you are sol.

The best example I could give would be neorageX. Ngx is fullscreen and uses low level inputs for navigation thus making it nearly impossible to simulate input via a wrapper. On top of that, you navigate through ngx via the mouse and scrollbars, making it impossible to track which game you've selected. To make things worse, the gui isn't built with standard windows controls and thus you can't even use fancy window sniping techniques to get/set data. While you can launch the emulator itself via a front-end and thus some people might be willing to use it, you can't launch a secific game, and thus this has to be done manually. In terms of consoles we might run into a case when the only emulator available would be a sol one.

---

Discussion

I brought this up because if this is done, a naming convention of sorts should be decided on. The emulator pages could classify it as the type of emulator it is, and that can link to the page that explains the type, and maybe even have a list of frontends that support that type. Thoughts?

--Liquid8 13:40, 21 May 2006 (EDT)