Greetings! Congrats on this new incarnation of the 3DO emulator. It looks great, and I hope you get the thanks of the community for your hard work.
The reason I found your site was because I was trying to set up my emulator collection on a new machine, going from a WinXP setup to a Win7 setup. On the new machine, I simply could not get the old commandline wrapper I used with FreeDO to work. I tried all the solutions on the web, and every version of FreeDO (even the hard-to-find version 1.6.2).
All earlier versions of the emulator would not work due to the lack of an ASPI file. The latest version, 1.9, would work, but I could not get the commandline wrapper to work with it via my frontend (MaLa).
Long story short - I'm wondering if there are any plans to build commandline support into the 4DO emulator, to allow it to work with frontends like MaLa and MAMEWAH.
Many thanks!
commandline feature
Re: commandline feature
Welcome to the humble 4DO abode! I can't say for certain I'll get to adding that feature, but I believe I know what you're referring to.
By command line support, do you mean things like "-openIso [gamerom]"? Could you give an example of an emulator with these features? I am wondering if others go fullscreen for your using similar command line options.
I know generally how I would implement it; I have a backdoor in fourdo currently for opening the game input screen on startup for me.
By command line support, do you mean things like "-openIso [gamerom]"? Could you give an example of an emulator with these features? I am wondering if others go fullscreen for your using similar command line options.
I know generally how I would implement it; I have a backdoor in fourdo currently for opening the game input screen on startup for me.
Re: commandline feature
Thanks for the welcome - glad to be here!
Yes, that's exactly the kind of thing I was thinking of. I have an arcade cabinet with several emulators running in it, and use a graphical frontend to simplify the process of finding and launching games for friends who aren't emulator-savvy. They can browse from system to system - say, from Atari 2600 to Nintendo NES to 3DO. Once in a system they can browse a list of games, and launch the game they'd like to play.
Under the hood, the frontend is scrolling through a list of games in a directory on the drive. When the user selects a game to play, the frontend can launch the required emulator, and feed it a command string. The command string at minimum must have the name of the requested ROM or ISO file. But it can also include other information, such as the path to the ROM, the file extension, a particular screen size, or whether to turn particular accessories on or off, such as a lightgun or special joystick.
Some emulators use an INI file which can contain information about whether to launch in fullscreen or windowed mode, etc. Some emulators allow the command string to override the options in the INI file. This can be handy if I want different settings in the frontend versus running the emulator manually from the desktop. Fullscreen is the best example of a setting I would want to be different depending on the circumstances.
The Z26 emulator (Atari 2600) has DOZENS of command switches, which allow you to not only specify a ROM, but also set screen resolution, turn various Atari visual effects on and off, and specify that you've got either joystick, paddle, or keypad plugged in.
http://www.whimsey.com/z26/
Or here's another example: the Fusion emulator for Sega Genesis:
http://www.eidolons-inn.net/tiki-index.php?page=Kega
It emulated ALL the Sega systems prior to Saturn. When my frontend tries to launch a ROM, it needs to specify whether it's trying to start the emulator in Master System, GameGear, Genesis, 32X or SegaCD mode. The command string that my frontend executes looks like this:
c:\fusion\fusion.exe c:\fusion\roms\Sonic.zip -gen -auto -fullscreen
...where the "-gen" specifies that the emulator should start up in Sega Genesis mode.
Being able to tweak settings via command line switches is nice, but given the awesome job you've done creating a good interface for 4DO, it's not really necessary. I think the only thing I'd be looking for in a command line feature would be:
1) the ability to pass an ISO file to the emulator
2) the ability to specify fullscreen mode
Another nice option would be to have a command switch that allows the emulator to shut down when the escape key is pressed. This is a nice feature to have because most cabinets don't have a keyboard, and the user has to rely on a joystick and fire button to navigate around. Usually one key is mapped to ESCAPE as an all-purpose "back" or "exit" button for all emulators (provided they support that feature).
On my old system, I was using FreeDO v1.9. It didn't have command line support, but I was able to accomplish all this using a "wrapper" - a small executable someone wrote that would take the command line and somehow plug them into the emulator to achieve the same effect.
The old wrapper for FreeDO can be found here:
http://maximusarcade.com/index.php?opti ... edowrapper
Sorry for the wordy response! Also - these kinds of things might be very low on your priority list for the emulator, so I appreciate you even reading through this. Thanks so much for all your hard work, and I'll be looking forward to future releases!
Yes, that's exactly the kind of thing I was thinking of. I have an arcade cabinet with several emulators running in it, and use a graphical frontend to simplify the process of finding and launching games for friends who aren't emulator-savvy. They can browse from system to system - say, from Atari 2600 to Nintendo NES to 3DO. Once in a system they can browse a list of games, and launch the game they'd like to play.
Under the hood, the frontend is scrolling through a list of games in a directory on the drive. When the user selects a game to play, the frontend can launch the required emulator, and feed it a command string. The command string at minimum must have the name of the requested ROM or ISO file. But it can also include other information, such as the path to the ROM, the file extension, a particular screen size, or whether to turn particular accessories on or off, such as a lightgun or special joystick.
Some emulators use an INI file which can contain information about whether to launch in fullscreen or windowed mode, etc. Some emulators allow the command string to override the options in the INI file. This can be handy if I want different settings in the frontend versus running the emulator manually from the desktop. Fullscreen is the best example of a setting I would want to be different depending on the circumstances.
The Z26 emulator (Atari 2600) has DOZENS of command switches, which allow you to not only specify a ROM, but also set screen resolution, turn various Atari visual effects on and off, and specify that you've got either joystick, paddle, or keypad plugged in.
http://www.whimsey.com/z26/
Or here's another example: the Fusion emulator for Sega Genesis:
http://www.eidolons-inn.net/tiki-index.php?page=Kega
It emulated ALL the Sega systems prior to Saturn. When my frontend tries to launch a ROM, it needs to specify whether it's trying to start the emulator in Master System, GameGear, Genesis, 32X or SegaCD mode. The command string that my frontend executes looks like this:
c:\fusion\fusion.exe c:\fusion\roms\Sonic.zip -gen -auto -fullscreen
...where the "-gen" specifies that the emulator should start up in Sega Genesis mode.
Being able to tweak settings via command line switches is nice, but given the awesome job you've done creating a good interface for 4DO, it's not really necessary. I think the only thing I'd be looking for in a command line feature would be:
1) the ability to pass an ISO file to the emulator
2) the ability to specify fullscreen mode
Another nice option would be to have a command switch that allows the emulator to shut down when the escape key is pressed. This is a nice feature to have because most cabinets don't have a keyboard, and the user has to rely on a joystick and fire button to navigate around. Usually one key is mapped to ESCAPE as an all-purpose "back" or "exit" button for all emulators (provided they support that feature).
On my old system, I was using FreeDO v1.9. It didn't have command line support, but I was able to accomplish all this using a "wrapper" - a small executable someone wrote that would take the command line and somehow plug them into the emulator to achieve the same effect.
The old wrapper for FreeDO can be found here:
http://maximusarcade.com/index.php?opti ... edowrapper
Sorry for the wordy response! Also - these kinds of things might be very low on your priority list for the emulator, so I appreciate you even reading through this. Thanks so much for all your hard work, and I'll be looking forward to future releases!
Re: commandline feature
It's a very interesting project! It sounds a bit similar to "hyperspin", which I haven't used myself.
If you're interested in getting this off the ground right now, it sounds like the 4DO features that are in place now would allow you to do this...
User's settings get saved in an XML file named (appfolder)\Settings\FourDO.settings. You'd first be interested in AutoOpenGameFile, which you'd set to True. Then you'd want GameRomSourceType, which you'd set to 1 (this indicates "file"). Finally, you'd set GameRomFile to the game's ISO file path.
There are also settings for window size, including full screen (WindowFullScreen). The input/joystick settings are also saved to file, but those are a bit more complicated. You still could script it out, theoretically.
I figure I'll be pretty stringent if I add command line parameters because there are only so many features I alone can add and support, but the two you mention would definitely make the list. One reason I haven't yet fleshed out a feature like that is that I haven't reached a concrete opinion on the appropriate handling of the "collision" of authority between potential command line parameters as opposed to the user's settings file. For example, if I let you pass in the game ISO like that, the easiest way for me to make it work is to set that setting in the settings file on startup. I'm unsure if that's functional enough (perhaps I want those to be "temporary" settings!), and the alternatives to that simple approach are difficult to implement.
By the way, it's times like this I'm glad I stuck to my guns on having the settings files get put in the file system near the executable rather than C:\Users\AppData\blah\blah\cryptic\path.
If you're interested in getting this off the ground right now, it sounds like the 4DO features that are in place now would allow you to do this...
User's settings get saved in an XML file named (appfolder)\Settings\FourDO.settings. You'd first be interested in AutoOpenGameFile, which you'd set to True. Then you'd want GameRomSourceType, which you'd set to 1 (this indicates "file"). Finally, you'd set GameRomFile to the game's ISO file path.
There are also settings for window size, including full screen (WindowFullScreen). The input/joystick settings are also saved to file, but those are a bit more complicated. You still could script it out, theoretically.
I figure I'll be pretty stringent if I add command line parameters because there are only so many features I alone can add and support, but the two you mention would definitely make the list. One reason I haven't yet fleshed out a feature like that is that I haven't reached a concrete opinion on the appropriate handling of the "collision" of authority between potential command line parameters as opposed to the user's settings file. For example, if I let you pass in the game ISO like that, the easiest way for me to make it work is to set that setting in the settings file on startup. I'm unsure if that's functional enough (perhaps I want those to be "temporary" settings!), and the alternatives to that simple approach are difficult to implement.
By the way, it's times like this I'm glad I stuck to my guns on having the settings files get put in the file system near the executable rather than C:\Users\AppData\blah\blah\cryptic\path.
Re: commandline feature
Thanks!
I wasn't sure how much to explain - after spending so much time in the arcade cabinet community, I've forgotten that it doesn't always overlap with the emulator community.
Also, I don't want to leave you with the wrong impression - I'm not developing a frontend, I'm using an existing one, called MaLa. It's not as graphically fancy as Hyperspin, but I like it because it's a little simpler to set up and provides good support for having multiple lists of games. For instance, if I want to have a short list of 10 3DO games for friends who are using the machine, but still be able to switch to a long list of 100 games for myself.
I hadn't thought about the collision of authority issue you mentioned, but it makes sense. I guess if I solve the problem on my end, I'd have to create a series of batch files, one for each game. I would then launch the batch file through the frontend. The batch file would either rewrite or swap the XML with another game-specific version, then launch 4DO.
I think you understand what I'm trying to do, but in case it helps to see my setup process, here's how it looks in MaLa:
This is the config window where you specify the executable, ROM location and ROM extension:
This information is placed into variables that can be inserted into the commandline, in case it needs information like the extension or full pathname.
Here's the window where you actually provide a commandline for the emulator:
Notice how the commandline is using the variables from the first window. The quotations are there because some emulators can't parse pathnames with spaces or long directory names. Also notice the PRE and POST command windows, where you can (duh!) run pre and post commands. For emulators that require CD images to be loaded in a virtual drive, this is where you would provide the load and unload commands. To solve my issue with 4DO, I might be able to use the PRE command window to run the batch file to swap in a game-specific XML file. I could then use the POST command window to swap it back to the default XML file, if I need to do that at all.
The last image I wanted to show you is this one:
Most of these options are specifically for MaLa to display game artwork, but the feature I wanted to point out is the "EXIT HOOK" option at the bottom, which allows you to temporarily specify a "kill" button which will terminate the emulator and put you back in the frontend. That's why I listed the "escape key" feature as optional, because it's possible to get the same functionality using the frontend.
I'll experiment with the PRE commands and multiple XML files, and maybe I can even write to some other emulator devs and see if they have any thoughts on sorting out conflicts between INI files and commandline instructions. If I get any tips, I'll let you know.
Thanks!
I wasn't sure how much to explain - after spending so much time in the arcade cabinet community, I've forgotten that it doesn't always overlap with the emulator community.
Also, I don't want to leave you with the wrong impression - I'm not developing a frontend, I'm using an existing one, called MaLa. It's not as graphically fancy as Hyperspin, but I like it because it's a little simpler to set up and provides good support for having multiple lists of games. For instance, if I want to have a short list of 10 3DO games for friends who are using the machine, but still be able to switch to a long list of 100 games for myself.I hadn't thought about the collision of authority issue you mentioned, but it makes sense. I guess if I solve the problem on my end, I'd have to create a series of batch files, one for each game. I would then launch the batch file through the frontend. The batch file would either rewrite or swap the XML with another game-specific version, then launch 4DO.
I think you understand what I'm trying to do, but in case it helps to see my setup process, here's how it looks in MaLa:
This is the config window where you specify the executable, ROM location and ROM extension:
This information is placed into variables that can be inserted into the commandline, in case it needs information like the extension or full pathname.
Here's the window where you actually provide a commandline for the emulator:
Notice how the commandline is using the variables from the first window. The quotations are there because some emulators can't parse pathnames with spaces or long directory names. Also notice the PRE and POST command windows, where you can (duh!) run pre and post commands. For emulators that require CD images to be loaded in a virtual drive, this is where you would provide the load and unload commands. To solve my issue with 4DO, I might be able to use the PRE command window to run the batch file to swap in a game-specific XML file. I could then use the POST command window to swap it back to the default XML file, if I need to do that at all.
The last image I wanted to show you is this one:
Most of these options are specifically for MaLa to display game artwork, but the feature I wanted to point out is the "EXIT HOOK" option at the bottom, which allows you to temporarily specify a "kill" button which will terminate the emulator and put you back in the frontend. That's why I listed the "escape key" feature as optional, because it's possible to get the same functionality using the frontend.
I'll experiment with the PRE commands and multiple XML files, and maybe I can even write to some other emulator devs and see if they have any thoughts on sorting out conflicts between INI files and commandline instructions. If I get any tips, I'll let you know.
Thanks!
Re: commandline feature
I second this. I need this for use with my frontend gameex. Thats how i launch all my emulators is through a frontend. Command line is the only way to use this with it.
Re: commandline feature
hey johnny,
first off, thanks for picking up the continued development, i love me some 3DO!
i also am using command line and i just about have it running, thought maybe you could share a bit of light?
i am doing it just a bit differently though. my front end uses daemon to mount a disc, drive letter G:
is there a specific line in your xml file that is for auto launching a game disc? if there, i'd be all set!
keep up the great work!
first off, thanks for picking up the continued development, i love me some 3DO!
i also am using command line and i just about have it running, thought maybe you could share a bit of light?
i am doing it just a bit differently though. my front end uses daemon to mount a disc, drive letter G:
is there a specific line in your xml file that is for auto launching a game disc? if there, i'd be all set!
keep up the great work!
Re: commandline feature
Since you are lauching from a disc drive (even since it's virtual) the option in the menu that says "After startup, launch last game" will auto run whatever disc is in that drive. The setting is in the menu, also it is in the FourDO.settings file. I also just tested this to make sure that this is what would happen, so it should work correctly for you.
Re: commandline feature
BryWI wrote:Since you are lauching from a disc drive (even since it's virtual) the option in the menu that says "After startup, launch last game" will auto run whatever disc is in that drive. The setting is in the menu, also it is in the FourDO.settings file. I also just tested this to make sure that this is what would happen, so it should work correctly for you.
oh man, that was easy, apologies for not being able to figure that out. but thanks so much! keep it up guys, the 3DO desperately needs some emu love!
one last quickie? it loads just as it should, thank you again. the only small issue is that the "file" drop down menu (close, open cd image file, open disc drive, etc.) is visible over the game until i click somewhere on the screen. is there some option to start "quietly" for lack of a better term?
thanks again guys!
Re: commandline feature
The behavior of the menu being shown on fullscreen, on startup... is not happening for me. I can force it to happen though if the mouse cursor is in the upper left. Is the position of the mouse forcing it to show? I also notice that if the mouse is at the upper part of the screen, the menu doesn't show right away but pauses everything too. It's a little bit weird of a behavior, but not too serious of a problem.
Anyways, im pretty sure it's the position of where the mouse is when you are starting up. If not, its behaving differently from my system for some reason.
Anyways, im pretty sure it's the position of where the mouse is when you are starting up. If not, its behaving differently from my system for some reason.
Who is online
Users browsing this forum: No registered users and 53 guests