Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Open-source front end  (Read 21467 times)

0 Members and 1 Guest are viewing this topic.

Jonathan_the_Red

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 39
  • Last login:Never
  • Cab-buildin' fool
    • Jonathan's Cab-in-progress
Open-source front end
« on: March 01, 2002, 09:20:33 am »
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?
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #1 on: March 01, 2002, 09:39:34 am »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Jonathan_the_Red

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 39
  • Last login:Never
  • Cab-buildin' fool
    • Jonathan's Cab-in-progress
Re: Open-source front end
« Reply #2 on: March 01, 2002, 09:43:16 am »
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?
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #3 on: March 01, 2002, 10:04:27 am »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

ArcadeFX

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
  • Last login:November 10, 2004, 11:16:56 pm
  • All the Dude ever wanted was his rug back!
    • ArcadeFX
Re: Open-source front end
« Reply #4 on: March 01, 2002, 10:14:42 am »
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.  :-/
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #5 on: March 01, 2002, 10:20:32 am »
Just out of curiosity what are you using to develop it with?
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re: Open-source front end
« Reply #6 on: March 01, 2002, 10:43:16 am »
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'

« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

mr_spark1e

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 35
  • Last login:February 25, 2005, 01:18:50 pm
  • Will I Ever Grow Up?
Re: Open-source front end
« Reply #7 on: March 01, 2002, 10:54:26 am »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re: Open-source front end
« Reply #8 on: March 01, 2002, 11:19:29 am »
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.  
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re: Open-source front end
« Reply #9 on: March 01, 2002, 11:28:10 am »
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)
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #10 on: March 01, 2002, 12:21:45 pm »
Quote
ArcadeFX is one frontend that can be use in a cabinet and on a home PC just as easy.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Jonathan_the_Red

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 39
  • Last login:Never
  • Cab-buildin' fool
    • Jonathan's Cab-in-progress
Re: Open-source front end
« Reply #11 on: March 01, 2002, 12:52:55 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #12 on: March 01, 2002, 12:56:05 pm »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Jonathan_the_Red

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 39
  • Last login:Never
  • Cab-buildin' fool
    • Jonathan's Cab-in-progress
Re: Open-source front end
« Reply #13 on: March 01, 2002, 01:15:33 pm »
Quote
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Open-source front end
« Reply #14 on: March 01, 2002, 01:33:40 pm »
Actually you'll see it tonight.   ;D   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"   8)  

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.)  :D

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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #15 on: March 01, 2002, 03:26:18 pm »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

simpleman46

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:December 29, 2003, 10:54:47 pm
  • Nummy Goodness
    • From Rocks
Re: Open-source front end
« Reply #16 on: March 01, 2002, 08:08:10 pm »
There's been so much exciting FE development lately!  Fantastic!   :D
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!   ;D
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Open-source front end
« Reply #17 on: March 01, 2002, 09:27:57 pm »
Quote
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Open-source front end
« Reply #18 on: March 01, 2002, 09:29:40 pm »
Quote
There's been so much exciting FE development lately!
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re: Open-source front end
« Reply #19 on: March 01, 2002, 11:10:01 pm »
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Guest
  • Trade Count: (0)
Re: Open-source front end
« Reply #20 on: March 02, 2002, 11:43:02 am »
Quote
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/
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Open-source front end
« Reply #21 on: March 02, 2002, 01:00:37 pm »
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.  
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Open-source front end
« Reply #22 on: March 02, 2002, 02:44:01 pm »
Quote
There's a reason why alot of us choose not to use c++ or a more "portable"
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #23 on: March 02, 2002, 03:34:25 pm »
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Open-source front end
« Reply #24 on: March 02, 2002, 03:57:41 pm »
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! :D
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Robert Flemming

  • Guest
  • Trade Count: (0)
Re: Open-source front end
« Reply #25 on: March 02, 2002, 04:07:46 pm »
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #26 on: March 02, 2002, 05:58:09 pm »
Quote
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.

Quote
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.

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


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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Open-source front end
« Reply #27 on: March 02, 2002, 08:04:07 pm »
Quote
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf_at_home

  • Guest
  • Trade Count: (0)
Re: Open-source front end
« Reply #28 on: March 03, 2002, 05:56:15 am »
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.  
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #29 on: March 03, 2002, 06:06:29 am »
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++.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #30 on: March 03, 2002, 08:10:36 am »
Quote
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re: Open-source front end
« Reply #31 on: March 03, 2002, 08:38:25 am »
Quote


I think what makes VB faster, if your making a desktop app, is really the IDE and the "visual" part.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #32 on: March 03, 2002, 08:41:23 am »
Quote
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.

Quote
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.

Quote
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #33 on: March 03, 2002, 08:55:19 am »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

flemming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • Last login:October 15, 2002, 11:02:11 am
    • pyReCADE
Re: Open-source front end
« Reply #34 on: March 03, 2002, 09:23:28 am »
Quote
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(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re: Open-source front end
« Reply #35 on: March 03, 2002, 09:26:29 am »
Quote
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #36 on: March 03, 2002, 09:31:52 am »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #37 on: March 03, 2002, 09:44:18 am »
Quote
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Jonathan_the_Red

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 39
  • Last login:Never
  • Cab-buildin' fool
    • Jonathan's Cab-in-progress
Re: Open-source front end
« Reply #38 on: March 03, 2002, 10:23:18 am »
One word: XML. Anyone wanna take a stab at coming up with a schema for game definitions?
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

flemming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • Last login:October 15, 2002, 11:02:11 am
    • pyReCADE
Re: Open-source front end
« Reply #39 on: March 03, 2002, 11:13:13 am »
Quote
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #40 on: March 03, 2002, 11:34:49 am »
Quote
One word: XML. Anyone wanna take a stab at coming up with a schema for game definitions?


If your doing this just for MAME, take a look at the output from the "-listinfo" option of mame.exe before writing your own XML schema.  It gives lots of information and its fairly easy to write a parser for it.  It may be all you need.

If you're doing this for games other than MAME (i.e console games), I could see some possibilities for XML.

-Dave
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re: Open-source front end
« Reply #41 on: March 03, 2002, 11:49:48 am »
I am all for it but make it as general as possible at least arcade, pinball and console games should be supported...

lets see...this is what I would really like to see...a database like app that can do
-records with a large number of columns where the labels can be set to anything.
-flexible selecting of records to be send to the frontend
-searching directorys for available games and check the crc's
-searching directorys for available games and add them to the database (mostly for console games)
-lots more... ;D


peter
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Open-source front end
« Reply #42 on: March 03, 2002, 03:38:43 pm »
As usual guys I'm a few steps ahead of you.  ;)  After talking with lilwolf a bit I've decided it might be a good idea to "de-intergrate" cetain elements of rd.  I've been thinking about it and the biggest hassle of any fe is searching for the roms and giving the zip files "real" names.  So keeping that in mind I thought a good project for myself would to make a "scanner" app that simply searches paths you've chosen, and compares files in said paths to a rather generic, but very versitile database.  
The database fields would be something like this:

filename|extension|Real Name|Clone|Emulator(s)|path|misc|

I haven't even started yet, so if anyone thinks they can do it in xml or whatever, that'd be great.  We need to make it real simple though, like you send it a lists of paths, and it spits out an array containing the above fields all alpahbetized and ready to go.  Since I seem to be the author that likes to support the "odd ball" emus, I'll be glad to fill in the gaps for emus like modeler and imapct, that don't have the built in information systems that mame does.  

A note to Dave, you've seemed to take my comments personally so I won't comment anymore, I was just trying to explain what you would have to do to get people to contribute to your project.  I'm sorry I won't say anymore.  
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Oh one more thing....
« Reply #43 on: March 03, 2002, 03:45:39 pm »
I really DISLIKE the idea of having just a databse and thats' it.  It's simple enough gathering all of this info, but the real code comes into play by actually sorting this info and storing it into variables.  I agree with the previous posts in that there needs to be some type of ocx plug-in developed as well.  

on more category as well.... |category|  

he he, how could i forget that one.
;D
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Open-source front end
« Reply #44 on: March 03, 2002, 09:15:37 pm »
Quote

The database fields would be something like this:

filename|extension|Real Name|Clone|Emulator(s)|path|misc|




Ewww, ewww, ewww.  Bad database design.  Ewww, ewww, ewww.  Not take database modelling in college yet????
hehe, DB class in college, using DB2 at IBM, and using SQL Server at my last job taught me alot:)

