BYOFE - *another* frontend?

[screaming]

  I started BYOFE a while ago and tried out different graphic libraries, first with SDL, then to Allegro, DirectX (DirectX was just too painful), then back to Allegro. Sticking with Allegro gives us the ability to run on many OSes, including Windows, Linux, and DOS. Being coded in C++ also gives us a great chance for interoperability.

Is there any interest for another front end? Does anyone else out there feel frustrated with the current iteration of front ends?

  I was working on it by myself pretty dilligently for a while there until the summer came around.  Now, 6 months later, it doesn't look like the FE scene has changed too much.   BYOFE will be:

1) Easy to configure. You should be able to hand-edit the configuration files and there should be an integrated interface to guide you along. In addition, just about everything should be as automatic as possible.
2) As flexible as possible but not at the expense of #1.  By "flexible" I mean:
    - Built-in supports for a range of emulators
   - Can add support for more emulators easily
   - "skinnable"
   - multiple emulators per "game list"
   - the possibility, via configration, of a "tree" view of the emulators/games.
3) It should be fast.
4) It should have integrated support for the most common hardware: ArcadeVGA, GP49s, KeyWiz, IPAC, etc.
5) It should support older hardware wherever possible, but not at the expense of *useable* features.

Basically there are only 2 configuration file: a config file to tell some global and default info and an input map (mapping letters/keypresses to "free form text"), then you had your layout. Each layout had one layout file (which could be split into two, and you'll see why in a sec). The layout file is a config file with layers (pretty much) and thier respective properties and a bunch of actions that mapped a "free form text" keypress to a list of actions.  All this was done using quasi-CSS-style configuration, so it's very easy to see and understand.  The config with the layers and the config with the actions could be split into two files for readability.

http://byofedev.bluecamel.org/browser/bin/byofe.conf?format=raw
http://byofedev.bluecamel.org/browser/bin/inputmap.txt?format=raw
http://byofedev.bluecamel.org/browser/bin/layouts/Default/layout.txt?format=raw
http://byofedev.bluecamel.org/browser/bin/layouts/Default/actions.txt?format=raw

Eventually, it's just a matter of implementing different actions for the emulators, like:

ACTION {
  key:    2nd Player, Button 2
  action: launch_daphne997(../emus/daphne/daphne.exe [name], Gamelist)
}

or

ACTION {
  key:    2nd Player, Button 2
  action: launch_vbscript_plugin(plugins/vb/daphne.vb [name], Gamelist)
}

..etc.

Is there anyone interested in a new grassroots foreward thinking FE, that actually aims to be user friendly?

Edit: If you're interested in helping out with creating such a front end, PM me.

[jjd]

Yep.

[Howard_Casto]

I don't mean to discourage your efforts in any way, but except for the built in hardware support you have prefectly described dk. 

Right down to the externalization of specail case emulators dk does exactly what you are saying in more or less the same way. 

Now if you don't like dk that's fine but it's very hard to say you are frustrated with the current fe's and have a better solution when your better solution is the one I am already using. 

[screaming]

my (our) solution will always be better than DumbA.exe, no matter how high you think your pedestal is.

[Sprucemoose]

I am very interested!

[Howard_Casto]

my (our) solution will always be better than DumbA.exe, no matter how high you think your pedestal is.

Huh?

What does the wizard have to do with anything?

Going down your list:

1.  Check
2.  Check
3.  Check
4.  Not Check
5.  Check

I didn't say it is exactly the same but this is pretty much the exact framework around which dk is based.  Most fes are based this way actually which is why I'm pointing it out.  I wouldn't have said a word except for the fact that you went into this big speech in that other thread about how none of the fes are user friendly and the course of action you've laid out isn't any different for the others already available.  

I think you are confused as you who is on the pedestal.  Your goal seems to be to make things more user-friendly but if those are your methods then you could only get things marginaly better at best in that department.  That is unless you have a TON of time to dedicate to this, like several hours a day.  By default things can't be done automatically if you are going to support multiple-emulators.  You can make plugins like youki does, or wrappers like I do but with the former the user has to wait for the developer to make a plugin for every single thing imaginable and not only that keep them updated and with the latter specialized configuration is required.  Mutiple emulators in the same gamelist requires some sort of filtering system like dk uses.  Even if you make it butt-easy the average user will never catch on unless you keep it really simple and in that case you've crippled the power of your filters and thus there really isn't any reason to do it.  Tree's are not easy to build automagically.  I just finished a new configuration program for dk that automatically makes the lists for each genre complete with subtree's navigation, ect....  Even with the catver.ini as a guide there was a lot of special case stuff that had to be done based on mame's crazy cats.  Any other trees would have to be manually and even with a easy to use helper app it'll confuse the heck out of users.

See the thing is you can't have it both ways.  You can try to have a nice balance, but the more features you add, the more configuration is needed, and even if you make it super easy people will always complain that it could be easier.

I wish you luck man, but you seem to be re-inventing the wheel yet again.  If that makes you mad then don't start posting a bunch of crap in this thread about how I am wrong.  Prove me wrong by actually doing it.    

[screaming]

my (our) solution will always be better than DumbA.exe, no matter how high you think your pedestal is.

Huh?

 

  If you would like me to reiterate why your FE (and everyone else's) doesn't meet my criteria, please start a new thread or ask me in one of the already existing threads on the subject.  I would like to keep this thread relevant to BYOFE.

[screaming]

Edit:  Weird.. I edited this message and then came back to it just now (an hour later) and my changes seem to be gone! hmm.. Let's se if I can remember what they were.

This isn't a final list, by any means, it's just a starting point.

BYOFE has very close to the framework needed for most of this stuff and implementing these features should be relatively easy (at least I had all these in mind while I was programming it back 6+ months ago).

Implementing these features in any FE is no easy task, especially one that is just starting out like BYOFE. It will be much more productive if we all got together to build it instead of just one person.  If you have any interest in helping out, please PM me!  You've seen the code, you know what I've got. 

Also, if you have any opinions on this list I'll be happy to hear constructive thoughts.  Are there features you like/dislike?  Maybe some that are more useful than others?  Do you have any wishes that are not on this list?


BYOFE planned features
-----------------------------------------
- Main program
  - The list scrolling should be capable of "MAMEWAH speeds". You know, fast.
  - 3D cabinet models, in addition to standard artwork.
  - WAV, MP3 support
  - Speech engine for on-the-fly announcements: "Get ready for... MOON PATROL!"
  - 3D support, for fancy layouts like wheels.
  - ROBUST gamelist filtering. Having "easy" gamelist filtering is secondary, but no matter what the average user will have basic needs, and game list filtering should be easy for these people, at least.
  - Should be knowledgeable in that it knows about the majority of the popular emulators out there and compensate for their lack of cabinet-friendlyness. Automatic "exit key" always exits the emulator, for example. No need for wrappers.
  - Knowledge of controls.dat project, including integrated layout viewer.
  - Have LED support.
  - Have a "plugin" architecture, as to remain extensible. Possibilities include a python/javascript/ruby/vbscript interpreter or compiled plugins that use BYOFE's API. Plugins could be used for things like fancy lighting, internet communication (updating a "now playing" tag, for example), etc.
  - Animated layouts
  - Layouts should have the capability to be mouse driven (for touchscreens).
  - MNG, animated GIF support
  - Low-res monitor support
  - Integrated pause feature. If I press the pause key, I want certain features (cp layout, custom message, etc) to be available no matter which emulator I'm running. This is a toughy. I don't know how this would work globally and might be restricted to certain emulators.
  - Should be fairly self contained. MAME is the most popular emulator around here so it should be the most supported (incidentally, it's the one that changes the most :/). When BYOFE and DLLs are dropped inthe the MAME folder, it should know about this and configure itself for MAME (yes, automatically).
 
- Config program
  - Should be internet enabled. I want to download config files, layouts, and plugins on the fly without leaving the config program.
  - Should be knowledgeable about the different popular emulators and configure for them automatically. "Daphne has seperate movie and index files? no problem!  The directory structure is in its config file."  "Oops, it looks like your daphne is a little misconfigured. BYOFE recommends __________."
  - Wizard interface to start with, with an "advanced mode" to access all the nitty gritty options.
  - Should conform to and recognize some sort of layout specifications.  The idea is that for the most part, people have thier emulators and emulator support files (cabinet shots, screen shots, etc) in 2 different "layouts". The config program should automatically recognize, and configure for these:
 
  <ROOT>
   |- emus
       |- <EMULATOR>
          |- <EMULATOR.exe>
       |- <EMULATOR>
          |- <EMULATOR.exe>
   |- artwork
       |- <EMULATOR>
          |- <ARTWORK TYPE (cabinets, marquees, etc)>
             |- <ARTWORK.jpg>
       |- <EMULATOR>
          |- <ARTWORK TYPE (cabinets, marquees, etc)>
             |- <ARTWORK.jpg>

and

  <ROOT>
    |- <EMULATOR>
        |- <EMULATOR.exe>
        |- <ARTWORK TYPE (cabinets, marquees, etc)>
            |- <ARTWORK.jpg>
    |- <EMULATOR>
        |- <EMULATOR.exe>
        |- <ARTWORK TYPE (cabinets, marquees, etc)>
            |- <ARTWORK.jpg>

[youki]

I think Howard shoud integrate a  good and smart plug'in system in his DK  to make it open to other Dev. 

Because your "Dream" Fe seems very well on the paper. But even with 20 developpers working on it won't come soon. 

It is not easy to split the work on one FE   for 20 developpers... there is a big project management work.  Not all can be done in the same time.

But i 'm very curious if the project start to see the result , and i will be happy to help if i can.

[Howard_Casto]

I think Howard shoud integrate a  good and smart plug'in system in his DK  to make it open to other Dev. 

Because your "Dream" Fe seems very well on the paper. But even with 20 developpers working on it won't come soon. 

It is not easy to split the work on one FE   for 20 developpers... there is a big project management work.  Not all can be done in the same time.

But i 'm very curious if the project start to see the result , and i will be happy to help if i can.

For once me and youki agree.  It's not that I don't think what you are tyring to do is a bad idea, I just don't think it can be done in the way you are describing.  I know because I've already tried it. 

All of dk's configurations and the generation of lists are done externally.  I did that so that anybody that wanted to make configuration utilities could.  All dk itself does is search for roms, display artwork, and of course launch games which can be supplimented by wrappers.  All the list managment and emu configuration is externalized.  Everything in dk is completely modular.

Instead of making a fe from scratch it might be best to write stuff for existing fes.  Most work how I've described anyway. 

I know that open source sounds like a great idea, but here is what usually happens:

The main developer does all the "real" work, like list managment, rendering ect.....  The only time third parties contribute is to add a really minor thing, like adding a new artwork element, or adding support for non-mame catvers.  This stuff is helpful and all, but it's stuff that the main developer, who is more familiar with the code, probably could have added in 5 minutes. Whats more, like youki is saying the main dev is constantly working on the core and thus the changes might not even be valid by the time they are submitted.  Your users or even other developers will rarely mess with the hard stuff like configuration and list managment because, well that stuff is hard and you don't get any visible reward for your efforts.


Another thing I would like to point out is that ease of use is something you typically want to do later in the fe's life cycle.  While you are figuring out the options and the formatting of everything you'll end up killing yourself playing keep-up with all the configuration utilities.  Dk is towards the end of it's life and that is what I am concentrating on now. Lots of configuration aids.  And remember, it's been over a year since my last release.  That should tell you how much effort is involved to get it right.    Also keep in mind my aids are no where near as "automagic" as what you are proposing. 

[screaming]

Instead of making a fe from scratch it might be best to write stuff for existing fes.  Most work how I've described anyway. 

  I'm not sure if you've seen this thread?

[JoyMonkey]

I hate to say it, but trying to assemble a team for BYOFE in the Software forum is going to be a little less helpful than banging your head repeatedly on a wall. Everyone's FE's are all way too superior than the other guys to be bothered thinking about anything else, and they're just going to keep shouting that at you. Shame.

I can give you a hand with my sweet drawing skillz, but that's about all I can offer.


If the display portion could lean towards how Kymaera did it, it would be cool. PacManFans skin system made it really easy to design for and it was real easy to create skins for multiple resolutions.
Edit: Oh, and support for PNG-24 images with transparencies would be sweet.

[Howard_Casto]

Instead of making a fe from scratch it might be best to write stuff for existing fes.  Most work how I've described anyway. 

  I'm not sure if you've seen this thread?

Yes I have.  Didn't I just tell you that the configurations of front-ends (which seems to be your main concern) are all external?  You don't need the source code for that.  And let me tell you, if you write a utility for a front-end that is really helpful, a dev is going to be a lot more receptive to adding the other things you are talking about. 

[screaming]

Yes I have.  Didn't I just tell you that the configurations of front-ends (which seems to be your main concern) are all external?  You don't need the source code for that.  And let me tell you, if you write a utility for a front-end that is really helpful, a dev is going to be a lot more receptive to adding the other things you are talking about. 

  Are you saying that MAMEWAH Config wasn't really helpful?  There are plenty of users who disagree with you there.

  I don't know anything about DK other than I spent a solid week trying to get it to work and failed. I don't know anything about external, internal or snozzleternal. I love lamp?

[screaming]

I hate to say it, but trying to assemble a team for BYOFE in the Software forum is going to be a little less helpful than banging your head repeatedly on a wall. Everyone's FE's are all way too superior than the other guys to be bothered thinking about anything else, and they're just going to keep shouting that at you. Shame.

   It is a shame. People seem to be afraid of a little challenge in ther old age.

I can give you a hand with my sweet drawing skillz, but that's about all I can offer.

  Hey, those ARE some sweet drawing skills! Is that a liger? bred for it's skills in magic? That's frickin sweet.

If the display portion could lean towards how Kymaera did it, it would be cool. PacManFans skin system made it really easy to design for and it was real easy to create skins for multiple resolutions.
Edit: Oh, and support for PNG-24 images with transparencies would be sweet.

  I'll have to take a look at Kymaera again.. I like the XML idea.

[Minwah]

FWIW: good luck with BYOFE...I have no problem with another FE on the block, and who knows, if I like it better than Mamewah then I can retire

[Howard_Casto]

Yes I have.  Didn't I just tell you that the configurations of front-ends (which seems to be your main concern) are all external?  You don't need the source code for that.  And let me tell you, if you write a utility for a front-end that is really helpful, a dev is going to be a lot more receptive to adding the other things you are talking about. 

  Are you saying that MAMEWAH Config wasn't really helpful?  There are plenty of users who disagree with you there.

  I don't know anything about DK other than I spent a solid week trying to get it to work and failed. I don't know anything about external, internal or snozzleternal. I love lamp?

Mamewah config probably was helpful to mamewah, I don't use mamewah so I wouldn't know.  Personally when I look at mamewah I see the old raging dragon I made several years ago.  It's very limiting graphically so imho and just imho it's the "wrong horse to back" at a point in time where the average mame cab can finally handle a lot more bells and whistles.  

Sorry you didn't get it to work, probably you tried it early on and your pc wasn't up to it yet.  Dk was very future thinking when I started it, it only runs on modern video cards so I can add snazzier effects.  

[screaming]

  I don't WANT to code BYOFE alone. I don't even want to code BYOFE!  There's too much to do here.

  I'd prefer to have my hand in another FE so that we (the community) can see these needed features implemented some time before the year 2010.

[Howard_Casto]

  I don't WANT to code BYOFE alone. I don't even want to code BYOFE!  There's too much to do here.

  I'd prefer to have my hand in another FE so that we (the community) can see these needed features implemented some time before the year 2010.

But here in lies your problem.  To you they are needed features, to the rest of us they aren't.  They are "that would be nice but It isn't a priority" features.  There are plenty devs (myself included) that are more than willing to work with you, but you only seem to want it done your way.  That is fine but it's hard to get a fe author on your side when you are telling them what to do at the same time. 

[screaming]

  Okay, I've pretty much given up in rallying support from you guys, so I'm ready for this thread to be derailed.

But here in lies your problem.  To you they are needed features, to the rest of us they aren't.  They are "that would be nice but It isn't a priority" features.  There are plenty devs (myself included) that are more than willing to work with you, but you only seem to want it done your way.  That is fine but it's hard to get a fe author on your side when you are telling them what to do at the same time. 

  Work with me how?  All I've seen since I got here some years ago is resistance, especially from you! Remember when I went on and on about how dumba.exe was the poo and you went on and on about how only stupid users need a config program and why cant they just edit the config files?  You know, then I proved you wrong by developing MAMEWAH Config?

  Yeah. Which program have you been working on, DK or a config program for DK? In the end, I'm curious to see whether you proclaim that was your idea too.

  Anyway, the only FE developer that seems remotely interested in the feature requests that I have offered in the past is youki, some of which he's implemented to some degree.  I still think it would be faster if he let me (and other people) help though.

[youki]

Anyway, the only FE developer that seems remotely interested in the feature requests that I have offered in the past is youki, some of which he's implemented to some degree.  I still think it would be faster if he let me (and other people) help though.

If you want make some configuration tools for me as said Howard, you are most than welcome.
My totally new configuration tools i started to write are plug'in based. So if you want, let advance a little more in the core of the tool and well define the plug'ins structure and what i need.  And we can try to collaborate.

[screaming]

make it happen.  I'll be waiting.