Open-source front end

[Jonathan_the_Red]

Folks--

I'm sure I'm not alone in being confused by the wide variety of front ends available. While it's good that there's competition so front ends are constantly improving, I like the MAME model of having a single, open-source standard, with lots of developers contributing to improve it.

I'm a professional software developer (have been for seventeen years) and would be happy to contribute my time to an open source front end project. Would any of the front-end developers here be willing to join such a project and contribute their code to the effort?

[Mike]

Unlike mame though the frontend means different things to different people. First off you have 2 groups ones that want an FE to run from an arcade machine and ones that want to run on thier home computer. So say we say we only care about people who have arcade machines because the others aren't serious enough for us. So Even then we have different sub groups. For people who want something really pretty you have like emulaxian. You also have people who hate that because it's not fast enough or it is just too pretty it's not usable for them. And it keeps going on and on. I think while certain FE's like arcadefx and RD could be combined into one super FE for the most part everyone is bringing so many different types of things to the table it would be impossible to combine them into one project.

[Jonathan_the_Red]

Good points, Mike, but I don't think they're insurmountable.

Skinning is the solution to differing expectations for appearance. We could certainly have a skinning layer that supports pretty graphics or 3D animations, while imposing little overhead when those features are disabled.

What are the primary differences in requirements for a front end for home computers and a front end for arcade cabinets?

[Mike]

The user on the arcade cabinet is using keystrokes only. Also all they usually want the keystrokes to be close to the mame defaults. Where the home user is using a mouse and probably a joystick to play the game. Also the guy with the arcade doesn't want a windows feel to the frontend. Where the other guy would probably rather have a windows feel so it doesn't go to full screen.

[ArcadeFX]

ArcadeFX is one frontend that can be use in a cabinet and on a home PC just as easy.  Full keyboard control and arcade controls.  It is skinable so you can do what you want with.

I don't plan to make it Open any time soon.  The dev. tool I am using to create AFX cost about 2600 retail.  :-/

[Mike]

Just out of curiosity what are you using to develop it with?

[Lilwolf]

Ed's using Authorware

And mine is opensource and java.... just it hasn't been released in a long time.  the next version in a few weeks should be more usable by everyone.

It's also a lot cleaner code, skinnable, ect.

And as a last thing.  All the FE authors that I read about on this board are VERY nice and VERY open with each other and sharing ideas, code, and everything.  If we were all writing in the same language (non of us are currently) I think we would probably be writing one custom FE instead of a few.

We are also long term planning with each other.  Some really cool idea of combining code are going around behind the message boards right now.  I'm hoping that some make it out for everyone to use.

last.  I wrote mine for me.  And I think we all do.  If nobody ever installs jfront I'm still happy.  But as an after thought, I am trying to make it workable for others.  I've added a few options that I can't use (screen rotation, ect), but most of them where because I wanted my frontend to run a very specific way.  I'm VERY glad if anyone can use my code for their front end, but really hope they play with the settings to make it 'theirs'

[mr_spark1e]

There are also the DOS vs Windows users.  I prefer to run straight DOS in my cab, and therefore find AdvanceMame the best front-end there is (although I also like ArcadeOS).  It is also open-source.

If I was running Windows in my cab, I might think differently.

[Lilwolf]

That is an issue.  Since all of us who are writing some of the newer frontends have decent computers in our cabinet, they each need a decent machine behind them.

Emulaxian needs 1ghz + a 32mg video card to run super smooth.  

[Lilwolf]

One more note...

I'm still hoping that Howard will opensource a few parts of his  

Maybe even make some middle-end tools (programs that do something and run something else)

[Mike]

ArcadeFX is one frontend that can be use in a cabinet and on a home PC just as easy.

[Jonathan_the_Red]

Hrmph.

To tell you the truth, I haven't looked at any of the major front ends in quite awhile. This was partly because my cabinet isn't quite ready yet, but mostly because I was dreading trying to evaluate the five or so well-liked front ends out there. I'm almost sure that I'll try one and think, "This one would be perfect, if not for such-and-so", and try another and think, "This would would be even more perfect, if not for this-and-that", and try a third and think, "I could live with this one, if only it had Feature X which I really need."