hehe.  That actually is a bad db design.  Everything in one table as complex as having a generic DB that covers emulators in general.  I could come up with a pretty generic design (with the help of y'all).

Actually, if the db was a flat file than yeah, that'd probably be ok.  But extremely inefficient (especially if a mass change takes place).


now, for the rest of you.
NOOOO, not an ocx.  That's not portable:)
It's have to be an API.  Generically it would be compiled as commandline executable.  Otherwise it'd be a set of C++ classes with db ties and one could make a linux .so lib, a windows .dll, or whatever a mac has and include it in their FE project to make their own gui.  Anyway, It's have to be a library with a simple API.


My current FE creates the DB from scratch if it doesn't exist.  Write now it uses Access with the JET driver.  But all i need to do is change the connection string to use it for SQLServer, MySQL, DB2, etc....
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re: Open-source front end
« Reply #45 on: March 04, 2002, 06:09:07 am »
Quote


Like I said a few messages back, I'm all for it.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re: Oh one more thing....
« Reply #46 on: March 04, 2002, 06:17:19 am »
I actually love the idea.  If we had a standard schema for the games, then we could work on writing a few programs for propigating the data and have it work

like this (quick, dirty, not thought out).

database: the game
name, description, system, categories, funstuff.  IE whats to be displayed

system: the system
name, directory, program name, whats needed to start, whats needed to exit.
ie

mame, c:\emul\mame, mame.exe, -resolution 640x480, 'esc key character'

s11, c:\emul\s11, s11emulationstart.exe, -startgame %n (where %n would be replaced with the rom name), 'f10'

The advantage is that we could have someone write a program to parse the roms for S11 and fill in the systems database, and your emulator would all of a sudden support it!  

propigating the database (in my mind) shouldn't be done without a keyboard anyway, and should probably be in a different application (or like I do, have special key configurations to do it)


Quote
I really DISLIKE the idea of having just a databse and thats' it.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Open-source front end
« Reply #47 on: March 04, 2002, 06:01:41 pm »
Quote
s11, c:\emul\s11, s11emulationstart.exe, -startgame %n (where %n would be replaced with the rom name), 'f10'

The advantage is that we could have someone write a program to parse the roms for S11 and fill in the systems database, and your emulator would all of a sudden support it!  


See I realize that you other programmers haven't been as concerned with supporting other emu's, but I have, and there's a fatal flaw in your plan......

Your example for instance......  it wont' work!  S11 uses a numerical scheme to launch games, so you have to have a database of all the rom names within the emulator and then have a case statment which compares the game with your table and laucnhes s11 with the appropriate number as an extension.  

Ok how about impact/modeler?  wont work!  You have to  simulate keypresses to launch a game since theres no command-line options...... you could tell it which keys it has to pass, but then we would have to translate those keys to their appropriate programming language once we get them... (vb uses keycodes as well as ascii, and keycodes have slightly better reponse time.)  U64/u642..... same deal, you could only pass the appropriate keypress sicne there's no command line argument.....

Now daphne and raine would work, but they use standard mame syntax anyway, so they would work on any fe with practially no extra code as it is.

I'm not dismissing your idea, but merely showing that in order to do this right an ocx would be necessary to handle such things...  if it does it for you then all of this converiting wouldn't be necessary, and it would be the only true way to have a virtually codeless solution that would be universal as well.


« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

ArcadeFX

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
  • Last login:November 10, 2004, 11:16:56 pm
  • All the Dude ever wanted was his rug back!
    • ArcadeFX
Re: Open-source front end
« Reply #48 on: March 04, 2002, 06:25:58 pm »
With the new version of ArcadeFX that went live today I totally converted the backend to work off a database.  This was a huge step forward for AFX and I am glad I took the time to do it.  I wish I would of done it from the start.  It would of saved me a ton to code changes.

About using XML, I think this is a great idea. Authorware now has an XML Parsing Xtra that I have been wanting to use.  If there is any plan to more forward with this I am in. I have done a little with XML but not enought to jump in and add this to AFX yet.

If someone can give the advantages of using XML I would like to see them.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
itRe: Open-source front end
« Reply #49 on: March 04, 2002, 07:05:37 pm »
Ed if you keep the database backend you should switch to MSDE on next go around. It's alot more powerful. It's basically ms sql scaled down. It can hold 2 gb of data. It's also free to distribute if you build an application on it. It can do most things sql server can do, stored procedures and triggers. Also it can hold images and files. It think there is a lot you could do with it as opposed to access ie: stick all your marquees, snips and cabinet pics in one place. Even though it's microsoft it might not be bad to use for the opensource project either. I'm all for xml the only problem I see with it is there really is no benefit to xml in itself. The only advantage you have is you can borrow someone elses interpretor for xml and modify it for our needs. Then it would probably use less resources than a true database engine. But on the downside you'd have to modify or create the interpretor where as with a database engine you just have to install it.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

flemming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • Last login:October 15, 2002, 11:02:11 am
    • pyReCADE
Re: Open-source front end
« Reply #50 on: March 04, 2002, 07:16:31 pm »
I'm pretty new to XML as well, so perhaps I'm making poor assumptions from the start but I spent a little time thinking about this today and trying to put together a basic tree for what a game might look like.  Most of this info is from listinfo plus catver.ini, but it would of course be a start.  Those of us interested in taking this further should probably do so offline, since this board isn't particularly efficient.  But here's what I was thinking:

<game name="pacman">
<description>Pac-Man (Midway)</description>
<year>1980</year>
<manufacturer>[Namco] (Midway license)</manufacturer>
<category>Maze</category>
<cloneof>puckman</cloneof>
<romof>puckman</romof>
<emulator name="mame">
 <version>0.02</version>
 <driver>
  <status>good</status>
  <color>good</color>
  <sound>good</sound>
 </driver>
</emulator>
<history>
 "Designed by Toru Iwantani \nProgrammed by Hideyuki ..."
</history>
</game>

Of course the message board eats the tabs, but you get the idea.  You could easily get carried away and store the rom file info, crcs, etc but mind you a dump of listinfo with all that information including the history is 9MB so this file would probably end up being larger than that.  I also know ArcadeFX stores a counter and such for however many times the rom is ran, but I think changing data like that is probably better stored elsewhere since in the future you'd probably want to be able to drop in a new version of this file and losing that data would suck.  I've only thought of this from my standpoint of what I'd like to see in the file.  I'm sure others have different ideas and If we want to find some common ground this might be a good place to start.  Of course in theory XML might be a good idea, but in practice it might be PAINFULLY slow, so that's of course something which will have to be weighed.  If someone wants to setup a mailing list or something for us to talk about this further that would be great, if not I can do it as well.

Robert
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #51 on: March 04, 2002, 07:40:26 pm »
Am I alone in thinking that an SQL RDBMS is a tad overkill for a front-end?  I don't want to require my users to install an RDBMS just to run it.  There are in-process databases such as Berkeley DB and GNU dbm that are *much* lighter weight.

http://www.sleepycat.com/

-Dave
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #52 on: March 04, 2002, 07:50:58 pm »
i agree i was just suggesting it over access. Because at least you can count on your data being there and most people are famaliar with microsoft products. Maybe I'm delusional since i've been at work for 15 hours staring at poorly written VB code and I can't go home for at least another 6 hours. I should have kept my low paying job doing java development. But dang it I wanted a mame machine so I needed the big bucks microsoft programming pays.  :D
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

flemming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • Last login:October 15, 2002, 11:02:11 am
    • pyReCADE
Re: Open-source front end
« Reply #53 on: March 04, 2002, 07:53:36 pm »
Quote
Am I alone in thinking that an SQL RDBMS is a tad overkill for a front-end?
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Open-source front end
« Reply #54 on: March 04, 2002, 07:58:33 pm »
Guys perhaps were going about this the wrong way.... I'm a bit confused as to what you guys are suggesting now.  A database should never be manipulated while a fe is running, for speed and compatability issues.  I assumed taht you all realized that a text or binary output of a pre written text file was the way to go.  Trust me on this one... rd alpha had a database (access in the release, but i tried a few)  and it slowed everything down and actually required more code to navigate through it than if i would have hardcoded the searches and read from a static text file...

just something to think about...

(btw im in no way endorizing access, it's just it was there and quick to do.)
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #55 on: March 04, 2002, 08:00:59 pm »
Quote
I should have kept my low paying job doing java development. But dang it I wanted a mame machine so I needed the big bucks microsoft programming pays.  :D

Hrm... you must have got a bum Java job!  ;-) I've been doing Java on Unix for the last 2 years and the pay is nothing to sneeze at.

-Dave, just trying to point out that you can get paid well w/o Microsoft products
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Open-source front end
« Reply #56 on: March 04, 2002, 08:03:13 pm »
my bad... i mis-read the last post or two.. if it ws managed form within an ocx then you would get acceptable speed
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #57 on: March 04, 2002, 08:31:01 pm »
Quote
my bad... i mis-read the last post or two.. if it ws managed form within an ocx then you would get acceptable speed


Ok, this is my Windows ignorance showing through, but how does OCX relieve the overhead of an RDBMS?  Does it run in a separate thread or process?  Keep in mind that I barely know what OCX means.

-Dave
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #58 on: March 04, 2002, 08:39:04 pm »
Got a question since I never used Berkley db. Connection wise what do you use to connect from to it from an application? And if anything what would have to be installed on a users computer? Also if you can connect to it say through odbc, how effecient is the driver? The reason I ask is because currently one of the databases I use is progress. Which is a wonderful database when using the progress language. But it moves like a slug on a salt lick when you try to connect to it from anything else. I disagree with howard though on even access being to slow. I don't know how you had your database set up or how you were connected to it but I can't imagine how a text file could be faster. Unless your loading the whole file into memory and performing everything from there. The reason I like the database Idea is for example on your screen when your displaying roms all you have to do is select the rom name from the database and show it. Then get the images and info for the rom that is selected not all roms so you keep the memory usage down. you could do a prefetch for rom info and images on ones above and below and a page down or up if you were having performance with them displaying fast enough. Thats just my thought.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #59 on: March 04, 2002, 08:41:15 pm »
Quote
Plus perhaps it's just the Linux bigot coming out of me but last time I checked MAME ran on a TON of platforms and OSes so I don't really see the point in talking about working together and sharing certain backend functionality and then bringing up MS SQL and OCX files :)  Berkeley DB does work on a variety of platforms so I think it would also be a valid option should the XML pipedream get tossed aside.


I agree... a common backend that only runs under Windows is useless to me.  I'm targetting my front-end for DOS, Windows, and Linux, so a backend would have to be portable to these platforms.

Maybe it could be broken out into two components, an API and a backend.  The backend could be pluggable with SQL, Berekeley DB, and GNU dbm plugins, for example.

-Dave
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #60 on: March 04, 2002, 08:43:15 pm »
ocx doesn't relieve rdbms overhead. It is a seperate component or control that could take care of the database functions. So the program itself wouldn't be burdened with them. I think thats what howard was getting at. He was also referring to using them with access.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

ArcadeFX

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
  • Last login:November 10, 2004, 11:16:56 pm
  • All the Dude ever wanted was his rug back!
    • ArcadeFX
Re: Open-source front end
« Reply #61 on: March 04, 2002, 08:49:40 pm »
I have everything you suggested for the XML already in my Access database. Fully populated.   It works like a charm and is lightening fast.  I do queries to the database the entire time the use is in ArcadeFX now.   Almost every action you do in AFX now is pulling data from the Access database.  It is head and shoulders faster than accessing any large file like listinfo or catver.ini or any other mame generated file.  I do not store any images in the database at all.  I see no reason to do this.  All image are taken from there respective MAME folder based on data returned form the database.

In AW database access on the fly from a db is faster that I could have imagined.  Mush faster than accessign any of the MAME generated files for sure.

Here is what my database contains and is fully prepopulated when the user downloads it with the AFX files.

gamename, gamedescription, gameyear, gamemanufacturer, gamecloneof, gameromof, gamecategory, gameversion, videoscreen, videoorientation, videox, videoy, videocolors, videofreq, soundchannels, inputplayers, inputcontrol, inputbuttons, inputcoins, driverstatus, drivercolor, driversound, drivercolordeep, available, favorite, favorite2, favorite3, favorite4, favorite5, counter

The last seven are data that is written from AFX for each user.

Any database I have ever worked with is faster than any txt file could every be. This includes PHP/MSLQ, Oracle, Sql Server, Access. I guess it all depends on how you code the front end.

