Open-Source Front End Specs

[Lilwolf]

To clean out up the last thread that was starting to be a flame war...  To do this we would need to orginize it a little.  I don't wan't to talk implimentation initially...

These are my takes on the development enviorment.  It We should decide what is required... because some of these will narrow our decisions.

1) Crossplatform:  (windows, linux, mac)
1.5) Crossplatform:  dos
2) Free Development system:  
3) Moduler
4) Easy graphics libraries available
5) Vertical and Horizontal text.

[Lilwolf]

1) Crossplatform:  (windows, linux, mac)

I think these are a must...  (well, I never use mac's... but others do I guess)

1.5) Crossplatform:  dos

I think this is also a must for many in the community.  But this will make EVERYTHING else VERY hard to get.  

2) Free Development system:  

I can't afford to buy a development system at all.  There seems to be GREAT development systems for almost all languages these days.  And if we all agree on one, the make files can be destributed.

3) Moduler

It should be able to swap out parts... At runtime would be best, but not necessary.  But the person compiling should be able to swap out modules and recompile.  If it's forced to be a compile time, we should require the modules to live next to each other nicely... ie, you could have the xml and database modules loaded at the same time... and from the configuration files, it should be able to switch between them.

4) Easy graphics libraries available

I know how to write the code to draw a line from bits (fast)... but I don't want to write them.  It would also be nice to have other utility objects available (vectors, hashtables, sorts, ect).

5) Vertical and Horizontal text.

This is really only for the text.  If you can't rotate the text, its a pain to do it by hand... but there are a ton of vertical cabinets that could use a good FE

[rampy]

I think we should start with broad strokes and then get more granular with the specifics... I'm a little mentally burnt at the moment, but here are some basic functional requirements off the top of my head.

The FE should:

* be able to launch any emu within reason (duh)
* have a customizable look/layout
* be easily configured "tweaked" (advanced gui/.ini files or both)
* support both PC monitors and Arcade monitors

I'm having a hard time at the moment separating "features" from "requirements" in my head...  so that's all I got.

Rampy

PS I wonder if we're serious about this effort if a more "groupware" type exchange medium would be better than msg board posts... jsut a thought ... phpwikki? *shrug*

PSS did I misunderstand what you meant by requirements? if so ... sorry... I musta had my BA/project manager hat on...

[Lilwolf]

I'm trying to create two threads (maybe more).  But this one specifically trying to come up with things that could limit the development system..  Not which one we should use, but what we need it to do.

But great things to add.

Arcade monitors.   I have no idea what this will impact, but it would be GREAT.  But I think this will force dos.

[Dave Dribin]

I would add:

* Playing background music with the ability to skip between songs.
* Fully themable
* GUI configuration program

-Dave

[Dave Dribin]

I wonder if we're serious about this effort if a more "groupware" type exchange medium would be better than msg board posts... jsut a thought ... phpwikki?

I can setup a mailing list.  I find this message board a little cumbersome to use at times.  I've never used Wikki, but if it's PHP, I can set that up on my server, too.  I tend to think most web interfaces are a bit cumbersome, but I'm willing to try it.

-Dave

[Dave Dribin]

Ok, I installed phpwiki.  We'll see how this goes:

http://www.dribin.org/dave/phpwiki/index.php/FrontEndRequirements

-Dave

[Lilwolf]

How do you log in?

Something else we might consider.  We might want to have each of the modules only available on some platforms, but the core is really works everywhere.

why?

Graphics mainly (but might have some issues with databases and xml).
I want a openGL frontend piece.  Well, that kinda kills DOS.  But I would hate to limit the core to not allow OpenGL, but maybe one instance.

[rampy]

Thanks for setting that up Dave!

I couldn't find the "register username" page/area either...

But you can edit documents without a username... it just uses an ip to "stamp it"

rampy

[Dave Dribin]

How do you log in?

You don't need to login to edit the pages.  Anyone can edit and create pages, which is a little wierd.  I've never used a Wiki before, so this is a first for me, too.