I think I'm just gonna make my own, and I will open source it. Anyone who wants to contribute to the project is more than welcome. In the next few days, I'll start the project on SourceForge. As far as language goes... well, I've been meaning to play around with .NET some more, and this is a good learning opportunity. For those not aware, .NET is a cross-language (but single-platform at this point and probably for the foreseeable future) framework, so you can write in any of several different languages. I'll probably do my parts in C#, again primarily for the learning experience.

Yes, using .NET will require a relatively modern computer... but as I said in a reply to JLR2000's unfortunate experience posted to the general board, modern computers are getting less and less expensive all the time. If you're running DOS on a Celeron 300, this won't work for you.

In the meantime, I'm wide open to ideas for a feature set. What I've got so far:

• Extremely flexible skinning -- I want to make it possible to completely modify every single aspect of the UI. This includes of course multiple resolutions and a choice of horizontal/vertical orientation.
  
• Extremely configurable input, with the ability to support mice, keyboards, joysticks, etc.
  
• Ability to run scripts on game launch/game close.
  
• Ability to organize games into favorites lists
  
• Ability to display a menu of most-recently and most-often played games
  

Anything else? If there are any features that you've wanted but current front ends don't have (or if there are any features the current front ends do have that you think are absolutely essential), please let me know.

Please note, absolutely no offense intended to the current front-end developers. They've done some fine work and produced some outstanding code. But I really think the hobby would benefit from having a mutual code base to which anyone could contribute.

[Mike]

RD has pretty much everything you mentioned. He's suppose to have a new version out here soon. He acts like it's real soon so maybe will see it sunday night.

[Jonathan_the_Red]

RD has pretty much everything you mentioned. He's suppose to have a new version out here soon. He acts like it's real soon so maybe will see it sunday night.

I'm sure he probably does. But that's not the point.

Look, suppose someone installs RD, uses it, loves it, etc., but then a few months later thinks of a feature that would be really useful. Right now, his only option is to ask Howard for the feature and then wait until Howard (who, after all, is not getting paid for this and surely has a life ) gets around to it. Or worse, one of the other front end developers puts the feature in his front end, and now the guy has to switch front ends, with all of the configuration headaches that entails.

If on the other hand there were a good open source front end, he could code the feature himself and check it in, or ask any of several developers to get around to it. The feature would probably get implemented sooner, and in the current front end so he wouldn't have to reconfigure.

Open source is a Good Thing. Believe me, I'm not thrilled to be adding yet another option to the many front end choices out there, but I really think it would be good to have an open source option available.

[Howard_Casto]

Actually you'll see it tonight.     As for all the issues raised, your all correct in your seperate views.  Since the general public dosen't know what's going on behind the scenes I thought I would take this opportunity to let eveyone in on our "grand scheme"    