This is only limitation in AW that I have had to work around and that is a 30k limit on variables.  This is a pretty easy thing to work around.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #62 on: March 04, 2002, 08:52:49 pm »
Quote
Got a question since I never used Berkley db. Connection wise what do you use to connect from to it from an application? And if anything what would have to be installed on a users computer?


There is no connection.  It's just a library or DLL you link in with your program.  The library accesses DBM files on disk directly.  These files are in a B-tree format or something.  If you statically link it in, then nothing is needed on the users' computer.  If you go the DLL or shared library route, the user would need the DLL installed somwhere.  

Granted, Berkeley DB cannot do much of what an SQL database does.  There's no concept of tables, joins, transactions or anything like that.  But it does provide you with very fast O(1) lookups on key/value data sets.  I also think it is very memory effecient since it does not need to read in the whole DBM file just to access a few records.

-Dave
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #63 on: March 04, 2002, 08:57:43 pm »
One more thing I see no point what so ever in creating anything for dos. I can understand linux, windows and even mac. But dos is a beast in it's self. There is no reason to write anything your going to have to dumb down to be compatible with an out of date OS. We should start it moving ahead with mame where it's going. Not what it's moving away from.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #64 on: March 04, 2002, 09:08:35 pm »
Quote
One more thing I see no point what so ever in creating anything for dos. I can understand linux, windows and even mac. But dos is a beast in it's self. There is no reason to write anything your going to have to dumb down to be compatible with an out of date OS. We should start it moving ahead with mame where it's going. Not what it's moving away from.


While I agree that DOS is a minority (and dying) platform, it is not dead for MAME yet.  There are many people who still use DOS for arcade cabinets.  I'm gonna cling on for another 6 months to a year.

Besides, I see no reason why DOS *can't* be a target.  With the DJGPP environment for DOS, programming for DOS isn't as bad as you might think.  It's almost like programming for Unix as many of the Unix APIs and libraries are available.  Hell, if they can port GCC 3.0.4 and Perl 5.6.1 to DOS, I *think* a  front-end could run under DOS! ;-)

-Dave
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

ArcadeFX

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
  • Last login:November 10, 2004, 11:16:56 pm
  • All the Dude ever wanted was his rug back!
    • ArcadeFX
Re: Open-source front end
« Reply #65 on: March 04, 2002, 09:30:41 pm »
DOS is dead as far as I am concerned.  If you want to make something that looks good then DOS is out.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #66 on: March 04, 2002, 09:38:59 pm »
Quote

Hrm... you must have got a bum Java job!
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

ArcadeFX

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
  • Last login:November 10, 2004, 11:16:56 pm
  • All the Dude ever wanted was his rug back!
    • ArcadeFX
Re: Open-source front end
« Reply #67 on: March 04, 2002, 09:55:57 pm »
You have to remember that people have to download this and set it up on their PC.  They are not going to buy anything Oracle to run a front end.  Oracle would give you all the power you need but useless for what we need to do with a front end.

Access is the best option for Window by far.  Relativly small download, free, and more powerful and txt files.

I personally think trying to develop a FE for every platform (DOS, Win, Mac, Linux) will limit you to much.  If it is open then let people make their own port to their desired OS.  And work with them to do it.   Otherwise anything that is done is going to look and function like it did before P-diddy, Howard, and myself started our FEs. BORING!  Yea, MAME32 works great but it looks like every other VB/C++ app. on the net.  That is the reason that I went with Authorware.  AW is not the solution for what an open project like what is being talked about here but is my creation of the perfect front end.  Perfect to me.  ;D  

How many other apps can you think of are cross platform like what some of you are suggesting here? I can't think of any off the top of my head.

« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #68 on: March 04, 2002, 09:58:10 pm »
Quote
But I guess i am also the sql and oracle dba so that may have something to do with my pay. Also may be why I like rdbms so much, hey we could use oracle 9i personal edition. It should run on everything.  ;)


Oh, don't get me wrong.  I have nothing against RDBMSs.  I'm partial to PostgreSQL or MySQL, myself.  Oracle is a fine DB if you need all of its features and you can afford the price.  But why spend thousands of dollars for something you can  get for free?

-Dave
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #69 on: March 04, 2002, 10:06:48 pm »
i was kidding on using oracle but personal edition is free if you ever want to download it.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

flemming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • Last login:October 15, 2002, 11:02:11 am
    • pyReCADE
Re: Open-source front end
« Reply #70 on: March 04, 2002, 10:18:41 pm »
Quote

How many other apps can you think of are cross platform like what some of you are suggesting here? I can't think of any off the top of my head.


Well there is MAME itself now isn't there?  BUT, I don't think that is what we were talking about (at least I wasn't).   He topic shifted from opensource FEs to playing nice with each other.  Along with the idea of playing nice with each other came the ideas of a universal database that various FEs could use and even a common library that could be written for extracting and sorting info from that database.  Along the way that got hijacked into RDBMSes and OCX objects, neither of which really go along with the idea of a universal database or common libraries.  Obviously those of use that choose not to use Windows are in the minority, but I'd still like to participate in the reindeer games and if one way to do that is to work with other FE authors on a standard way of doing a few things, I'm sure that will save both myself and other developers time.  Of course the additional benefit being that end users could switch FEs and have some data remain constant between them.

Robert
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re: Open-source front end
« Reply #71 on: March 04, 2002, 10:23:53 pm »
Quote
How many other apps can you think of are cross platform like what some of you are suggesting here? I can't think of any off the top of my head.


Ugh... MAME!  :P  And even if DOS is dropped out of the equation, many games like Unreal Tournament, Quake 3 and Myth 2 all run under Linux, Windows, and Mac.  UT and Q3 run under all sorts of consoles, too.  And they're not boring. :)  Well, ok, maybe Q3 was boring, but that's beside the point....

That said, I don't think one uber front-end will ever make everyone happy, anyways.  There's way too many opinions on what makes a good FE.  But that won't stop me from making an open source, cross platform FE that is functional and looks better than a standard Windows program.  

-Dave
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Mike

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 307
  • Last login:September 22, 2005, 01:22:14 pm
  • Umm, yea about the TPS report
Re: Open-source front end
« Reply #72 on: March 04, 2002, 10:54:09 pm »
You should make emuix. Strip the linux kernel so it just runs emulators and fires off a clean customizable GUI to launch the emulators from nothing but the keyboard controls. That would be ideal for all. Lets see that penguin power.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

flemming

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 11
  • Last login:October 15, 2002, 11:02:11 am
    • pyReCADE
Re: Open-source front end
« Reply #73 on: March 04, 2002, 11:21:07 pm »
Quote
You should make emuix. Strip the linux kernel so it just runs emulators and fires off a clean customizable GUI to launch the emulators from nothing but the keyboard controls. That would be ideal for all. Lets see that penguin power.


Uh, what's what I'm doing.  Except it's not as black magicy as it seems you'd like to make it sound.  MAME can be build using SDL which can use the frame buffer so X is not needed.  Pygame the library I'm using to write my front end also uses SDL, thus the same applies.  So add the Linux Progress Patch to the kernel with some cheezy graphic and you have a machine that boots up immediatley into a graphical screen while the OS loads then fires off the frontend.  It's pretty brain dead to strip down what gets loaded on startup and build a kernel with only the bare minimum so that your overhead is reduced as much as possible.

Robert
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

ArcadeFX

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 188
  • Last login:November 10, 2004, 11:16:56 pm
  • All the Dude ever wanted was his rug back!
    • ArcadeFX
Re: Open-source front end
« Reply #74 on: March 05, 2002, 12:12:44 am »
Okay you guys got me with MAME being cross platform but that doesn't have a univeral frontend that works on all platforms. That is what I was getting at.

I also use Red Hat at home on my cable box so I would be interested in anything you do on Linux.  The perfect MAME OS would really be Linux for the simple reasons you mentioned. You can totally customize the OS for the cabinet.  

Only problem is now how do I play NFL Blitz and Castle Worf?  I can't live without those.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re: Open-source front end
« Reply #75 on: March 05, 2002, 09:00:38 am »
One more thing about databases and XML.

If we make generic frontend tools, we sould write an API to get the data somehow.  Who cares how!

Why?  Database are better!  They really are.  XML parsers usually require you to load everything in memory.  Thats great! But that was my number 1 complaint in my first version that I took to much resources on low end systems.  

So why not use both?  

Have a database plugin and a xml plugin going throught the same API?  That would be easy and we could easily get them writting and working great!  I also working on (hopefully soon) getting mame so we can ask it for the info ingame.  So the only thing I would be interested in would be the name of the game, all the rest would come from mame itself (and I would probably do that from mame directly also).  But I could incorporate that into the same api.  

Last,  Howard, about the trouble with my database stuff.  I have most of that covered.  

first, each game can add to thier own command line.  So for S11 I add a

-listinfo 1

for the first game in the argument location.  But I also have a -argument in the system.  That can take (currently) a %n and have that replaced with the rom name.

so I can have
-game %n.zip

and it can combine together also.

-game %n.zip -gameargumentA

This will run almost everything.  But I can't simulate keystrokes *** until you open that part of your code as a middlewhere piece of course :) ***

But that can be added
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Open-source front end
« Reply #76 on: March 05, 2002, 10:33:54 am »
Quote
Am I alone in thinking that an SQL RDBMS is a tad overkill for a front-end?
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re: Open-source front end
« Reply #77 on: March 05, 2002, 02:08:15 pm »
Quote


2) Recently played games.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re: Open-source front end
« Reply #78 on: March 05, 2002, 02:17:51 pm »
Ok... we are talking about implimentations...  We should be talking about requirements/functions

1)  Crossplatform?  
 yes) This will force it to be java or c basically.  We could go pascal, but that would kill a bunch of stuff.  They both have their advantages.
 no) This allows us to use DLL and activeX components for the parts.  

2)  Moduler?   IE, do you have to compile to get the different parts together?
 yes) Then java is still a great platform.  But most others there is a level of hacking to get it to work.  
 
3)  API's for what?  
 Databases/XML/Whatever
 Emulator starting?  (ie, module for mame, impact, ect)
 Screen setup?  or standard skinner with modules to add?
 Keyboard/Encoder hooks?
 In-frontend configuration?

4)  How about database configuration?  Does this happen from a seperate application?  

IE, Before we argue about how to do the parts, we should decide on how to create the parts, how to connect them, then let different people work on the different parts (and see if they work in the end :)
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re: Open-source front end
« Reply #79 on: March 05, 2002, 02:21:04 pm »
btw, if we only care about the .net framework (not sure the extent to that....)