I think right now PhpWiki only uses the usernames for tracking history.  You can log in using any WikiWord without a password, if you like.  WikiWords are "capitalized words which are strung together with no spaces between them".  So I can log in as "DaveDribin".  See FAQ #1 for PhpWikie 1.3:

http://phpwiki.sourceforge.net/phpwiki/FrequentlyAskedQuestions

Something else we might consider.  We might want to have each of the modules only available on some platforms, but the core is really works everywhere.

I would agree.  And a good MVC architecture would allow for this.  There code be a 2D view and a 3D view.  Heck there could even be a text view.

I want a openGL frontend piece.  Well, that kinda kills DOS.  But I would hate to limit the core to not allow OpenGL, but maybe one instance.

Well, actually there is a Mesa port to DOS.  But its all software rendering so it may not really be useful in practicality.  But a FE is not gonna be pushing a lot of polygons.  Perhaps with fast CPUs these days, a 3D FE under DOS is a possibility.  But regardless, as long as the architecture is modular, a 2D view could be added as well.

I've actually thought about creating an OpenGL version of Game Launcher but I just don't have the time.  Perhaps you would consider doing this rather than starting your own.

BTW, there is an OpenGL plug-in to Allegro (the graphics lib that GL uses).  Here is a good article:

http://www.pixelate.co.za/issues/6/6/articles/agl-a/index.html

I don't know how advanced AllegroGL is, though.  It may be better to drop Allegro and use SDL + OpenGL.

-Dave

[Lilwolf]

Ok, I have some questions... someone might be able to answer
to start off with, it seems to me that C/C++ is the only language that will fit the bill for everything.  Any others we should be looking at?



Free development system
 any good free IDE's for C++?  

Modular
 how easy is it to load modules after the fact in C++ by name?  Or should we just assume that we will be compiling with all modules connected.

Easy graphics libraries available
 I've heard of a few out there.   Allegro sounds good.  But I would like the core not to assume any of them personally.   So people can use their own... I just want to make sure there are some good ones out there

Vertical and horizontal text
 Anyone with any solutions to this?  Allegro?

Launch any emu within reason
 shouldn't have any trouble with this.
 
Have a customizable look/layeout (themes)
 ....

Easily configured "tweaked" through INI files a GUI or both
 This HAS to be optional.  Many people DONT want a way to configure anything after it's all setup (don't want the kids messing it up).

Support for both PC and arcade monitors
 I'm clueless here.  By arcademonitors i"m assuming we are talking about dos / linux only.  Any comments?

Play background music with the ability to navigate songs
 MP3 files would be nice.  I would love a module to play MP3's instead of roms.  Maybe even a DVD addon and CD player.

Mappable controls (redundant to easily configured )
 The question is if we should put these in an .ini file.  I would say yes, but we have to make sure that there can be more then one (one per control panel at least).

[SirPoonga]

Free development system
 any good free IDE's for C++?  

Borland

[Dave Dribin]

Ok, I have some questions... someone might be able to answer
to start off with, it seems to me that C/C++ is the only language that will fit the bill for everything.  Any others we should be looking at?

Oh, no, not again!

Free development system
 any good free IDE's for C++?

 
I just use Emacs, make, and gdb.  It's probably gonna be hard to find a cross-platform C++ IDE.  For Windows, Dev-C++ sounds interesting:

http://www.bloodshed.net/devcpp.html

But think about what you would be getting out of an IDE.  It's not like we're donig GUI development so I don't see an IDE providing much help.  At the very least, we shouldn't require an IDE, but allow people to use an IDE.  I just like a good text editor, thank you.

Modular
 how easy is it to load modules after the fact in C++ by name?  Or should we just assume that we will be compiling with all modules connected.

It ain't easy to dynamically load C++ modules, especially in a portable matter.  You'd have to look at something like libtool, and even then most loadable modules are meant for C.  One problem for C++ is symbol name mangling.  There's no standard for this, so a C++ DLL compiled with mingw may not be compatible with a C++ DLL compiled with VC++.

Easy graphics libraries available
 I've heard of a few out there.   Allegro sounds good.  But I would like the core not to assume any of them personally.

