Main > Software Forum
BYOFE - *another* frontend?
(1/5) > >>
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:


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

--- End quote ---

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:


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

--- End quote ---

or


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

--- End quote ---

..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!
Navigation
Message Index
Next page

Go to full version