the c# could be the language (very very similar to java) and there is hooks to convert VB and ActiveX component dll's to the .net framework.

I ahven't tried it, but there are a bunch of examples around.

Also, all the tools are free I think
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re: Open-source front end
« Reply #80 on: September 12, 2002, 09:34:23 pm »

Ok... we are talking about implimentations...

Dave_K.

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1807
  • Last login:July 06, 2022, 03:27:30 pm
    • Arcade Fever
Re:Open-source front end
« Reply #81 on: September 13, 2002, 01:38:07 pm »
I completely agree with SirPoonga.  Its apparent you should be using Java if you want full cross platform compatability using open standards.  There is even a JVM for DOS!  Lots of XML java tools, GUI tools, and JDBC api for ubiqutious database access.

-Dave

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re:Open-source front end
« Reply #82 on: September 13, 2002, 01:44:38 pm »
Since JFront is a java frontend I can talk about it a little.

It's great for many features... but...  One major trouble I'm having with it.  I can't run a dos program from it.  Why?  I get some runtime error.

This isn't a big deal for me.  I'm not running any dos emulators...

but where it would have been nice is that I was able to control the encoders based on game/emulator.  So I could configure my encoder for all modeler games... then something else for most mame games... then something different based on what cp your using....

but I could only get it to work when I ran the win32 bit version of the encoder software and most encoders dont work

why am I mentioning this?  Well, because it would never be able to use for dos emulators/games.  And this will keep some people away from java

but other then that... its a great language for a frontend

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #83 on: September 13, 2002, 03:31:38 pm »

I completely agree with SirPoonga.  Its apparent you should be using Java if you want full cross platform compatability using open standards.  There is even a JVM for DOS!  Lots of XML java tools, GUI tools, and JDBC api for ubiqutious database access.


Don't forget about C.  C is probably the most portable language currently in existance running on just about every platform designed in the last 20 years.  There are plenty of 3rd party libraries for C, too (including XML).  C is "more open" than Java, since its not controlled by a single corporation and has an official ISO/ANSI standard.

Don't get me wrong, I love Java.  I've been programming Java professionally for the last 2+ years now.  And if you want a standard GUI interface, than Java is a good choice.  Swing is a decent GUI API, though it's ugly and a little sluggish.  Java is just not the only cross-platform language that could be used for a front end.

BTW, I've never heard of a JVM for DOS.  Do you have any pointers to that?

-Dave

Dave_K.

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1807
  • Last login:July 06, 2022, 03:27:30 pm
    • Arcade Fever
Re:Open-source front end
« Reply #84 on: September 13, 2002, 04:27:55 pm »

BTW, I've never heard of a JVM for DOS.  Do you have any pointers to that?


Here is one:
http://www.openje.org/kaffepc/manuals/en/index.html
There may be more.  I've never tried them personally.

-Dave

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #85 on: September 13, 2002, 05:52:27 pm »


I completely agree with SirPoonga.  Its apparent you should be using Java if you want full cross platform compatability using open standards.  There is even a JVM for DOS!  Lots of XML java tools, GUI tools, and JDBC api for ubiqutious database access.


Don't forget about C.  C is probably the most portable language currently in existance running on just about every platform designed in the last 20 years.  There are plenty of 3rd party libraries for C, too (including XML).  C is "more open" than Java, since its not controlled by a single corporation and has an official ISO/ANSI standard.

Don't get me wrong, I love Java.  I've been programming Java professionally for the last 2+ years now.  And if you want a standard GUI interface, than Java is a good choice.  Swing is a decent GUI API, though it's ugly and a little sluggish.  Java is just not the only cross-platform language that could be used for a front end.

BTW, I've never heard of a JVM for DOS.  Do you have any pointers to that?

-Dave



True, C is "more cross platform" but that really is an opinion too:)

I suggested java because of the ease of doing a GUI.  You say it has ugly GUI, then you don't know enough about it!  My friend di a full screen app in java.  It mapped out an intranet.   displayed everything radial style.  The computer or router or network element you click on would (animate) to the center of the screen.  everything one connection away would be on the first circle around it, everything 2 connections away, would be one the second radius (radius is better than saying circal since it is a radial design).  You could click on another element and it would all animate so that element would be come the center of the radiuses.  Was fast and looked pretty sweet.

Dave_K.

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1807
  • Last login:July 06, 2022, 03:27:30 pm
    • Arcade Fever
Re:Open-source front end
« Reply #86 on: September 13, 2002, 06:17:12 pm »
Yes, I guess C is a cross platform language, but its a challenge to keep the code portable.  Java was made for this, and its a breeze.  You could even distribute with the compiled byte code so there is no need to run complicated makefiles or .configure scripts like with C.  There are a slew of other reasons why its eaiser to develop a joint project like this in Java than C, but I won't get into the pros/cons of object oriented programming v.s. procedural, memory management, or threading models.

-Dave

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #87 on: September 13, 2002, 06:32:08 pm »

True, C is "more cross platform" but that really is an opinion too:)


Actually, that's an easily quantifiable fact with a little research.  Again, I'm not knocking Java.  I didn't say Java wasn't cross platform now, did I?  It certainly is more cross platform than VB or Flash, but Java is not the "one and only" cross platform language.
Quote
I suggested java because of the ease of doing a GUI.


Which I agree on.  Swing is easy to work with.  There are cross platform GUI libraries for C, too.
Quote
You say it has ugly GUI, then you don't know enough about it!


Well, you're entiteld to your opinion, but I happen to think the Swing "metal" look and feel *is* ugly and a little slow and unresponsive.  I have used many Swing apps, so I think I'm qualified on this subject.  This isn't something I'm quoting from some article I read.  It's a personal experience, so don't tell me what I know and don't know.
Quote
My friend di a full screen app in java.  It mapped out an intranet. ....  Was fast and looked pretty sweet.


Well good for your friend. :P  Seriously, I'm not knocking Java as a cross platform language.  It's just not the one and only language to develop a cross platform FE in and neither is C.

-Dave

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #88 on: September 13, 2002, 06:47:37 pm »

Yes, I guess C is a cross platform language, but its a challenge to keep the code portable.  ....


You make some very good points in there, but they still don't rule out C.  It's not *that* difficult to write portable C code.  And don't forget about C++ which is nearly as cross platform as C, but object oriented.   I'm a big fan of OO, too.

Anyhow, I guess my main point is that a programming language shouldn't be chosen without knowing all the requirements.  Going on the one requirement of "cross platform", there are more choices than just Java.  There are more choices than Java, C, and C++, even.  Perhaps Python or Ruby is the best language for someone's ideal front end.

-Dave

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re:Open-source front end
« Reply #89 on: September 13, 2002, 07:26:55 pm »
As java goes... Swing IS slow!  It's HUGE and it bloated...  But when it works for you it's great (creating buisness screens for a standard PC).

Sure you can create a fullscreen app.  But has anyone here !@##ed with the !@#!@ up focus problems with the Window object (the full screen frame?).  It's so bad, that I had to change to 1.4 for jfront and use a non-decorated frame... so your stuck with 1.4+... not a huge deal though..

As for C / C++... (get one and you can use the other usually)... the trouble is the libraries aren't always crossplatform... and there libraries are very very useful.  But we could use the C++ and the libraries used my mame... why?  mainly so we could make sure that it works on all platforms that mame runs on...

but you still have the problem of modularity... Add some classes at runtime in C/C++... You just can't really do it without HUGE problems (and I don't think you would find a crossplatform solution)...


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re:Open-source front end
« Reply #90 on: September 13, 2002, 09:50:27 pm »
The truth of the matter is there is never going to be a cross-platform front-end.  There is a perfectly good reason for this.  Operating systems arent' meant to be intercompatible.  

Ok don't flame me but here is the matter at hand.....

Java=too slow/akward

Flash=maybe... but it's very dependant upon the os around it.

C=Not truely cross platform in that different parts need to be coded for different oses.  Also straight C isn't very friendly when it comes to graphics.  I find it amazing that the mame team have gotten it to work so well for them.

Any other programming lang=proprietary.

So what about html, dynamic php and all of that crap?  Well basically these can't launche external programs so you are screwed there.  

You've got to look at the practical side of things.  It's much simplier to have 4 seperate fes that all run great on their respective platforms than to try to make some nasty uber beast.  Plus I don't think any of us are familiar with linux, windoze, mac os, mac ox X, bsd ect to make one big one.  

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #91 on: September 13, 2002, 11:22:31 pm »

Flash=maybe... but it's very dependant upon the os around it.

Very true, as my FE is flash.
Though with MX it will not work whatever for a multiplatform FE unless you combine it with director maybe.  But then you have to make a mac version and pc version.  Is there other OS flash runs on???


Second, HC is partly right, there is noway to make an ENTIRE fe crossplatform.  It is more likely to make the data store (database, XML, whatever) cross platform but not the GUI.  In otherwords one could make a backend that is cross platform that would just need a good frontend that can talk to it.  We've talked about this before, too lazy to search for the thread right now.  Actually, it's kinda like java, the bytecode binary (.class file) would be the "backend" and the JVM would be the "frontend".  you have to have the JVM for the particular OS.

Dave_K.

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1807
  • Last login:July 06, 2022, 03:27:30 pm
    • Arcade Fever
Re:Open-source front end
« Reply #92 on: September 14, 2002, 03:28:47 am »

Java=too slow/akward

I'm not sure I understand what you mean by Java being akward?

As for Java's speed, well that all depends upon how complex the GUI is.  I really hate how people immediatly think Java is slow.  There are tools available on all platforms for speeding up java performance.  Sure it may not be as fast as a natively compiled C program, or be a choice to write an RTOS, but come on we are talking about graphical menu system here.

To answer SirPoonga, Java is a perfect backend.  Its flexable enough to work with almost any database and even no database if you prefer to store your data on disk in say a properties file.

-Dave

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #93 on: September 14, 2002, 03:48:08 am »
the data doesn't have to be stored in a database, to be truely cross platform you need textfiles.  XML does very well at that and I hear java has excelent xml capabilities.

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #94 on: September 14, 2002, 12:55:30 pm »


Flash=maybe... but it's very dependant upon the os around it.

Very true, as my FE is flash.
Though with MX it will not work whatever for a multiplatform FE unless you combine it with director maybe.  But then you have to make a mac version and pc version.  Is there other OS flash runs on???


