FE developers, what lessons have you learned in making yours?

[Felsir]

I noticed that some people create their own frontend (instead of using established FEs like Mala, Hyperspin etc.) I'm thinking of creating my own as well- mainly because I think it is a fun project to do.

I was wondering if there are any lessons learned, unexpected challenges or emulators that caused headaches. Anyone willing to share?

[Gray_Area]

I'd re-title the thread to "FE developers, what lessons have you learned in making yours?"

[Felsir]

thanks for the hint. I'm not a native speaker... 

[mrv2k]

It is ridiculously hard to do.

I've been writing MAMOS (My Arcade Machine Operating System) for four months and it surprised me in the scale of data involved. MAMOS only supports MAME at the moment and is still in alpha stages but the amount of data and information it has to generate and parse is huge.

MAME supports over 26,000 games. That info needs to be stored in a database efficiently. The database needs to be sorted and filtered for easy access. Once the game is selected you need to poll the database, load any images and any ini/info/dat information and display it in an understandable way. Oh and quickly!

Once the game is selected you have to deal with the command line options of which there are loads. Each command becomes a gadget, which triggers a variable, which is polled to generate the command line when you run a game and has to be saved for future use.

You also need to be able to customise the frontend which involves adding scalability for different resolutions, variables for colours, fonts, images. These settings also need to be saved.

After getting all the above working you need to look at other frontends and the feedback they get and implement anything you feel relevant.

Personally when I set out to write my frontend I decided that I didn't want lists all over the place and I wanted as much of the available media and info available straight away.

So far MAMOS supports
All current MAME options
zip and 7z files.
History.Dat
MAMEinfo.dat
Catver.ini
NPLayers.ini
Icon support.
All progretto snap images (including bosses,versus, gameover etc...)
Emumovies/Video files

It can parse the complete MAME XML, sort it and filter it in under 20 seconds.
It loads in under a second and the exe is under 2MB in size.
It is completely portable and will be available in 32 and 64bit versions.

At the moment I'm working on a MAWS style game info page with ROM auditing. Then I need to finish the settings, command line options, finalize the stored files and then bug fix the whole thing. http://forum.arcadecontrols.com/Smileys/default/banghead.gif

Hopefully I'll get to a beta version about May where I'll introduce MAMOS to the world. In the mean time I've attached a picture of the current alpha.

Regards

MrV2K

http:\\easyemu.mameworld.info

[Howard_Casto]

My suggestion would be not to do it. 

I used to write FEs for the community, keyword used to.  You think supporting mame is a pain in the butt, try supporting everything else.  Mame is a cake-walk, it prints out nice data for you to use, the others don't.    Also if you want the thing to run with any degree of speed, you'll probably need to make it a directX/ogl app.  So unless you know one or the other, you are kind of screwed. 

[sandheaver]

My suggestion would be not to do it. 

I used to write FEs for the community, keyword used to.  You think supporting mame is a pain in the butt, try supporting everything else.  Mame is a cake-walk, it prints out nice data for you to use, the others don't.    Also if you want the thing to run with any degree of speed, you'll probably need to make it a directX/ogl app.  So unless you know one or the other, you are kind of screwed. 

Do it, but be smart about it.  Don't write one for the community, write it for yourself.  Use the technology & language(s) that you know.  Limit your scope.

NO MAME front-end will need to list every last game supported by MAME.  No one is going to play every single variation of every single fruit machine that is supported.

On mine, I have a menu editor, that exists outside of the front-end itself.  I use that to select which games I'll make available in the menu, and manage categories, clones, etc.  It queries MAME (via -listxml) and I can select all vertical games or only games of a certain resolution, only vector, etc.  I can query by any information contained in that XML file MAME generates.  So, I find a set of games I want to use sort them how I like and then write out another XML file for the middle-ware program that generates the files needed for the UI. 

This XML file I create contains all the information needed by my second app, which generates screenshots and gameplay movies for the front-end.  (My front-end shows gameplay movies with sound instead of screenshots.)

The front-end uses the XML to know how to display the systems, categories and game pages & games.  Navigation information and which games to show where, etc.

Eventually I will merge the menu editor and the middle-ware that does the file creation into a single application. 

My system works PERFECTLY for me.  It will not work perfectly for anyone else.  This is the secret of software that few people understand.  It is VERY difficult to make a single piece of software that scratches every "itch" of every user.  I would say that it is impossible, actually.  The only software that actually even comes close would be a compiler or software development tool, and even with the tools to build almost anything you could need, they still fall way short.

My point: split the problem into parts, tackle them each on your own, for your own reasons.  The community does not need more front-end software.  Make it for yourself.

Also, you don't need DirectX or OpenGL knowledge; if you're on Windows, just use WPF.  The WPF framework accelerates that for you.  My UI is butter smooth.

[Felsir]

Yeah, it was not my intention to write a frontend to do all and everything. There are a few specific things I want to do (for example, the gamelist should adapt if additional gamepads are connected to the USB ports so 4 player games will show up and some console style games where my controlpanel wouldn't work).

I like the idea of having an menu editor outside the frontend. Initially I was planning to manually edit XML files but it might be to cumbersome or prone to errors.

[sandheaver]

Yeah, it was not my intention to write a frontend to do all and everything. There are a few specific things I want to do (for example, the gamelist should adapt if additional gamepads are connected to the USB ports so 4 player games will show up and some console style games where my controlpanel wouldn't work).

I like the idea of having an menu editor outside the frontend. Initially I was planning to manually edit XML files but it might be to cumbersome or prone to errors.

Depending on the platform, framework, and language you're working with, you can automate most of that stuff pretty easily. 

Manually editing XML is error-prone, but writing a menu editor is, too.  Writing a menu editor is a lot more fun, though, and the errors a lot less mundane.

[Felsir]

I'm an experienced C# programmer, and I have already made some code snippets as proof of concept  (the USB gamepad detection, some graphics and launching programs from code). So I need to combine those parts basically.

It's launching the various emulators that I'm not sure about- basically if I can launch it from commandline I'm good. And that is also the thing that I'm worried about the most, I fear that it is not as simple as that (or is it?)

[sandheaver]

I'm a semi-experienced C# programmer.

It's launching the various emulators that I'm not sure about- basically if I can launch it from commandline I'm good. And that is also the thing that I'm worried about the most, I fear that it is not as simple as that (or is it?)

Pretty much.  Use MESS where you can, where performance allows and where the games you want are supported.

System.Diagnostics.Process and System.Diagnostics.ProcessStartInfo.

[Felsir]

Indeed, I use System.Diagnostics to run the emulators. Good to know that I'm on the right track 

[sandheaver]

I'm pretty sure you know C# better than I.  You won't need any help from me.

That said, if you would like to see the code for my unfinished front-end, please let me know.  I have a Microsoft Team Foundation account and my code is in there.  Much of it is still hard-coded and I am not as far along as I'd like to be, but if you learn something or are willing teach me something, then I'll add your account and you can have at it.

[Felsir]

Lesson learned:
If you have a frontend that uses the GPU for drawing fullscreen, keep in mind that this might "lock" the GPU exclusive to your frontend. This way when you launch an application it might be unable to "claim" the GPU resulting in a fatal exception.

I solved it this way: I made a fullscreen borderless window. This appears as a full screen application but it doesn't lock the GPU.