Main > Software Forum
State of the FE devs?
screaming:
--- Quote from: Howard_Casto on September 14, 2006, 10:23:35 am ---We all code in different languages and all have different features. How in the world could we share our development other than saying "Hey look what I did too bad it doesn't help you.... sucks to be you man."
--- End quote ---
2 out of the 3 "big" front ends use Visual Basic *6*. If the number of posts with, "I'm thinking of starting with a programming language. Which one should I choose?" is any indication, then I'd say there would be no shortage of people submitting bug reports and patches to them.
--- Quote from: Howard_Casto on September 14, 2006, 10:23:35 am ---I think about the only thing that has been successful cross-fe is the wrappers.
--- End quote ---
That's unfair to say because there hasn't been any other option.
--- Quote from: Howard_Casto on September 14, 2006, 10:23:35 am --- People use em on everything and a lot of fe-devs are wising up that supporting the launch of every crazy assed emu out there internally will kill ya. ;)
--- End quote ---
Who's given that a serious go and given up? Maybe you?
--- Quote from: Howard_Casto on September 14, 2006, 10:23:35 am ---If you mean multiple people working on a single fe that is essentially the same as opening up the source. You have the exact same problems and "lack of freedom" minwah is talking about.
--- End quote ---
Minwah didn't say anything about "freedom". He said he didn't want to share the responsibility of coding his front end because it's easier for him to keep track of it that way.
It's unfair to say that open sourcing your product removes some, or any, of your freedom.
swindus:
--- Quote from: Minwah on September 14, 2006, 10:27:19 am ---
--- Quote from: swindus on September 14, 2006, 10:19:31 am ---This just shows how different people think what is called easy .....
--- End quote ---
I think, people want a FE that you install, and it automaically does the rest for you. I suppose this is possible but to me would create more problems than it's worth.
And I know I'm probably old fashioned, but I also like just editing ini files for configuration. Mame uses this system which lets be honest is why most people have a cabinet...so if you can configure Mame you can configure Mamewah (or other ini-based fe). In addition to this, editing ini files on a low-res non-trackball equipped cabinet is MUCH easier than using a Windows GUI or whatever you might call it.
--- End quote ---
Your FE, your decision.
For me it was: Why not use the windows gui when running on a windows system? And my first cab was a selfbuild one with 17 inch LCD monitor running on 1280x1024. ;)
The option dialog fits on a 640x480 screen and MaLa switches the resolution for you when opening this dialog. So you can run MaLa on 368x240 for example and when opening the config dialog the resolution is changed to 640x480 and vice versa.
Of course it is better to use a mouse for it.
screaming:
Okay, let's think of the different variables involved in setting up an emulator, given a generic scenario:
1: Executable path
2: Emulator config (mame.ini, controls.cfg, etc)
3: Artwork path
4: ROM path
5: Sounds path
6: Commandline switches
7: Available games
8: Emulator support files (catver.ini, controls.dat, etc)
-----
3, 4, 5: Use the emulator config files to determine where these paths are. They're almost always defined in there and if not, they are hard coded in the emulator anyway.
6: Just about all the emulators will have a predefined set of commandline switches that you would use, and most of the ones that would be different would be detectable (old hardware? disable direct3d, for example).
7: Available Games = romlist (binary AND) gamelist output. Easy.
8: This might require some coordination on the part of the support file maintainer, but not necessarily. The latest catver is always http://www.catver.com/catveren.zip, for example. Display a disclamer/license, user clicks ok, download, unzip, enjoy.
6 and 8 could be maintained similar to how MAMEWAH Config was built: When you open up the layout browser (or the predefined emulator configs for that matter), it goes to a website, downloads an XML config file and display a list of layouts based on URLs in the XML file. No having to update and redistribute a new version of the config program - It's "live".
Out of all of these, the ones in bold are the ones that you can make automatic, or very close to it. #2 up there could come close to being automatic (but not entirely), but that is the only one where I see a lot or work to implement.
The way I see it, assuming they have set up thier emulators correctly, all the user (wants?) has to do is select thier emulator folder, click "Go" and thier emulator is set up. Save, exit, open up FE. Done.
Depending on the way the FE is built, the FE developer could get a serious start on something like this over a weekend. It's not tough stuff, it just requires forethought.
SirPoonga:
--- Quote from: screaming on September 14, 2006, 01:27:49 pm ---3: Artwork path
3, 4, 5: Use the emulator config files to determine where these paths are. They're almost always defined in there and if not, they are hard coded in the emulator anyway.
--- End quote ---
Almost
3a. Artwork built into emulator (snaps from F12).
3b. Extra artwork like instruction cards, marquees, controls panels, etc...
Plus snaps is not generic. Not all emulators create snapshots so you can;t determine those paths automatically.
Also not you need to allow multiple paths. Some of use use multiple paths. Many emulators support multiple paths for stuff.
screaming:
But as long as the emulators are set up correctly then thier config files should have that info, right? If the emulators weren't set up beyond the defaults, "snap" is the default anyway.
Sure, not all emulators have snaps, but if the layout is calling for one (which is the only time the FE would care about it) and there isn't one there there would be a some kind of placeholder image anyway.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version