I run Linux and can use most Flash sites, except some of the newer ones.  Flash 5 runs on most Unix platforms.  Flash 6 is Win/Mac only and Shockwave is Win/Mac only.

http://www.macromedia.com/shockwave/download/alternates/

The Flash development environment is also not free (as in cost) which is a big drawback for an Open Source project, IMHO.  If If I want to contribute to an Open Source project, the last thing I want to do is shell out a few hundred bucks for some developement kit.

-Dave

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #95 on: September 14, 2002, 01:01:42 pm »

the data doesn't have to be stored in a database, to be truely cross platform you need textfiles.  XML does very well at that and I hear java has excelent xml capabilities.


Yeah, I agree.  I think using a separate RDBMS for a FE is *way* overkill.  A FE isn't going to use 90% of what a full blown RDBMS provides and it's a PITA to require the end-user to install a RDMBS.

And Java *does* have excellent XML capabilites.  Anyone doing XML work for  Java should look at JDOM:

http://www.jdom.org/

-Dave

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #96 on: September 14, 2002, 01:49:07 pm »

The truth of the matter is there is never going to be a cross-platform front-end.  There is a perfectly good reason for this.  Operating systems arent' meant to be intercompatible.


Well, true, OSes aren't designed to be interoperable, but that doesn't mean a FE cannot be cross platform.  Game Launcher is cross platform.  You may not like GL, but that doesn't detract from the fact the GL runs natively on DOS, Windows, and any Unix (not just Linux).  It would probably run under Mac OS, too, but I don't have a Mac to try it out on.
Quote
Java=too slow/akward


I may be sounding like a broken record here, but it depends on what you want your front-end to do.  If you want a standard GUI, than Java is a good option.  I don't think Java is too slow, just slower and a little sluggish.  If you want the minimum system requirements to be a 1Ghhz+ CPU with 256MB+ of memory, Java will easily be fast enough for you.  If you are targetting a P2 300, then Java is gonna be a little too slow, I think.

As far as Java being awkward, I have to disagree.  Java is one of the most non-awkward languages I have ever used.  It's really a fun language to program in.
Quote
C=Not truely cross platform in that different parts need to be coded for different oses.  Also straight C isn't very friendly when it comes to graphics.


Well one of the problems with C as compared to Java is that there is no "standard" graphics and GUI API.  But there are some very good graphics libraries out there.  SDL, OpenGL, and Allegro come to mind immediately.  All are C based and all are portable among the many popular OSes.  Many professional games, including Quake 3 and Unreal Tournament, use SDL and OpenGL.

I personally have used Allegro and it took me all of 1 day to port the graphcs part of Game Launcher to Windows and Linux.  The hardest part of porting GL was the code that launches an external program.  Of course, this is only a few hundred lines out of 20,000.  Unfortunately it is also the most important part and still needs some cleaning up.
Quote
I find it amazing that the mame team have gotten it to work so well for them.


It's called good design.  They've abstracted out the graphics so that 95% of all of MAME is portable to any system with an ANSI C compiler.  And it's easy to plug in a new graphics engine.  That's why you can see MAME on devices from digital cameras, PDAs, and the XBOX to a PC.  And that shows both the portability of C and the power of good sofware design.  Kudos to the MAME team!
Quote
Any other programming lang=proprietary.


Well you do have Tcl, Perl, Python, and Ruby available wich are not proprietary.  I think all even have a portable GUI of some sort, too.
Quote
You've got to look at the practical side of things.  It's much simplier to have 4 seperate fes that all run great on their respective platforms than to try to make some nasty uber beast.  Plus I don't think any of us are familiar with linux, windoze, mac os, mac ox X, bsd ect to make one big one.  


With a little work, you can be cross platform to all those.  And you don't necessarily have to be an expert on all of them.  For Java, all the cross platform stuff goes in the JVM and Sun takes care of it.  For C/C++ the cross platforfm stuff goes into properly abstracted graphics modules.  Again to bring up Game Launcher as a case study, I didn't have to be that familiar with Windows to make a Windows port.  The Allegro guys are the Windows experts and have already done the hard work for me.  I couldn't program DirectX if my life depended on it, yet GL is a DirectX application.  That's pretty cool.

-Dave

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re:Open-source front end
« Reply #97 on: September 15, 2002, 04:01:07 pm »
Java slow???  

Howard... I've been told from a few out there that my frontend is the fastest of any of the NextGen frontend... hehe...  

MUCH faster then all the flash/autherware/ect

Java, with hotspot compilers, are about 10% slower then native C.  But that depends on what your doing.  The lower level, the slower... mainly because arrays are really objects... and they automatically do things like bounds checking.  

Swing is slow because every object is so general... that they each can do about anything.  And they they give hooks for people to rewrite the parts that they want/need.  But doing so slows them down considerably.

but all in all... until the jvm's fix the problems with launching dos applications... I would say it's not a good choice... I don't run any dos emulators currently... but I would love to be able to configure most encoders from a frontend.


Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #98 on: September 15, 2002, 06:52:05 pm »
but all in all... until the jvm's fix the problems with launching dos applications... I would say it's not a good choice... I don't run any dos emulators currently... but I would love to be able to configure most encoders from a frontend.


I assume you're using java.lang.Runtime.exec() to launch programs, right?  What errors do you get?  One thing to try is launching "command.com /c <program>".  Maybe you'll have better luck spawning command.com, rather than the program itself.  Of couse, this part would be Windows specific, but I think you can detect what OS you're on in Java.

-Dave

nipsmg

  • Trade Count: (+2)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1741
  • Last login:Yesterday at 03:41:49 pm
  • ROONEY!! ERRGH!!
    • Arcadia
Re:Open-source front end
« Reply #99 on: September 15, 2002, 11:43:59 pm »
OK well I figure I'll throw my $0.02 in on this one.

The two arguments I see going back and forth are over the use of some kind of data management system (XML, RBDMS, Etc..) and over the use of a language for various reasons (speed, portability, ui)..

First of all, I have to agree that using a full blown RBDMS is a bit overkill.., especially if this is to be a portable application.  End users, especially those who arent' very technically inclined, will simply not use a frontend if they are required to install a RBDMS to run it.  It's too difficult, when most users are looking for a "plug and play" solution.

People have been complaining about the speed of XML as a solution.  However, I happen to believe XML is an ideal solution, basically because of its flexibility and the sheer number of tools available to utilize it. And I have doubts about the need for crazy speed when, basically, the data will only be used to display a list of available games for the user, and does not need to have any complex queries run on it.

As far as the language to use, I'd have to say that I think C or C++ developed something like gcc or djgpp would be ideal for the design.  People have been complaining about the speed of swing, or the ease of VB for UI design, but, at least from a Cabinet Owner's standpoint, people do not want a "windowed" UI for a frontend.  And being that there are a few good cross platform API's out there for 2d graphics, I'd think C/C++ would be the way to go for speed and portablilty.