I can attest for Allegro.  It's awesome.  The only other big one I know about is SDL.  SDL probably has better OpenGL integration.  AFAIK, both provide things like bitmaps, sprites, samples, sounds, and text.  You'd have to do some research to find the exact pros/cons between the two, though.  I can't think of any others.  I think it's actually quite difficult to make the core graphics library agnostic.  It can be done, but we probably won't get it right the first time.

Vertical and horizontal text
 Anyone with any solutions to this?  Allegro?

GL uses Allegro.  It draws text onto a bitmap.  It then rotates the bitmap and copies it to another bitmap.  This final bitmap can be blit to the screen like a sprite.  My first implementation of rotated text was horribly ugly.  The second time around I created higher level components like "labels" and "scrollable lists".  And just like Swing components, it's MVC.  You can then do different views, like one for horizontal, one rotated right, etc.

You can probably do this with any graphics library that can draw text onto a bitmap, not only Allegro.

Launch any emu within reason
 shouldn't have any trouble with this.

It should be easy, but I'm still have issues launching programs under Windows.  This is just my lack of Win32 experience.  Someone with a clue could do this much easier.

Easily configured "tweaked" through INI files a GUI or both
 This HAS to be optional.  Many people DONT want a way to configure anything after it's all setup (don't want the kids messing it up).

One solution is to have the config GUI be a completely separate program.  That way it's easy to lock the configuration: just don't launch that program.  Plus, you could do a proper Windows app or even a Java Swing app for the config GUI.  Java would be nice 'cuz the GUI would then be portable to most platforms and Swing is pretty cool.

Mappable controls (redundant to easily configured )
 The question is if we should put these in an .ini file.  I would say yes, but we have to make sure that there can be more then one (one per control panel at least).

This can be done in an INI file.  The next version of GL will have super flexible mappable controls all setup in an INI file.

-Dave

[SirPoonga]

But think about what you would be getting out of an IDE.  It's not like we're donig GUI development so I don't see an IDE providing much help.  At the very least, we shouldn't require an IDE, but allow people to use an IDE.  I just like a good text editor, thank you.

Um, then you aren't making an FE!!  This thread is about a frontend, not purely a backend.

It ain't easy to dynamically load C++ modules, especially in a portable matter.  You'd have to look at something like libtool, and even then most loadable modules are meant for C.  One problem for C++ is symbol name mangling.  There's no standard for this, so a C++ DLL compiled with mingw may not be compatible with a C++ DLL compiled with VC++.

Easy graphics libraries available
 I've heard of a few out there.   Allegro sounds good.  But I would like the core not to assume any of them personally.

I disagree.  There is an ANSI standard for class files.  As long as a person includes these class files into a project there wouldn't be an issue.


An open source frontend should work with the open source data control )p( and I have been hinting about.  I could see it has two projects that work together.

Also, try not to make the INI file so huge.  It doen't need to be if the FE can read meu config files.  Actually, I see three project.  A backend, for grabbing data (like categories, romnames, etc, the data storage).  Utilities to read configs from emus, that way , mame for example, you just have to "register" mame with the FE, it will get the rom paths and such from the mame.ini.  Third would be a GUI.

Between the first two projects is a standardized datafil/catver/whatever format.

[Dave Dribin]

But think about what you would be getting out of an IDE.

Um, then you aren't making an FE!!  This thread is about a frontend, not purely a backend.

But the front end we've been describing doesn't have any GUI in the traditional sense. A GUI builder would be useless.  Eh, IDE vs. text editor is another holy war which I really don't want to be apart of at the moment.  If you guys standardize on an IDE and its free, perhaps I'll give it a shot.  Otherwise, I'll find a way to use a text editor.  This doesn't have to be an either/or decision and we should be able to accomodate both camps.

It ain't easy to dynamically load C++ modules, especially in a portable matter.

I disagree.  There is an ANSI standard for class files.  As long as a person includes these class files into a project there wouldn't be an issue.

Well, I'll admit, my experience with this is a couple years old.  Things may have progressed since then.  I know the original ANSI C++ std did not specify an ABI, but perhaps they made an addendum since then.  The proof is in the pudding.  If you find a way that works in a portable manner, I'm all for it.

-Dave