Lilwolf, )p(, and myself have been talking back and forth for some time now about cooperation between our developments.  As Lilwolf stated, what we've been working on is making our repective fe's more modular so that we could create some sort of "uber front-end"  that had elements of all three inside.  Me and )p( have been working for a few months on taking his 3d-cab element and adding it to rd via a director active X plugin.  We've had mixed success so far, but I'm sure eventually we'll be able to come up with something.  I seem to be really good on the "finding wierd code and using it to do things your not supposed to be able to do" department, and once Lilwolf ports to C, he'll definately have the "stable easy to work on code" department down pat.  Ed is also a very good graphic artist, and we'd love to have him on board for interface design if we ever get all of this stuff working together. Boris has be scare lately, but he's always up on functions, and protocols and what-not so I'm sure he would have some valuable knowledge to share as well.

I wil definately be making some components of rd external as time goes on as well... it's easier for me to deal with code wise and it gives the benefit of other fe developers not having to re-invent the wheel.    

I don't see us all dumping our respective projects to work on one big project anytime soon, but I think this cooperation will continue until we get to the point that the only difference between afx, jfront, aplayer, emulaxian, rd, ect is game support and the "feel" of the interface.  

As for releasing the source code..... I personally intend to do so, but not until I feel that it's "ready."  I really don't think it's a good idea to have several versions of the same front-end floating around for confusions' sake.  (Think about what happened to final burn after the source was released for it.)  Once I feel that I've added all the features that I want to add and that I'm capable of adding, I'll glady turn it into an open source project and let other, more experienced programmers work on it with me.

I might be a big jerk though and only allow variants of rd to be released publically if they have my seal of approval though.  (Similar to linux's open-source agreement.)  

Anyway, I hope that puts your mind at ease... it'll take some time, but we're getting there.  

One last note.... dos is a totally different animal(one that's getting old and needs put to sleep), so I won't go there.  In mame terms coding in dos makes sense since mame is simply a big code intrepreter, but in fe's it's a b**ch to code for.  so there will always be two main factions dos users and win users.

[Mike]

I'm feeling like a kid in a candy store. The new emulaxian is out and RD and AFX will be out this weekend. I've read what everyone is adding and I think things will be at a point where the windows arcade FE's will definately have what most users want and cause everyone but the guys chugging along on the 486DX2 to ditch arcadeos and go the windows route. Thanks to all of you guys for making my arcade better.

[simpleman46]

There's been so much exciting FE development lately!  Fantastic!  
It's been great to see the friendly competition develop between the authors.  It makes me wonder what cool feature will be added next.
On the other hand, the thought of all these brilliant FE authors working together gives me goosebumps.  I can't wait to see what sort of creation will appear.

Keep up the great work guys!  Frontend developers are definitely the strong backbone of the emulation community!  

[SirPoonga]

Folks--

I'm sure I'm not alone in being confused by the wide variety of front ends available. While it's good that there's competition so front ends are constantly improving, I like the MAME model of having a single, open-source standard, with lots of developers contributing to improve it.

I'm a professional software developer (have been for seventeen years) and would be happy to contribute my time to an open source front end project. Would any of the front-end developers here be willing to join such a project and contribute their code to the effort?

Hmmm, would have to be done in ansi c (or c++).   So we can mod it for linux, windows, or mac.

It;d be a cool idea, GPL it.

[SirPoonga]

There's been so much exciting FE development lately!

[)p(]

To jonathan:
Emuwizzard is opensource and is allready on sourceforge! So you may join that project. It is also in my opinion one of the most efficient and effective fe's...

The source to Emulaxian is normally available but now with the 3d arcade it is just to experimental to release yet.

Because flash itself can be integrated easily by most other fe's the only part of Emulaxian that really could be useful of to others is the 3darcade...when I have finished it the way I want it to be I will make it available as a shockwave object that can be dropped into other fe's...it should work with authorware, vb, c etc...
And maybe by that time mine will be outdated allready by an even better 3darcade fe...hehe...

Peter

[Dave Dribin]

Folks--

I'm sure I'm not alone in being confused by the wide variety of front ends available. While it's good that there's competition so front ends are constantly improving, I like the MAME model of having a single, open-source standard, with lots of developers contributing to improve it.

I'm a professional software developer (have been for seventeen years) and would be happy to contribute my time to an open source front end project. Would any of the front-end developers here be willing to join such a project and contribute their code to the effort?

Game Launcher is an Open Source (GPL) front end hosted on SourceForge.  It already supports a few of the features in your wish list.  Skinning is one feature I would love to add to GL.  It's been on the todo list for ages, but I'm constantly getting dstracted by other projects/work.  

I've been a little disappointed in the developer involvement as I've received only one set of patches (for joystick support) in over 2 years of development.  GL is based entirely on other Open Source software so it should be a good candidate for other developers.  Occasionally, I wonder  why GL hasn't attracted more developers.  Maybe a FE just isn't a good app to Open Source.  Maybe because GL was orignally DOS-based it scared off a lot of people.  Maybe I scare people.  Who knows.

BTW, GL is written almost entirely in C++ which is actually a much better choice than C# in terms of portability.  In theory GL should run under DOS, Windows, Linux, and even BeOS.  I've run preliminary versions under Linux for a while now.

In any case, if you'd be interested in contributing, I'd be interested in helping make that work.

-Dave

http://www.dribin.org/dave/game_launcher/

[Howard_Casto]

There's a reason why alot of us choose not to use c++ or a more "portable"  coding language.  Mainly because of rapidity of development.  Now mind you I'm not as good a programmer in C so that has a little to do with it, but as far as the graphical elements of my fe are concerned, I can redo stuff in about 5 min in vb as opposed to 50 min in c++. Director and authorware are similar in their rapidity of devlopment in that graphical functions are often built in, which means no extra coding necessary.  Java has built in database support (really good support)  as well as built in support for those png files, which I'm sure had something to do with lilwolf's choice.    

Emuwizard is and incredible piece of software, but you notice that it's not updated very frequently.  Keep in mind also that the author of emuwizard didn't start out fom scratch either, but took code from an old cocktail fe and modded it.    

I've though of porting my code to c++ many times, but the fact of the matter is, unless development slows down to a crawl, it would only make things slower at this point.  

As for gamelauncher, it used to be my fav fe, but quite frankly, it's extremely dated.  Emuwizard has all of the features of gl, and is written similarly, so it would be silly to work on gl and try to "re-invent the wheel"  when the code for emuwizard is already available.  

[SirPoonga]

There's a reason why alot of us choose not to use c++ or a more "portable"

[Dave Dribin]

Ok, I don't want to start a language war here.  I brought up C++ due to the fact Jonathan mentioned .Net and C#.  I also think you are off the mark on C++ being slower for development, especially when you compare it to similar languages such as Java and C#.  I do Java coding at my day job, and yeah Java is a cleaner language, but it's not much faster to code Java than C++.  As for PNG libraries, there's a very good Open Source one written in C, which is easily accesible from C++.  And yes, Java does have excellent database support.  But GL does not require a database, and I hope it never does.

I also take offense to GL being called "extremely dated".  GL is downloaded  just as much now as it has in the past.  You compare GL to EmuWizard, but they really are quite equivalent in terms of functionality.  In fact, GL is up to par with features of many other front ends, with the exception of 3D support and skins.  And skins is on the Todo List.  The biggest thing holding GL back is time for me to work on it.  And *that's* where I was hoping Open Source would help out.  Unfortunately, that never happend.

Here's a question for ya.. if GL was your fav FE, why'd you re-invent the wheel and start your own project rather than extend GL to add the missing functionality?  That's supposed to be the beauty of Open Source.

-Dave

[Howard_Casto]

Gl was my favorite fe when i used it in combination with party-on.... although Game Launcher supports jsut about any emu, the way you go about adding other emus was always cumbersome.  I realized that the only way to make supporting multiple emus simple to the user was to take m$'s approach and integrate the launching  those emus into the fe automatically rather than reading how to do it from a script file.  This became apparent to me after I couldn't find any pre-made script files even though they were realitively easy to make.  The idea of letting users configure stuff for themselves was a good one, but apparently none of the users at that time were willing to help out by posting scripts they had made.  

When I realized how much I would have to change to make it the way I wanted it, it just seemed simplier to start from scratch.  

And you shouldn't be offend to the fact that c is slow for development.  It is, that's a fact, but that's not necessarialy a bad thing.  I wasn't taking c# and vb.net into account as they aren't main-stream yet, and I can't really comment on them as of now.  Vb is deisgned for rapid development of windows-based applications as is director, and as I'm beginning to learn Authorware is as well.  Java is rather slow for development, but as you notice lilwolf is switching over to C++ which will be more main-stream.  

And as I said I love gl, I don't know how you could take offense when I said it's outdated.  It at least needs snap/flyer/cab/marquee/screenshot(it has that, but i mean all 5 displayed at once)  and naviagtion by said elements to be up to par with the newer emus.  As you said emuwizard is very similar in terms of features, but it has these keys features that gl lacks.  To do those elements right sometimes requires ALOT of code, so I suggested anyone wanting to work on open soruce should look in emuwizard, which has those elements already.  

I don't want you to be upset with me because I really do like your fe, it's just it's not been kept up to date with the others, which I know first-hand can be a difficult thing to do.  Perhaps youd could work with the author of emuwizard and combine fe's... that'd be sweet!

[Robert Flemming]

I've been working on an opensource frontend written in Python for a little while now.  I haven't really made any sort of announcements about it because it's still a work in progress.  But since you asked I'd be a idiot to turn down potential help with it.  It's called pyReCADE and you can find out a little more about it at http://pyrecade.sourceforge.net.  Since it's written in Python it should in theory run on Windows, Linux, and many others though it's being primarily developed for use on a Linux based MAME cabinet.  It's not ready for mass consumption, but those who have been looking for a arcade style frontend for Linux should check it out.  Kudos to Raging Dragon, ArcadeFX, and others but I haven't used Windows in 4 years or so and no matter how cool your frontends look, my MAME cabinet isn't going to use it either  Feel free to offer suggestions and anyone who wants to hack on it please do I could use the help.  I'm more than happy to give you CVS access if you want to contribute.  Take Care

Robert

[Dave Dribin]

And you shouldn't be offend to the fact that c is slow for development.  It is, that's a fact, but that's not necessarialy a bad thing.

I'm not offended that you think C/C++ is slow for development.  It's not my language.  I disagree with you, though, since making such blanket statements of "fact" like that are very hard to justify.  VB is better than C++ in some cases and C++ is better than VB in others.  I'm a big believer in using the right tool for the job.  If I were to start a FE for MAME today that needed to run under DOS, Windows, Linux, and Mac, I would still pick C++ over any other language out there.  Heck, even if I dropped DOS as a requirement, I would still seriously consider C++.  I think C++ would be a pretty strong contender given the plethora of graphics APIs to use, such as Allegro, SDL, and OpenGL, that make development easier.

And as I said I love gl, I don't know how you could take offense when I said it's outdated.  It at least needs snap/flyer/cab/marquee/screenshot(it has that, but i mean all 5 displayed at once)  and naviagtion by said elements to be up to par with the newer emus.

Just because GL is missing these features does not make it "extremely outdated."  It makes it different, and diversity is a good thing.  I don't find these features a big deal.  I just want screen shots.  BTW, adding snap/flyer/cab/marquee/screenshot to GL would probably be a couple days of coding, far easier than starting your own FE.

Perhaps youd could work with the author of emuwizard and combine fe's... that'd be sweet!

I don't think GL has reached the end of its life yet, so it will not be merged in the foreseeable future.  On the contrary, if there are developers who would love to make a great front-end even better, please contact me!

-Dave

[Howard_Casto]

Just because GL is missing these features does not make it "extremely outdated."  It makes it different, and diversity is a good thing.  I don't find these features a big deal.  

I couldn't agree with you more about needing diversity, but lack those featues does, indeed make it outdated.  I'm not saying by any means that these features are necessary, but now they've become expected of a typical cabinet oriented fe.  It's like if someone came out with a new os that resembled windows 3.11  That os could be techinically superior and even give better performance in some cases, the majority fo the public would still think it's "outdated".  If you really are concerned about keeping gl up to date and you can add those features as easily as you say, I would recommend adding them upon the next release.  I know YOU don't care about those feautres, but everyone else does, including alot of developers.  You would have a better chance of getting people to add to your source if you had these things to begin with.  I'm jsut trying to give some friendly advice since you seem to want others to pick up your source.

As for the C++ stuff, you can call it fact or whatever, but all I know is M$'s official description of VB goes something like "A beginners language for the rapid development of desktop applications."  and for c++ it's something like "For the robust completion of complicated applications and games."  

Now considering the same company made both programs and they desgined one to make it easy to put out applications quickly and the other to make longer, more complicated programs, which one do you think is faster to develop in?  I never said one was better htan the other, they are just different, and one is geared for speedy development, while the other is not.

[Lilwolf_at_home]

About the languages.  What makes something fast to develop or not isn't really the language, its the apis that go with it.  (minus one option)

The apis.  Can you put an image on the screen in one method call?  Do you have all the basic types at your disposal (hashtable, vectors, lists, ect) so you don't have to write your own.  

Do you need to hack everything.  I spend a great deal of time because java doesn't support before jdk1.4 windows without the border without doing wierd stuff, using nonstandard objects.

One of my big pet pieves against c++ (but not c++, MFC) is you have to have some consistancy.  There are like 6 different string options in MFC.  And they are all incompatible, and when you use someone elses object, you need to convert all your strings to what they take.  apsolutely stupid microsoft.  I can't even imagine how they did it (other then had 3 teams not talk to each other and build their own... ie stupid)

Last, garbage collection and pointers.  Java issue here (since I think VB makes you deal with garbage collection yourself).  Java, you build an object and use it.  As soon as nobody references it, it goes away.  No ints cast to pointers that cause blue screens of death!  No incrementing a pointer at all (use a list, they are bound checked).  IE, the stupid hard to find errors are removed.  You also don't have to deal with destroying your object, and finding others where looking at it.

Then there is the Object Oriented bits.  Well, microsoft doesn't have a single one.  They fake it, but really doesn't have one.  SmallTalk is an OO language.  This means that you have an object, and you can call methods on it.  You never know what object your really have, its just an object.  The trouble with this is almost every error is a runtime error (ie the compiler doesn't check a damn thing) so you find problems 6 months after release.  Then there is C/C++/VB/Pascal.  These check everything.  You have a Fred object that knows 5 methods that you can call.  It can be a subclass of 2 different objects and know 10 other methods from that... but at compile time you know everything.  This is nice since it cuts down on runtime error, but it also means that you need to have everything at compile time.   Then there is java.  You can have a Fred object like above and its checked like c++.  You can also recieve and object that is defined to know 3 methods.  You don't know what the object is or who created it, but you know it knows 3 methods.  You can also get a blank object and ask it what it knows, and call methods from that.  So you can send me an object that you wrote after mine, and my object can say, do you know the "paint" method that takes a graphic object?  you do!  Great, call it with this graphic.   This is why javabeans are so much easier to use then activeX components.  It also allows java applications to be expanded afterwards by others easily when you want.

well, I'm sure theres other things to consider also.  

[Mike]

The only problem I see with java is with a cabinet you want stability and java applications have a tendency to hang and not shutdown properly on windows machines no matter how well written they are. I agree with howard that VB isn't a bad way to go. One it's quick to develop in, two anyone can learn to code in it and add stuff, three there is a ton of preexisting plugins for it.  C++ gives you the greatest flexibility but it does take longer to develop in and for what most people want I don't know if it's even worth it. Because an FE is a program running shell commands people have added bells and whistles but when you break it down to it's essential functionality thats what it is. So personally if any project was going to be opensource I'd like to see it be in VB so I can take an hour and change it to add the functionality I might want not spend 2 days adding it in C++.

[Dave Dribin]

About the languages.  What makes something fast to develop or not isn't really the language, its the apis that go with it.  (minus one option)

I couldn't agree more, well said!  Which is why choosing a language is essentially a design decision and should be done  based on the requirements of your project.

I think what makes VB faster, if your making a desktop app, is really the IDE and the "visual" part.  It's much easier to create menus, dialog boxes, and other GUI components from the IDE.  If I were going to build a traditional windows app, with File, Edit, etc. menus, a preferences panel and some dialog boxes, then, yes, VB, probably would be faster (though VC++ does have a good visual wizard, I hear).

However, a FE like Game Launcher has almost no GUI components (or certainly doesn't need to).  In fact, no traditional GUI was a design goal for GL.  So what does VB really buy you at that point?  Like Mike said, a FE is basically a pretty wrapper around shell commands.  C is pretty darned good at shell commands.  I mean, how much "faster" could you write code to stick an image and some text on the screen in VB over C++?   It's not like it's 5 lines of code vs. 500 to do the same task.  It's probably fairly equivalent.  And given its equivalent, choosing a language then comes down to other issues, such as portability (target environments), developer familiarity, cost of tools, and the scope of the application.

Blanket statements like "Language X is faster/better/smarter/etc. than Language Y" just aren't true in the real world.  And *that's* a fact.

And one other thing... don't listen to Microsoft's marketing description of the the language.  In fact, don't listen to the marketing departments of most any company.  At the very least, take what they say with a very large grain of salt.

</soapbox>

-Dave

[)p(]

I think what makes VB faster, if your making a desktop app, is really the IDE and the "visual" part.

[Dave Dribin]

I couldn't agree with you more about needing diversity, but lack those featues does, indeed make it outdated.  I'm not saying by any means that these features are necessary, but now they've become expected of a typical cabinet oriented fe.

Just because you expect/require these features in every FE does not mean the rest of the world does.  Like I said earlier, GL is just as popular today as it was a year ago, probably more popular.  That's not a trend I would expect an "extremely outdated" FE to have.

If you really are concerned about keeping gl up to date and you can add those features as easily as you say, I would recommend adding them upon the next release.

Ok, I haven't even written a line of code for GL in the last two months.  When I finally *do* get a chance to code, it's not gonna be those features.  I have a list of *other* features that I want to get in first.  So you see, it all comes down to priorites.

I know YOU don't care about those feautres, but everyone else does, including alot of developers.  You would have a better chance of getting people to add to your source if you had these things to begin with.  I'm jsut trying to give some friendly advice since you seem to want others to pick up your source.

That's just utter BS.  If "everyone" cared about those features, GL wouldn't be downloaded and I wouldn't get any support questions about it.   Do you think that Nicola cares about all the games added to MAME?  Do you think that Linus cares about all features added to Linux?  Do you think that Larry Wall cares about all features added to Perl?  Do you think that Guido van Rossum cares about all features added to Python?  These projects didn't have all the features to begin with when other developers started contributing.  You just don't "get" Open Source.

BTW, I don't want anyone to pick up GL.  I would like others to contribute to it.  If you want marquees and flyers... add it!  If you want 3D pictures flying around.... add it!  If you want MAME to support <insert your favorite game here>.... add it!  That's how Open Source works.  Developers scratching an itch.

I'm not a commercial entity try to make profits and grab market share.  GL is just my way of giving back to the MAME community who wrote one of best programs ever written and then gave it away, source code and all, for free.

-Dave

[Mike]

Since you brought up linux. If you want to write an FE in a similar way. Everyone truthfully needs to quit working on what it looks like and build the back end functionality into an an object that a nice pretty frontend object can access. That is the only peice that would be worth creating as open source. If someone wanted to create an object that could sort the roms, send back information about the roms and launch the roms I'd be willing to contribute to this. Information could be the appropriate screenshot, year or whatever other data would be needed. Then anyone could use it and quickly develop a gui to display it all. Also this way you could also use objects like the 3-d arcade in your gui.

[flemming]

If someone wanted to create an object that could sort the roms, send back information about the roms and launch the roms I'd be willing to contribute to this. Information could be the appropriate screenshot, year or whatever other data would be needed.

I'm with you on this one.

[)p(]

Since you brought up linux. If you want to write an FE in a similar way. Everyone truthfully needs to quit working on what it looks like and build the back end functionality into an an object that a nice pretty frontend object can access. That is the only peice that would be worth creating as open source. If someone wanted to create an object that could sort the roms, send back information about the roms and launch the roms I'd be willing to contribute to this. Information could be the appropriate screenshot, year or whatever other data would be needed. Then anyone could use it and quickly develop a gui to display it all. Also this way you could also use objects like the 3-d arcade in your gui.

Yeah I would love to see such a database like object if it is generall enough. It would really be great if I and others who like to focus on other aspects of the would not have to bother with that part of the frontend anymore...
Also as mentioned before the 3darcade of Emulaxian will be available to other fe's if they want it...

Peter

[Mike]

I think it could be more than a database. I think it could contain more functionality than that. It could be like an ocx object you include. It could run the roms, sort them by category or year and include something to hide the mame screen when loading roms or at least display a now loading picture over it. Then all you have to do is create the gui. It just needs to be flexible enough to work for everyone.

[Dave Dribin]

Since you brought up linux. If you want to write an FE in a similar way. Everyone truthfully needs to quit working on what it looks like and build the back end functionality into an an object that a nice pretty frontend object can access. That is the only peice that would be worth creating as open source. If someone wanted to create an object that could sort the roms, send back information about the roms and launch the roms I'd be willing to contribute to this. Information could be the appropriate screenshot, year or whatever other data would be needed. Then anyone could use it and quickly develop a gui to display it all. Also this way you could also use objects like the 3-d arcade in your gui.

Game Launcher actually has a very good internal architecture that tries to follow the MVC pattern.  The common part you're talking about is the model:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/glaunch/glaunch/model/

It doesn't do the launching of the game, as that is very platform specific, and even downright cryptic on some platforms (um... DOS).  But it does provide things like scanning for ROM files, sorting games by their title, and constructing a proper command line for a game.  I never really thought that this would be of use to others, but if there is interest, this part could be reused on its own fairly easily.  There isn't a lot of coupling to the rest of GL in there.

I would disagree that this is the only part worth creating as Open Source, though.  I think that a FE worked on by two or three developers would be very productive.  A FE isn't a huge project, so more than two or three developers would probably just step on each other, but a FE is definitely a big enough task to have more than one developer.

-Dave

[Jonathan_the_Red]

One word: XML. Anyone wanna take a stab at coming up with a schema for game definitions?

[flemming]

One word: XML. Anyone wanna take a stab at coming up with a schema for game definitions?

Like I said a few messages back, I'm all for it.  Even if none of the other fe developers choose to use it, it's still something I'd like to use with pyReCADE (in place of the text file I now use).  I'll try and spend a little time working on a draft of what I'd like to see, and if other people want to throw some weight behind it even better.

Robert