I've even been planning on possibly creating a custom frontend for my cabinet, using OpenGL for 3d graphics....  Basically for show, but i'd love to have some eyecandy on a frontend... you know, exploding transition effects, particle engines, just craziness (even though you'll need a nasty video card to run it properly)..   However, being that i'm new to C++ (I've been doing VB programming professionally for 3 years, just dabbling in C++), I'm not quite sure how I'm going to pull that off, but i'll find a way, like usual..

Just thought I'd add my comments (and some more length to this rediculously long thread)

;D
--NipsMG



Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re:Open-source front end
« Reply #100 on: September 18, 2002, 06:33:58 am »

Java slow???  

Howard... I've been told from a few out there that my frontend is the fastest of any of the NextGen frontend... hehe...  

MUCH faster then all the flash/autherware/ect

Java, with hotspot compilers, are about 10% slower then native C.  But that depends on what your doing.  The lower level, the slower... mainly because arrays are really objects... and they automatically do things like bounds checking.  

Swing is slow because every object is so general... that they each can do about anything.  And they they give hooks for people to rewrite the parts that they want/need.  But doing so slows them down considerably.

but all in all... until the jvm's fix the problems with launching dos applications... I would say it's not a good choice... I don't run any dos emulators currently... but I would love to be able to configure most encoders from a frontend.


Java is slow and akward in terms of development speed, not the actual run speed.  And regardless of what anyone thinks java is akward for two reasons....  

#1 It's just like C in a bad way.....
Meaning you have to deal with header files and c's annoying syntax. (Which I do know but still find the silliest of all langs)  >P<, myself and ArcadeFx don't have to deal with that junk which greatly simplifies the souce and speeds up development.  Of course all of our langs are pretty much propritory, which even proves my point more that you can make seperate fe's for each os much fster/easier than doing a big one, even if it is just the backend.  

#2 It's not like C in a bad way....  
For some reason many of the useful built-in functions of c/visual c are lfet out of java.

I'm not saying java is a bad language, but what it really is, is a crippled version of C that's supposed to be more portable but in actuality isn't any mroe protable than c.  Since C has all of the extra features why not just use C if you are going that route?  Now mind you it is really good for databases, but I've still found that a simple text file is the best database simply because of the added hastle of another interface level.  

My listgenerator parses the listinfo file and dat files converting it into a list of records minus the junk. After that you just make an array, which is simple to do in any language.  I've found the backend stuff to be simple, too simple to waste time making a universal one.  The hard part is usually the gui and how you use the backend info.  

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #101 on: September 18, 2002, 10:40:38 am »
Java is slow and akward in terms of development speed, not the actual run speed.


Huh? I can build a Java program consisting of over 70 Java files in 10 seconds.  And I've compiled bigger programs (hundreds of files) in only seconds more.  And that's compiling *all* files which rarely needs to be done.  A typical build only takes a few seconds.
Quote
And regardless of what anyone thinks java is akward for two reasons....  

#1 It's just like C in a bad way.....
Meaning you have to deal with header files and c's annoying syntax.


Nope, no header files in the Java I've used.  Just .java files.  And what annoying C syntax are you talking about?  Sure Java looks similar to C with the curly braces, but that's hardly annoying.
Quote
>P<, myself and ArcadeFx don't have to deal with that junk which greatly simplifies the souce and speeds up development.


Hmm.... ok.  Those languages have no stupid syntax at all, right.  They're perfect.  Yeah.... right.  I don't buy for a second that those languages don't have some part of the syntax that isn't annoying.  And I'm skeptical of this syntax that "greatly simplifies the source and speeds up development".  I don't know those languages you talk about, but I doubt syntax can cut development time by any quantifiable amount.
Quote
#2 It's not like C in a bad way....  
For some reason many of the useful built-in functions of c/visual c are lfet out of java.


What?!  Such as.....
Quote
I'm not saying java is a bad language, but what it really is, is a crippled version of C that's supposed to be more portable but in actuality isn't any mroe protable than c.


Well, actually, you *are* saying Java is a bad language. :P  And I don't buy it.  Not one of your arguments has any basis in fact.  Sorry.  Pure FUD.

Have you ever actually *programmed* in Java before, or did you just see some code snippets on a piece of paper?  From some of your arguments (particularly the header file one), it doesn't sound like you've ever used it.

-Dave

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re:Open-source front end
« Reply #102 on: September 18, 2002, 11:19:26 am »
#1 It's just like C in a bad way.....
Meaning you have to deal with header files and c's annoying syntax. (Which I do know but still find the silliest of all langs)  >P<, myself and ArcadeFx don't have to deal with that junk which greatly simplifies the souce and speeds up development.  Of course all of our langs are pretty much propritory, which even proves my point more that you can make seperate fe's for each os much fster/easier than doing a big one, even if it is just the backend.  

Mentioned above... No headers

#2 It's not like C in a bad way....  
For some reason many of the useful built-in functions of c/visual c are lfet out of java.

Actually... 100% backwards...  Java has all the useful parts into the core.  C 100% doesn't.  Ansi C has VERYVERY little to it... anything else is an add on.  If you are talking about MFC, then you drop crossplatform or have to play games.... But Java is VERY rich in features set... and installing additional packages is one line at the bigging of the file...

As for quick text file access.  It deals with all files as streams.  This makes some simple items a little more complicated.  But people don't use straight text files.  They use property files

fred=joe
test=1

and thats one command to get it the values.  VERY easy.  If you need  more then a property file, usually you goto XML or a database.


btw, one of the great things about java is that IDE's are almost all free / crossplatform and great also.  

rampy

  • *shrug*
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2910
  • Last login:March 02, 2007, 11:32:16 am
  • ...as useless as a JPG is to Helen Keller
    • Build Your Own PVR
Re:Open-source front end
« Reply #103 on: September 18, 2002, 11:50:03 am »
I'm coming late to the party, and I don't have my own FE...

but I found it ironic that in my inbox today I had a link to this article/editorial about alternatives to swing like AWT/etc

Language advocacy is a weird thing...  I say:

1. use the best tool for the job
2. use what you are familiar with

that's of course and oversimplification, but hey... that's my style...

What I like about JAVA is this: NO MALLOC and NO POINTERS =P  when coding I don't want mess around with memory locations, i'd rather let the compiler/runtime deal with that... but that's more an argument for "higher" level languages than just for java.

Different languages have different strenghts and weakness... so do different coders....   RAD type languages can be very powerful, but I can see cases where one would want to be able to dive down deeper than the language lets your.  

IOW to each his own... but I like cross platform open sourced FE's personally... I can't stand when there's a super cool FE (or any other proggie), but it doesn't work in my environment.

*shrug* YMMV,

rampy


Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re:Open-source front end
« Reply #104 on: September 18, 2002, 12:45:58 pm »

Have you ever actually *programmed* in Java before, or did you just see some code snippets on a piece of paper?  From some of your arguments (particularly the header file one), it doesn't sound like you've ever used it.


Yeah, I took a symester or two of java.  I'm sorry if I didn't use the correct teriminology.  I didn't mean a true.h file, what I meant was the fact that you have to tell your main the other files exist. Vb doesn't do that as do many other proprietory languages.  In vb if you have 20 module files you never have to write a single line of code setting those up, the development package does that for you automatically when you compile.  This is how it should be btw for all langs.    

Memory managment, pointers, the built in functions that make c so much more versitile are often missing in java or they are replaced by a much more complex calling method.  Sorry if you haven't ran into that before.  

And yes ease of syntax makes a HUGE difference.  I don't have to remember to put in ;'s at the end of each line, for example.  I cant' remember the times in java and c that I spend forever tracking down a missing semi-colon.  How stupid is that?  What is that needed for?  Why doesn't it just use the carriage return?  Vb is syntax is how you would write it down on paper if you were working out  the logic... no brackets, no semi-colons, no nonsense.  Not to mention that java is case sensitive which is retarded.  I know it was written for sun but why in the world would you ever want to make a function called 'Bob' and another function called 'bob' and run them in the same program?  That's not only confusing, but bad coding technique.  They should have nixed the case check and made the whole thing a LOT easier.  

Anyway now it sounds like I'm dumping on java which wasn't what I wanted to do, that's why I didn't do specific examples last time, but you guys asked for it...... sorry.

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #105 on: September 18, 2002, 03:33:55 pm »

Yeah, I took a symester or two of java.  I'm sorry if I didn't use the correct teriminology.  I didn't mean a true.h file, what I meant was the fact that you have to tell your main the other files exist. Vb doesn't do that as do many other proprietory languages.  In vb if you have 20 module files you never have to write a single line of code setting those up, the development package does that for you automatically when you compile.  This is how it should be btw for all langs.    

Wrong!  You have to add the module to the project!  The IDE does all the including for you.  Adding the module to the project is pretty much the same as using an include or import statment.

Quote

Memory managment, pointers, the built in functions that make c so much more versitile are often missing in java or they are replaced by a much more complex calling method.  Sorry if you haven't ran into that before.  

Doesn't mean VB has its time because of its limitations where you have to be more complex than another lanagauge.

Quote

And yes ease of syntax makes a HUGE difference.  I don't have to remember to put in ;'s at the end of each line, for example.  I cant' remember the times in java and c that I spend forever tracking down a missing semi-colon.  How stupid is that?  What is that needed for?  Why doesn't it just use the carriage return?

Have you ever written a compiler? It does make sense to use ; or something to denote the end of an instruction.

Plus what about if you want to put the instruction on multiple line?  In VB you have to have  " _" (yes a space in front, THAT annoys me) where in c++ or java you just need that ; at the end of the instruction.

Quote

Vb is syntax is how you would write it down on paper if you were working out  the logic... no brackets, no semi-colons, no nonsense.  

The is a blessing and an evil to VB.  It's good for some things and bad for other things.
I'm surised you aren't suggestion COBOL, if you want a super easy to write language....


Quote

Not to mention that java is case sensitive which is retarded.  I know it was written for sun but why in the world would you ever want to make a function called 'Bob' and another function called 'bob' and run them in the same program?  That's not only confusing, but bad coding technique.  They should have nixed the case check and made the whole thing a LOT easier.

This comes from little real world experience.  Sorry college doesn't give you  the experience of working with a large team.  One team member makes function FConst() while another makes fConst().  they won't get confused with each other.

Quote

Anyway now it sounds like I'm dumping on java which wasn't what I wanted to do, that's why I didn't do specific examples last time, but you guys asked for it...... sorry.

Actaully, it sounds more like inexperience.  Granted I have only been out of college a year or two more than you, I have learned alot more than what college has taught me.  You know when oyu sit in class, the teacher is trying to teach you something new, but you really don't pay attention because you think you will never use it.  Haha, amazing how some of those thoughts you actually use in the "real" world.

when choosing a compiler, you have to think about what tasks you probably will end up doing.  Like I know it is easier in VB to use an access db, that why I use VB for my backend to my FE.  java has awesome XML, string parsing, and true OO which gives it advantages over other langauges.    

Personally, I think java is one of the best languages out there.  The VM may not be fast, but this isn't about the VM, it's about the language.  When I program I completely think in OO so java comes naturally to me.

Can you use inheritance in VB?   Thisis an extremely powerful characteristic of OO programming.  Like I've been redoing the AI for armagetron.  Being able to inherit the original AI class and override functions is very nice.  I don't have to change anything to someone else's code.  I can just plop my code in and it works.  Pretty cool!

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #106 on: September 18, 2002, 04:08:00 pm »
Ok, restarting from square one.

Actually, I reread what I wrote.  The most important stuff is after the ****.

Ok, let's think about what the advantages of some langauges are over others, and the feature one would need in an FE.

So, I am going to ask a bunch of questions.

Very first question.  should there jsut be an open source backend?  Since everyone has their own opinion on FEs it is impossible to make an open source FE everyone will like.  But I'm not stopping you:)

Second, should it be crossplatform?
Actually, I have mixed feeling on this.  It definately won't be for macmame has that is like mame32, it has it's own gui.
But for OS X, linux, any other unix port it would be nice.

Second, this answer somewhat depends on if it should be cross platform and just a backend.  Should the data be stored in text files or a db.  Personally, if it isn't going to be crossplatform then a DB is great.  SQL is very fast and really easy to use to get the data you need, no multiple parsings of text files, smaller memory footprint.  Yes, a small memory footprint is somewhat important.  Not everyone is going to be using a 2Ghz machine is 1g of memory.  Some of us have a PIII650 with 128 megs of ram in their cabinet.  well, if oyu want to play a larger rom you need the memory open.
However, text file does have it's advavtages.  A pure textfile has a huge disadvantage of that you need to manually parse.  However, that's where XML comes in.  Using an XML parser does all that for you if you store the data in XML format.  Also is a textfile is crossplatform too.

If one uses a text file what language is best suited for it.
Non cross platform, VB.
Cross platform, java.  Java has AWESOME string parsing and an very good XML parser, so I hear.
c++ sucks at string parsing.  Though, if it wasn't cross platform, only on windows, it is really easy to use XML 4.0 from M$.

Now, one would say why not include c++ if it is crossplatform.  Well, c++ code may or maynot be crossplatform, the executable isn't.  With java, the whole purpose of java, is to have to make the bytecode only once and be able to run on any machine.


So, after all that is said, for a backend I suggest this:
not crossplatform: VB with XML or Access
crossplatform: java with XML

now, this is just the backend.  That means an FE would have to talk to it.  So being able to easily interface with it it important.
Non crossplatform:  VB solution, use a dll.  you can;t get much easie to interface than an axtiveX dll.
crossplatform:  well, there's java's downfall in this situation.  It would be very hard to make a non java FE then.

Ahhh, but there is another solution to the crossplatform then.  One, you'd have to use a flatfile textfile, not XML.  Second, it would be done in c++ code.  The code itself would not compile into anything, liek a dll or exe.  The c++ code is just classes to access mame and the data.  You then just have to add those classes into your c++ FE project.

****

There are many different solution to this problem.  Guess what, there is an FE for almost each of those solutions already.
That makes you think, WHY make a universal backend.  easy, configuration.  We all know no one can agree what the best FE is.  That's why there are so many.  Each person has their own taste on what an FE should be.  BUT with a universal background, each FE would pretty much be configurable the same way.  It'd make switching FEs easy or trying out someone elses much easier.  now, my question is, do we really need that?


Actually, what I think is more needed, is something like my c++ solution idea above, but for each language.  That way an FE developer just has to add files to a project and not worry about anything but GUI and usability.
« Last Edit: September 18, 2002, 04:10:45 pm by SirPoonga »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #107 on: September 18, 2002, 04:47:18 pm »
hehe, )p( IMed me almost instantly after I posted the above posts.  we were talking about it.

Here's a better idea.  The fundamentals need to be done first.  A uniform catver/datfile system.  That's  good first step.  Then it's just hops, skips, and jumps to make something that accesses the info from combining data from catvers and datfiles.

One thing, a catver should not be needed, but the datfile should.  The catver is just nice to know what category and what version of emu the rom belongs to.  that actually is a challenge.  Hence that's why lazarus requires a catver for anything along with the datfile.  If that statement is wrong correct me if I didn;t interpret lazarus correctly.
« Last Edit: September 18, 2002, 04:48:47 pm by SirPoonga »

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #108 on: September 18, 2002, 05:30:47 pm »
Yeah, I took a symester or two of java.  I'm sorry if I didn't use the correct teriminology.  I didn't mean a true.h file, what I meant was the fact that you have to tell your main the other files exist.


You must be talking about the "import" statements at the top of the file.
Quote
Vb doesn't do that as do many other proprietory languages.  In vb if you have 20 module files you never have to write a single line of code setting those up, the development package does that for you automatically when you compile.


Hmm... "import" statements are *optional* in Java.  You're free to use the full class name.  If you're lazy and are on a small project, just put all your code in the same package.  Voila... no need for imports.

BTW, having packages and importing them is a Very Good Thing in the Real World.  Try working on a non-trivial project of more than 20 files and you will quickly learn the value of reducing namespace collisions.
Quote
This is how it should be btw for all langs.


That's a very bold, arrogant, and incorrect statement.  It's statements like this that really show your naivete.
Quote
Memory managment, pointers, the built in functions that make c so much more versitile are often missing in java or they are replaced by a much more complex calling method.  Sorry if you haven't ran into that before.


That's funny.  Most people would say that not having memory management and pointer APIs in Java is a good thing.  I doubt that VB, Flash, and Director have APIs for memory management and pointers, either.  I really don't see where you're going with this argument.

And you still haven't provided a concrete example of one of the "many" functions in C that was left out of Java.
Quote
And yes ease of syntax makes a HUGE difference.  I don't have to remember to put in ;'s at the end of each line, for example.  I cant' remember the times in java and c that I spend forever tracking down a missing semi-colon.


Oh jeez!  You're argument is that the semicolons and curly braces make a HUGE difference?  Puh-leez.  If you were a professional Java progammer, you would code Java for hours just about every day.  If you're a week into your job and you *still* can't remember to put a semicolon at the end of the line, look for another career.
Quote
Not to mention that java is case sensitive which is retarded.  I know it was written for sun but why in the world would you ever want to make a function called 'Bob' and another function called 'bob' and run them in the same program?  That's not only confusing, but bad coding technique.  They should have nixed the case check and made the whole thing a LOT easier.


You probably wouldn't have functions "bob" and "Bob", but there are many cases when different case is a good thing.  For example, if I have a class called "Sprite", I can have a variable called "sprite".  If Java was case insensitive, I would have to call the variable "mySprite" or something like that to avoid a conflict.  Using caps properly is a very *good* coding technique that can make code much more readable.

I really can't understand how requiring someone to type a shift here and there is such a bad thing for a language that not only do you think the language is so bad that you would completely avoid it, but you must tell other people how bad the language is.  If you don't like caps, just type the whole damn thing in lower case.  Java doesn't require you to name classes with an upper case.
Quote
Anyway now it sounds like I'm dumping on java which wasn't what I wanted to do, that's why I didn't do specific examples last time, but you guys asked for it...... sorry.


Your specific examples just show how naive and inexperienced you are.  Inexperience in combo with a closed mind, arrogance, and a strong set of opinions.  That's not a really good combination.  Keep an open mind and lighten up on your opinions a little.  You have a lot to learn.

-Dave

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19400
  • Last login:April 21, 2024, 11:59:54 pm
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re:Open-source front end
« Reply #109 on: September 19, 2002, 12:06:28 am »
Dave what the hell is your problem?  

I stated my opinion and then you guys basically in a nice way accuse me of not knowing what I am talking about so I defend myself and instead of saying "Ok now I understand where your opinion came from."  you attack me again.  

Grow up you big baby.

Don't think like a freakin engineer.  Engineers lack all common sense.  Trust me I am friends with a few.  That is the problem with ALL coding languages today, they are written by engineers and they don't understand a single thing about the common sense factor. Director and VB were companys attempts to make a coding language that even non-programmers could use as was java.  The difference between java and the other two is that java failed.  Java is a good language, but it's not a quick or easy language.  You don't understand that because you code in c and java is a step down from c.  

My wrappers are the best example I can think of.  It took a great deal of thinking outside of the box to get those to the universal level they are now.  A lot of people think they are simple but they are not.  I had dozens of hundreds of possiblities to take into account and yet they still work fairly well.  Do you know why?  I used api calls and functions and quirks that aren't supposed to work and forced them to work the way I wanted.  If you asked an engineer about my wrappers and told him how they work he would say that it was impossible, but guess what... they do work.  Also I was told by several that they would be best coded in java or c or some other language.  Well I tried them in all, and only vb would cut it.  It was the exact same logic and api's across the board but only vb could cut it.  The only way to do some of these tricks was with the aid of invisible forms.  Java's forms slowed machines down to a crawl and visual C++'s coding structure was so rigid that it would'nt even accept the api's in the way I needed to use them.  Do you know why vb worked when the rest didn't?  Simple... it's M$'s baby boy.  Guess what java is sun's baby boy... it's programs work best on a sun box.  Mac's and linux have their own baby boy's  (I'm not familiar enough with either os's to even begin to comment on those two.)  I was trying to prove a point but as usual you engineer mentality types can't see the forest for the trees.  It is completely and totally pointless to make a universal fe when their are so many native languages that are better suited for each indvidual os and application.

Now see how bad and awful that sounds?  I wanted to make my comments "kindler and gentler"  to satisfy a few of you more sensitive types but guys like you have to tick me off and force me to do things the hard way.  

The key to universality is to make config files and data files intercompatible between fe's and let the programmers concentrate on using the universal data we give them.  

>P< and myself have been working on this for some time  to make our fe's compatible and I'm telling you it's much easier this way.  He does his thing and I do mine but when we are done a user will be able to setup either and have the other configured based on the first.


And don't you dare say I've never coded anything serious.  I take this little project of mine very seriously.  Although graphically the code I use in lazarus is nothing special, behind the scenes the functionaly aspect is most likely the most complicated and advanced emulator front-end ever built, period.  That may seem like small potatoes to you but  d@mn well you better keep it to yourself.  You can talk about which language is better as that is a perfectly valild discussion and will lead to knowledge and possbily a solution.  

Leave my understanding of code and ability to program out of it, that's getting personal, and trust me you don't want to make this personal.

Oh and by the way ANY professor of computer science or professional  programmer worth anything will tell you that you NEVER name a variable and a function the same thing.  If the code is worked on by multiple people, same name declarations like that can be extremely confusing.  Since we have stopped pulling punches here I just thought I would point out how foolish you sounded from that remark.

I won't contribute to this thread anymore even though while some of you more hostile types are only talking some of us are actually putting some work in and geting results towards such a goal.  Thanks for being so closed minded Dave, it makes me feel better as a person.  :)

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #110 on: September 19, 2002, 01:05:14 am »
Whoa, settle down people.  HC, that post does show you as close minded too ;)


Anyway, I can see there is no way a project like this can come about.  At least from this group of people.  Too many opinions about wht is the best way.

)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re:Open-source front end
« Reply #111 on: September 19, 2002, 01:49:35 am »

Whoa, settle down people.  HC, that post does show you as close minded too ;)


Anyway, I can see there is no way a project like this can come about.  At least from this group of people.  Too many opinions about wht is the best way.


I am still in for that dat file ini file combo  :D

Peter

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #112 on: September 19, 2002, 01:55:54 am »


I am still in for that dat file ini file combo  :D

Peter


The idea we chatted about?  being able to combine a datfile and a catver file into an XML database?  XML is super easy to create.  I could make something rather quickly.

)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re:Open-source front end
« Reply #113 on: September 19, 2002, 02:01:57 am »



I am still in for that dat file ini file combo  :D

Peter


The idea we chatted about?  being able to combine a datfile and a catver file into an XML database?  XML is super easy to create.  I could make something rather quickly.


Yeah but the first step should be a naming convention for emulators and fields to be used in the dat files. Also we could add optional additional sections to the ini files... Maybe we should start a new thread for brainstorming how to do setup the dat and ini files for specific emulators/gamesystems...

Peter

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #114 on: September 19, 2002, 02:14:41 am »




I am still in for that dat file ini file combo  :D

Peter


The idea we chatted about?  being able to combine a datfile and a catver file into an XML database?  XML is super easy to create.  I could make something rather quickly.


Yeah but the first step should be a naming convention for emulators and fields to be used in the dat files. Also we could add optional additional sections to the ini files... Maybe we should start a new thread for brainstorming how to do setup the dat and ini files for specific emulators/gamesystems...

Peter



Good idea, because this topic is for open source frontend.

Dave_K.

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1807
  • Last login:July 06, 2022, 03:27:30 pm
    • Arcade Fever
Re:Open-source front end
« Reply #115 on: September 19, 2002, 02:19:25 am »
Ouch, after reading some of this, I wonder how any open source project ever started.  I guess this is what happens when you mix CS and non CS majors.

-Dave
« Last Edit: September 19, 2002, 02:21:21 am by Dave_K. »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #116 on: September 19, 2002, 02:26:27 am »

Ouch, after reading some of this, I wonder how any open source project ever started.  I guess this is what happens when you mix CS and non CS majors.

-Dave



Actually, most open source projects start a a hobby project by one person.  Look at mame and linux.  Most didn't start witha  group of people wanting to do the same thing.
And since ther are no managers, supervisors, or higher ups, ina  group situation it is hard to get something open source started.

Management does have a purpose, even if at times they need a swift kick in the head.

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #117 on: September 19, 2002, 03:06:58 am »
Dave what the hell is your problem?


My problem is quite simply this: I got tired of your BS.  I am usually a calm person, and I *rarely* flame people on email, forums, usenet, etc, even when they deserve it.  I am very tolerant and open minded to opinions.  And usually when someone states so much non-truth as you have, I usually just completely ignore it.  I guess you know how to hit my buttons just right, and I felt I needed to respond.

My main point (though you may see this differently) was not to flame you or make you look like an ass.  It was to refute your "facts" as I don't want people to think badly of Java or C just because HC said so, and stated it as a fact.  I probably gave your opinions too much weight and should have never responded.  And it's not only what you say, but how you say it.  Instead of saying "I don't like Java becuase I can't type semicolons" you say "Java is a bad language because it has semicolons".  This first one is stated as an opnion, the second one is stated as fact.  And you didn't present your opinion as fact just once.  I could let that slide.  You did it over and over and over again.  And that's what got to me.

Quote
Don't think like a freakin engineer.  Engineers lack all common sense.


Howard, we were (at one point) talking about an engineering topic, aka how do I pick a language to use for a project.  An engineering topic calls for an engineering discussion.  Remind me never to hire you onto one of my projects.

Statements such as "Java/C/C++ is awkward/slow/bad/non-portable because ...".  NEED to be backed up by FACT.  If you think that presenting an argument and then presenting facts to backup your argument is just for thinking like an engineer, then so be it.  Lawyers may beg to differ.

I won't even bother to coment on the rest of your message as am just completely enraged by it.  You can't recall what I said correctly.

These last few posts got *way* OT as they had nothing to do with Open Source FEs and I do apologize for that.  I will not comment further on this.

As for the original topic.... what was it again?  I think rampy summed up my thoughts on language selection, but somehow I think that language selection wasn't even the original topic.  How about starting a new thread as this one has been left on the grill too long and is a little well-done.

-Dave

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #118 on: September 19, 2002, 03:24:18 am »
atually, I think I summed it up pretty well with
Quote

There are many different solution to this problem.  Guess what, there is an FE for almost each of those solutions already.
That makes you think, WHY make a universal backend.  easy, configuration.  We all know no one can agree what the best FE is.  That's why there are so many.  Each person has their own taste on what an FE should be.  BUT with a universal background, each FE would pretty much be configurable the same way.  It'd make switching FEs easy or trying out someone elses much easier.  now, my question is, do we really need that?


Pretty much, I don't think an open source FE is a good idea.  I do think a common "backend", datfile, whatever you want it to be, a common way to store the information about games.
Kinda like an XML file with datfile AND catver info in it, or something like that.
Then, after that is setup, providing tools to use that with different languages.  Like a set of VB classes and modules to use and parse that data, same with java, c++, perl, python, what ever.
That way the developer just need to include the files in the project.  Say for example you use VB, just include and class and modules.  There will probably be some init functions, the you have a class that stores all the info.

That way There is a common base is FE developers use it.  

I've been working alto if XML in java, c++, and vb lately.  It is very easy to pickup XML.  It essentially is a markup langauge and a db mashed together.  Pretty powerful stuff.  I have been reading the book, "XML for the the real world" by Elizabeth Castro.  Great beginners book.

XML is basically two parts.  the XML file, that stores data and a translator, the uses the data.  It's hard to explain what a translator is.  but essentially that is what is used to "filter" out the data you need.  The cool thing, At least with VB and VC++, it uses the  M$ XML 4.0 parser.  The tool for parsing the text file is already there:)

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #119 on: September 19, 2002, 03:36:43 am »

Ouch, after reading some of this, I wonder how any open source project ever started.  I guess this is what happens when you mix CS and non CS majors.


Well, I hope you pegged me as the CS guy.  Well, ok I was a computer engineering major, but close enough.

BTW, one of the classic flame wars in Open Source lore is between Linus Torvalds and Andrew Tannenbaum.  Tannenbaum started off the thread with a subject of "LINUX is obsolete".  You can almost guess Linus' response.  This was way back in 1992 and Tannenbaum was comparing Linux to MINIX.  It's quite an interesting read:

http://www.oreilly.com/catalog/opensources/book/appa.html

-Dave

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8183
  • Last login:April 12, 2023, 09:22:35 pm
  • The Bears Still Suck!
Re:Open-source front end
« Reply #120 on: September 19, 2002, 04:05:06 am »
Well, if you want flame wars, just goto mame.net....

rampy

  • *shrug*
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2910
  • Last login:March 02, 2007, 11:32:16 am
  • ...as useless as a JPG is to Helen Keller
    • Build Your Own PVR
Re:Open-source front end
« Reply #121 on: September 19, 2002, 11:55:50 am »



Anyway, I can see there is no way a project like this can come about.  At least from this group of people.  Too many opinions about wht is the best way.


FWIW, I think the project can and still be done... I do think open source is preferable way to go (greatest benefit to the community and greater potential pool of contributors) and it opens it up beyond this immediate group.

The project does need some structure in order to choose a direction.  A board of directors so to speak... after a group of core/lead devs/maintainers are chosen/volunteer they could then democratically work out the goals, design, language, etc...  people that are put off by the decisions can choose not to contribute or fork/start their own open source FE in their language of choice...

It would be neat if at the minimum, even if NO code is actually created some sort of standards/specification is hammered out.  FE's could even have a little badge that says "UberFrontEnd 2002 compatible" or something (i'm blue skying a bit here... work with me)

I dunno... maybe we can make it platform/language agnostic modular framework (kinda like what .NET hypes it self to be  -- now I curse M$ daily, but hopefully you know what I'm implying... the whole common IL runtime interpreter thingiemabob...)

*shrug*

Rampy

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #122 on: September 19, 2002, 04:23:47 pm »
FWIW, I think the project can and still be done... I do think open source is preferable way to go (greatest benefit to the community and greater potential pool of contributors) and it opens it up beyond this immediate group.


In theory I agree with you, but reality has proven otherwise.  Game Launcher has been an Open Source FE for almost 3 years now.  I have only once received a patch (which I am grateful of!).  But in general, I have gotten almost zero interest in people wanting to contribute.  It looks like most other Open Source FEs have had similar lack luster followings.

Perhaps I am an ass and people just don't want to work with me.  However the real reason I think is that most people using GL (and FEs in general) do not have programming skills.  Open Source tends to work best when the users are technical and can contribute back to the project.  I think that's why most successful Open Source projects are more infrastructure type stuff: Apache, Linux, Perl, Python, Sendmail, Bind.  The users of these projects are programmers or sysadmins.  They have the ability to fix mistakes, add features, and contribute back.  I don't think a FE has that luxury.

I am open to suggestions (even personal ones) as how to make Game Launcher more approachable to someone who wants to contribute.  I am reluctant to completely scrap GL and start over, though, unless there is significant benefit.

There's a lot of cool stuff going on in the CVS version of GL.  There will be themes in the next version.  And it will be very flexible themes.  I've embedded the Lua language into GL and all themes will be written in Lua.  This should give an enormous amout of power to the theme writer.  I can't wait to get it fully working.

BTW, Lua is an embedable scripting language meant for extending applications.  It's small, effecient, and very portable.  And there's no semicolons or curly braces, either. :)  I've already tested it under DOS, Windows and Linux.  For more info check out:

http://www.lua.org/about.html

I also like having a common back end, or at least a common file format for game meta-information.  This could get rid of my map files.  It would especially be cool to get information for emulators other than MAME.  MAME is nice in that you can get most of the information you need from -listinfo.  Most other emus do not have that capability.  It would be nice to have a consolidated file with all the NES info, for example.

-Dave

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re:Open-source front end
« Reply #123 on: September 19, 2002, 04:36:31 pm »
I think it could happen... but it would work best if we had different people excited about different pieces or modules and then combining them.

It would be great if we could also pull in parts from other FE's especially initially (so if soemone already has -listinfo parsers, we dont' have to do it right away and we aren't testing everythign at once).

btw, JFront is opensource also, but I don't think anyone has ever downloaded the source.

Dave Dribin

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 152
  • Last login:May 26, 2007, 11:17:39 pm
  • ugh... yeah
    • Dave Dribin's Home Page
Re:Open-source front end
« Reply #124 on: September 19, 2002, 04:42:09 pm »
I think it could happen... but it would work best if we had different people excited about different pieces or modules and then combining them.


True, but these could be different modules within the same program/project.
Quote
btw, JFront is opensource also, but I don't think anyone has ever downloaded the source.


Other Open Source FEs are EmuWizard (and Cocktail) and AdvanceMenu.

There have actually been 500 downloads of Game Launcher's source since the last version, which really baffles me.  It's not that easy to compile and no one has asked for help.  I don't know what people are doing with the source.

-Dave

)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re:Open-source front end
« Reply #125 on: September 19, 2002, 04:44:59 pm »


I also like having a common back end, or at least a common file format for game meta-information.  This could get rid of my map files.  It would especially be cool to get information for emulators other than MAME.  MAME is nice in that you can get most of the information you need from -listinfo.  Most other emus do not have that capability.  It would be nice to have a consolidated file with all the NES info, for example.

-Dave



And that is precisely what the dat and carver.ini combo can do for us. The clrmamepro dat files are in mame's listinfo format. Allready there are basic dat files available for a lot of systems. It is not perfect yet but with a bit of standardization of the fields to use I think they can serve as the common file format for out fe's to retrieve the meta information...especially because we all have a way to parse them allready...

Peter

Lilwolf

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4946
  • Last login:July 31, 2022, 10:26:34 pm
Re:Open-source front end
« Reply #126 on: September 19, 2002, 04:48:20 pm »
I have to admit.  I never thought of using t.he .dat files... and I love the idea.

but this will also assume that you have the rom files right?  Can you make a dat file of all your own roms?  I've only downloaded them

)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re:Open-source front end
« Reply #127 on: September 19, 2002, 04:56:17 pm »

I have to admit.  I never thought of using t.he .dat files... and I love the idea.

but this will also assume that you have the rom files right?  Can you make a dat file of all your own roms?  I've only downloaded them


No the datfile contains all the known roms/games. The fe can generate the gamelist in any custom format it wishes from that and check for the availabilty of roms/games and do whatever. This way we have a common base for game information for all fe's to use. Personally I think that is enough...and easily implemented in most of the current fe's because we all alrready parselistinfo fomrat and catver.ini files...

Peter

Peter