Cabrio 2.0

[Steve Maddison]

Hi all,

Before anyone gets too excited: no, there is no 2.0 version yet, nor is there even a 1.0 for that matter ;-) I am however thinking about tackling some of the niggly things in Cabrio and whether these would be best retro-fitted to the existing code or part of a complete rewrite.

One thing I'd like to do is to get away from the old OpenGL 1.x code and on to something that will work on OpenGL ES devices as well as the desktop. The pain of doing so may be somewhat mitigated by using an existing 3D engine which abstracts the differences away. I've been looking at Irrlicht and am now playing with OGRE, both of which are C++ based and would probably suggest more of a rewrite than an update.

This brings me to another point, which is whether to stick with C of move to C++ (which seems to be the norm for 3D engines) or even something completely different like Python or Go.

Back on the topic of abstraction, some kind of wrapper around the ever-changing ffmpeg libraries would be great, but I've not found anything like this as yet.

Some other spitballs:

 * Whether to keep the XML configuration files or dump them for something else.

 * Possibly using an SQL database for game lists, etc.

 * Configuration from within the GUI (optional, protected by password/PIN).

 * Custom events/actions for games.

 * Redoing themes properly, with absolute offsets for everything.

 * Building with autoconf (Psychomantis had a crack at this but I never managed to get it working).

 * Arbitrary number of images per game (box, cabinet, control panel, etc.)

 * Game ratings (0-5 stars or similar).

 * Displaying misc. game info text (synopsis, review stars, etc).

 * Attract mode (randomly flip though games at idle).

 * Background pan and zoom.

As fellow developers I'd like to hear your opinions on this stuff, especially the technical decisions if you have experience building 3D apps for multiple platforms.

Cheers,

Steve

[Joseph K]

Steve et al.,

  I had successfully managed to an older code base of Cabrio to C++ with minimal headache. I've also been playing around with Ogre3D for some time now and think it might be a good way to abstract portions of the development. Though I don't have any experience programming for embedded devices, my use for cabrio is more for a Linux based HTPC or Arcade box. Think something like SteamOS on steroids.

While you're correct that the move to C++ is pretty much a rewrite, it wasn't that much of a headache considering the naming conventions used within the C calls. It made conversion to a class-based architecture really simple.

Getting to your bullets:

 * Whether to keep the XML configuration files or dump them for something else.
 * Possibly using an SQL database for game lists, etc.

-- While I'm normally in favor of a relational database so that we can do assorted queries (e.g. "Show me all genesis fighting games"), that makes things trickier for an end user. It would also mean more up-front development to ease that burden of importing and updating data. Another plus is that we could "stream" data by getting a 100 titles and corresponding imagery at a time, instead of an educated guesstimate of where the user will be in their list (read: less brute force import, less overall memory footprint).

 * Configuration from within the GUI (optional, protected by password/PIN).

-- To do this we need to 'settle' on a few common actions. The way we want transitions to behave between main and sub lists; the way we want the main list to behave between selections; the way we want the sub-list to behave; etc...

 * Custom events/actions for games.

-- Are you meaning something like the "themes" for Hyperspin? e.g. a custom backdrop with some animations for the "Fighter" list, which is separate from the "Driving" List?

 * Redoing themes properly, with absolute offsets for everything.

-- I'd normally be up for this too, considering a lot of development seems based on "make the HUD 30% of total screen height". Thought setting "absolute" to (850x, 630y) will push offscreen for 800x600. In other words, we'll need to get really good about boundary checking.

 * Building with autoconf (Psychomantis had a crack at this but I never managed to get it working).

 * Arbitrary number of images per game (box, cabinet, control panel, etc.)

-- This could be done with a database or similar. Hyperspin limits to 5. Commonly the screenshot, cover art, cartridge, game logo, and movie.

 * Game ratings (0-5 stars or similar).

-- This strongly hints at using a database, or maybe pulling from some web database like metacritic?

 * Displaying misc. game info text (synopsis, review stars, etc).

-- This puts a big burden on either the user, or some wget/sed hackery.

 * Attract mode (randomly flip though games at idle).

-- This would be really simple to do. We'll need to make sure we have some "attract mode" settings, such as how long to dwell, volume for sounds, etc...

 * Background pan and zoom.

-- This I think ties into themes and "custom actions/events". Take a look at the different "wheel" settings for Hyperspin. There are settings for how "big the circle is" (size of the on-screen arc, including "vertical"), which side of the screen it's on, how big the icons/fonts are, and the offset from the screen. I think we can take that a step further and have an alpha-numeric grid as part of the drill-down to games.

As an aside, I used Hyperspin on my arcade cabinet before I finally decided I was sick of dealing with Windows. One of my biggest gripes was when I had a MAME or SNES list of over about 75 games, it became a pain in the ass to find the one I wanted. Hyperspin would also crash if an individual game list (it stores systems in an xml, and each system's game list in a separate xml) got over roughly 200 or 250, it would just crash. It made me have to focus on the "top games" instead of a full arcade in one box.

If you guys give the thumbs up, I can begin porting to C++ and OGRE pretty quickly. At least the first crack at it, I'm no OGRE expert, but could get something functional.

Regards,
Joseph

--
You received this message because you are subscribed to the Google Groups "Cabrio FE Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cabrio-fe-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Maddison]

On 31 August 2014 21:45, Joseph K <jcko...@cs.unm.edu> wrote:

While you're correct that the move to C++ is pretty much a rewrite, it wasn't that much of a headache considering the naming conventions used within the C calls. It made conversion to a class-based architecture really simple.

That's good to hear. I guess if you took all the structs as classes and the functions as methods, you'd be well on your way.

 

Getting to your bullets:

 * Whether to keep the XML configuration files or dump them for something else.
 * Possibly using an SQL database for game lists, etc.

-- While I'm normally in favor of a relational database so that we can do assorted queries (e.g. "Show me all genesis fighting games"), that makes things trickier for an end user. It would also mean more up-front development to ease that burden of importing and updating data. Another plus is that we could "stream" data by getting a 100 titles and corresponding imagery at a time, instead of an educated guesstimate of where the user will be in their list (read: less brute force import, less overall memory footprint).

A requirement would indeed be to manage everything going in and out ourselves; the database would need to be completely invisible to the end user. Importing existing XML file should be easy enough but generating everything from scratch is a lot of work.

 

 * Configuration from within the GUI (optional, protected by password/PIN).

-- To do this we need to 'settle' on a few common actions. The way we want transitions to behave between main and sub lists; the way we want the main list to behave between selections; the way we want the sub-list to behave; etc...

Yep, that and a lot more. Considering the above (database stuff) you'd need to be able to manage game lists, emulators, categories and everything via the interface too. Either that or have some external tool(s) that manipulate the database, at least to start off with.

 

 * Custom events/actions for games.

-- Are you meaning something like the "themes" for Hyperspin? e.g. a custom backdrop with some animations for the "Fighter" list, which is separate from the "Driving" List?

That too, but basically something to do some arbitrary action (e.g. run a command) for a game, from within the GUI.

 

 * Redoing themes properly, with absolute offsets for everything.

-- I'd normally be up for this too, considering a lot of development seems based on "make the HUD 30% of total screen height". Thought setting "absolute" to (850x, 630y) will push offscreen for 800x600. In other words, we'll need to get really good about boundary checking.

Most of the relative stuff just comes from the nature of using OpenGL, where everything is of course relative by definition. We're not likely to be able to get away from it completely, but thats not necessarily a problem. It would be nice to have some of the interface components in a 2D layer above the 3D stuff though.

 

 * Arbitrary number of images per game (box, cabinet, control panel, etc.)

-- This could be done with a database or similar. Hyperspin limits to 5. Commonly the screenshot, cover art, cartridge, game logo, and movie.

Yeah, I'd like to eliminate that limit and allow the user to define the things they want to display, based on a few primitive types (image, video, maybe even a sound track).

 

 * Game ratings (0-5 stars or similar).

-- This strongly hints at using a database, or maybe pulling from some web database like metacritic?

 * Displaying misc. game info text (synopsis, review stars, etc).

-- This puts a big burden on either the user, or some wget/sed hackery.

Above two are kind of related. It's be cool to scrape a lot off the web (maybe snaps, etc. too) but configuring manually would be a good start.

 

 * Attract mode (randomly flip though games at idle).

-- This would be really simple to do. We'll need to make sure we have some "attract mode" settings, such as how long to dwell, volume for sounds, etc...

I think this would be really cool. I never did it before because I wanted to do it with a proper spin of the wheel, not just the sort of shuffle effect used for skipping to the first game with the next initial letter.

 

 * Background pan and zoom.

-- This I think ties into themes and "custom actions/events". Take a look at the different "wheel" settings for Hyperspin. There are settings for how "big the circle is" (size of the on-screen arc, including "vertical"), which side of the screen it's on, how big the icons/fonts are, and the offset from the screen. I think we can take that a step further and have an alpha-numeric grid as part of the drill-down to games.

Yes, definitely a theme thing. I'd like to see a (probably darkened version) of a screenshot or whatever as the background panning and zooming about. I like the grid idea, we should do that :)

 

As an aside, I used Hyperspin on my arcade cabinet before I finally decided I was sick of dealing with Windows. One of my biggest gripes was when I had a MAME or SNES list of over about 75 games, it became a pain in the ass to find the one I wanted. Hyperspin would also crash if an individual game list (it stores systems in an xml, and each system's game list in a separate xml) got over roughly 200 or 250, it would just crash. It made me have to focus on the "top games" instead of a full arcade in one box.

I suppose big lists and limited controls is a hard problem, although there's no reason we can't support keyboards or whatever too.

 

If you guys give the thumbs up, I can begin porting to C++ and OGRE pretty quickly. At least the first crack at it, I'm no OGRE expert, but could get something functional.

I don't want to commit to any engine (or language) for the "official" Cabrio 2.0 quite yet but a proof-of-concept would be very interesting to see!

Cheers,

Steve

[Jzeme Ocala]

this would be amazing........if you need testers or anything I would be happy to help....particularly with the GLES portions (which I personally feel should be your primary concern.....not only out of personal need, but also because alot of people have been wanting cabrio on the arm boards without using glshim)......just google around and you'll see that I was actually the first person to even get it running on the pi (let alone any arm board)


so if you make a testing branch on git and at least start on the gles conversion i would be happy to test and debug for you (at least on the pi and the cubieboard)

not to mention, if you can get it working via gles then you could even port it to android eventually which would beat out gamesome and possibly bring you a lot of recognition

so I must say a big thumbs up if you can get this going]


as for the other aspects:
-Stay with the XML config......its cross platform and easier to implement

-GUI configuration would be extraneous but quite awesome

-custom events/actions would be useful for adding games that rent run via emulators

-in my experience, game rating are at best ignored or else get in the way

-I would highly m that you look through the code related to the metadata scraper in emulation station for some of the other feature that you mentioned



other ideas would be to use something like the locations tag to set predefined rom, logo, screenshot, background, and video folders for specific emulators and roms
and as far as dealing with large lists, I would recomend using what emulationstation does and switch to a quickscroll after holding the up/down button for x amount of seconds
that way you can keep the program fully function with out a keyboard (which is helpful for arcade cabinets)

[Steve Maddison]

On 3 September 2014 22:28, Jzeme Ocala <jzeme...@gmail.com> wrote:

this would be amazing........if you need testers or anything I would be happy to help....particularly with the GLES portions (which I personally feel should be your primary concern.....not only out of personal need, but also because alot of people have been wanting cabrio on the arm boards without using glshim)......just google around and you'll see that I was actually the first person to even get it running on the pi (let alone any arm board)

so if you make a testing branch on git and at least start on the gles conversion i would be happy to test and debug for you (at least on the pi and the cubieboard)

Yes, I think GLES support is pretty near the top of the list. As you say there are plenty of use cases. We will need to test on as many platforms as possible so thanks for offering to help there.

  

other ideas would be to use something like the locations tag to set predefined rom, logo, screenshot, background, and video folders for specific emulators and roms

I was thinking about this too. The best thing would be a hierarchical set of locations, i.e. is there a specific location for this game, this platform, etc. until you hit a default (or don't find anything). Supporting entire themes in the same way would allow for some pretty cool effects.

and as far as dealing with large lists, I would recomend using what emulationstation does and switch to a quickscroll after holding the up/down button for x amount of seconds

I'd wondering how this would perform, especially on modest systems, as it would potentially mean preloading a lot of images or loading/converting them on-the-fly very quickly (at least as fast as the selector moves). Falling back to rendering text labels might be an option when it can't keep up, then reverting back to images when the selector stops.

--Steve

[Jzeme Ocala]

as far as I know the, the metadata scraper in ES is done primarily during the initial configuration of the system (not "on-the-fly"). so the loading speed shouldn’t be an issue in a final/preconfigured system.

[Steve Maddison]

Yeah, that's what I'd expect. The performance doubts I have are simply about loading the title/logo images from disk (or SD, or whatever) quickly enough when scrolling at high speed.

On 5 Sep 2014, at 03:22, Jzeme Ocala <jzeme...@gmail.com> wrote:

as far as I know the, the metadata scraper in ES is done primarily during the initial configuration of the system (not "on-the-fly"). so the loading speed shouldn’t be an issue in a final/preconfigured system.

--

[Pieter Hulshoff]

Hello all,

Considering my earlier post on the Google group, this might be the correct thread for me to step in on. Having written my own Linux front-end in the past (MAMEd for those with a really long memory), and having recently updated that so that it would also support MESS (local code only) I figure I might consider spending my time on Cabrio FE in stead rather than porting all its cool features to my own front-end. Both are intended for the same purpose after all (Arcade machine control rather than mouse control like MAME32UI), so there really isn't much sense in doing the same things separately. Besides: Cabrio FE already looks much cooler. :) My C/C++ is a bit rusty, but I should be able to be of some help here, though I'll have to start by analyzing the Cabrio FE code to get a good idea of its structure first.

Steve, could you give any insight into the coding process you have in mind? Assuming more developers would be interested to work on this, how would you like to streamline this process?

Since you're looking at a rewrite based on new libraries, setting up a feature list and code/file structure first would probably be a good idea.

 * Whether to keep the XML configuration files or dump them for something else.

XML configuration has its advantages; I currently use the MAME/MESS output internally in my code to create gaming lists, but there's no reason not to write some small tools to automatically create XML files for Cabrio FE in stead. Does Cabrio filter the gaming list in any way, like check whether the games are actually available before showing them?

I would consider separating the paths and element types (screenshot, titleshot, etc.) from the actual game list. I believe people generally keep them separated by system (also to prevent overlap of the same game name on multiple systems), so perhaps a fixed directory structure per system would make sense?
 

 * Possibly using an SQL database for game lists, etc.

This would probably make it hard for the end-user, and I'm not sure if it's not a bit of overkill. Automatic generation of game lists would help though.
 

 * Configuration from within the GUI (optional, protected by password/PIN).

Probably a good thing, though I wouldn't give this the highest priority.
 

 * Custom events/actions for games.

Could you give some specific examples of this?
 

 * Arbitrary number of images per game (box, cabinet, control panel, etc.)

I'd consider showing the different elements in order of definition within the defined skin. That way you can create any number of elements, including box, cabinet, control panel, title shot, screen shot, etc., and have them overlap (with transparency) in any way you want to.
 

 * Game ratings (0-5 stars or similar).

I'd skip this, but being able to add games to a favourites category with filter (only showing favourite games) would be helpful.
 

 * Displaying misc. game info text (synopsis, review stars, etc).

Some of this can be extracted from the emulators; others would have to be downloaded from the internet. There are a few front-ends out there that do this automatically, so it might be of interest to have a look at those?
 

 * Attract mode (randomly flip though games at idle).

Sounds like a screen-saver mode; would probably be nice to have.

Kind regards,

Pieter Hulshoff
http://www.towel42.nl/mame.html

[Pieter Hulshoff]

My own thoughts to this regard were adding 2 buttons: x10, x100, x1000 (both buttons combined) to game stepping to skip 9, 99 or 999 games. That should allow any users to quickly arrive at/near the game they're looking for. Of course, once a game is placed in a favourites filter, the need to use this becomes much less. :)

[Joseph K]

Pieter,
I'm currently working on a C++ based conversion of Cabrio to use
OGRE3D as the graphical back-end. I already have a state machine up and
running, now it's just the task of making sure that I match behavior and
refactor the code. This 'port' isn't part of the main GIT repository, and I'm
just chipping away at it as I find time (I'm also looking for a new job). I
certainly wouldn't be opposed to creating some new branch to throw my code
into and have someone else help out. Right now it's very incomplete.
We always welcome new ideas and new people to help work on it.

I agree we do need some sort of feature list. Github does bug tracking, but
we may consider using something like RedMine to actually manage the project.
It's early for me and I haven't even had my coffee yet, but I did want to toss
my $0.02 in.

As far as process and structure, that's definitely a Steve question.

Regards,
Joseph

[Pieter Hulshoff]

Joseph,

We all understand the time problem; I have a full time job and family as well. :) I'm currently still busy getting my arcade setup to function the way I want it too anyway, but I'll have a look at OGRE3D in the mean time to get familiar with its syntax. I'd love to have a look at your code when it's functional. I also should have a look at the repository systems currently in use, since I'm not familiar with any of them. We're using different systems here at work, and I never needed any for my own front-end, since it was a one-man job.

I also need to have a closer look at Cabrio FE's current feature list (is it written down anywhere?). I've got a base system up and running at the moment, but I don't yet know its limitations. To give you an idea of the features I'm looking for:

Automated game list generation; for Cabrio FE we should perhaps write a few small tools to generate them, and provide the XML files to users. Since these lists will contain all supported games, Cabrio FE should support a filter that only shows those games that are actually available. Does it already have such a filter?

The ability to place a game in a favourites list, and only show those games that are in the favourites list. This way a user doesn't need to scroll through all the supported games to find the one he/she's looking for. Does Cabrio FE already support something like that?

I need to delve a bit deeper into the skinning as well; I'm not yet familiar with all the Cabrio FE options to that regard. Being able to show either a video or a snapshot, depending on what's available, would probably be nice. For the rest, I think the skin should allow any number of elements to be placed with a defined ordering for overlapping. As said: I need to have a look at how it's currently working before commenting on any additional features.

A quick way to work through large lists. As written above: I currently use x10, x100, and x1000 buttons, but I'm open to alternative suggestions. Reading in large lists can also take a long time; I once auto generated a complete MESS list, and ended up with almost 2000 supported systems, and 600k supported games, which took about 20s just to read into the program...

I'd also love to see a complete Linux distribution for Cabrio FE, possibly with support for XBMC as well. I currently have something like that set up on my HTPC (well, with my own front-end in stead of Cabrio FE for now), and thought it would be nice to offer users a complete live USB solution with the possibility of installing it on a HD/SSD.

[Pieter Hulshoff]

All,

I'm not sure if this should be discussed on a Google group or if we should create a developer's mailing list (if Steve's interested of course)?

Some feature proposals, assuming we start with a clean development for version 2 (not necessarily backwards compatible):
- State configuration split between static and dynamic; the last saved as save action or autosave.
- XML emulator game lists generated by added tools.
- Filter on available, mature, clone, verified, ...?
- Selectable favourites lists (multiple for multiple users)?
- Skins using elements; overlapping via Z-axis or fixed order?
- Element types: game name, genre, manufacturer, screenshot, titleshot, marquee, cabinet/game system, flyer, control panel, video, ...?
- Element parameters: x, y, z, x-rotation, y-rotation, z-rotation, width, height, transparency, animation, font, ...?
- Distribution: source code, package, installable live CD/DVD/USB, ...?

Some questions:
- Should we search for graphics artists to create new skins and/or graphics or do we point towards available packages on the internet?
- Which emulators do we wish to provide XML game lists for? MAME and MESS can do this (almost) automatically, but what support do other emulators offer?
- Should we set up repositories, mailing-list(s), ...? Steve, do you have download limitations on your website?
- Should we (also) use torrents for distribution?

[Pieter Hulshoff]

On Friday, September 5, 2014 8:55:01 AM UTC+2, Steve Maddison wrote:

Yeah, that's what I'd expect. The performance doubts I have are simply about loading the title/logo images from disk (or SD, or whatever) quickly enough when scrolling at high speed.

This is indeed a problem, depending on the size of the images. I noticed that it works quite well with the standard snapshots etc. that you can find, but I also created some screenshots of my own for the MSX emulation (I couldn't find any readily available screenshots for that), and game scrolling slowed down significantly. Using an SSD helps of course, but not hugely so. On the other hand: my MAME snapshot directory alone is 495MB; add it all up, and it doesn't sound like something you'd want to store in RAM (not to mention the increase in startup time required to do that).

[Pieter Hulshoff]

I figured it was worth a test, so I created a game list with all supported MAME games; it took over 5 minutes just to start Cabrio FE. Loading on the spot may have its drawbacks, but considering how many systems I'd like to emulate, the loading times for loading everything into memory on start-up would not be acceptable. What's your view on this?

[Joseph K]

This is indeed an issue. It simply doesn't make sense to load up an entire directory worth of data if you are only (say) cycling through 3-4 screenshots, maybe a dozen logo's, a wallpaper, etc...

The solution that comes to mind for me is to minimize the overhead by tying in on of my ideas in the "2.0" thread. Have a default 'font' and background for a particular system. Think a rectangle of the red stripes for Genesis, with a distinctly Genesis font. I would think this would work well for the fast scan, since at most you're looking at roughly 60 small-ish images that can be reused for lettering, plus another simple image for the game "logo" background. When doing a fast scan, no movies or screenshots show up. After stopping for some determined time (e.g. 1 or 2 seconds), we figure out what is drawn on-screen and load the appropriate imagery. I believe some of this can be done by Ogre3D automagically, but will have to investigate once I get there. I have been able to get font and flat imagery loaded in Ogre3D before... dynamic resource management may be interesting.

Regards,
Joseph

[Pieter Hulshoff]

That's basically what Cabrio FE is already doing at the moment, isn't it? Show the static as screenshot/video until game rotation has stopped. What would you consider an acceptable scrolling speed?
In my current code, I manage about 3-5 games per second at 1920x1080, and loading all fixed images on boot (e.g. background), and all dynamic images (screenshot, titleshot, cabinet) on scroll. Cabrio FE does something similar on my system: 4-5 games per second, though I'm not sure if it's internally slowed down or if that's the maximum it can handle. In my old code, I was at about 15-20 games per second at 1024x768, and showing only the screenshots. I haven't figured out which part of this slowdown is due to new scaling functions, screen size increase, and number of images displayed. It would be interesting to see what impact the Ogre3D library will have.

Speaking of images, and especially when it comes to game skin images (like the wheel): do we leave it up to the user, make our own (we'd need a community for that), or should we get in touch with the repository owners like the Hyperspin community? I remember that Steve had a discussion about this on their forum once, since some developers thought he had taken their images for his demo's, but since they were his own that was resolved peacefully. Since they're not interested in developing a Linux version they may be open to the idea as long as proper recognition is given, but we'd have to wait and see. It's difficult enough to get all the resources together for a properly installed system; they're spread out over multiple sites IF you even know where to look.

With regards to the game lists: my little test showed me it's rather simple to create a full game list for at least MAME and MESS; I could write one or two small separate tools in C++ to write them out as soon as we've decided what information should be stored in there. Still provided that Steve's interested of course; it makes little sense to define anything without his input and decision. :) I'd love to take a look at your Ogre3D code though; I've taken a quick look at the website, but it's an extensive library to use, and I for one don't use a very fast system for my Arcade setup. Speed would depend on the chosen skin of course.

[Steve Maddison]

Wow, I've been meaning to sit down and reply to this flurry of activity :) I'll just go through everything chronologically first and if it makes sense we can make some summaries/conclusions towards the end. Here goes...

On 25 September 2014 12:16, Pieter Hulshoff <phuls...@gmail.com> wrote:

Considering my earlier post on the Google group, this might be the correct thread for me to step in on. Having written my own Linux front-end in the past (MAMEd for those with a really long memory), and having recently updated that so that it would also support MESS (local code only) I figure I might consider spending my time on Cabrio FE in stead rather than porting all its cool features to my own front-end. Both are intended for the same purpose after all (Arcade machine control rather than mouse control like MAME32UI), so there really isn't much sense in doing the same things separately. Besides: Cabrio FE already looks much cooler. :) My C/C++ is a bit rusty, but I should be able to be of some help here, though I'll have to start by analyzing the Cabrio FE code to get a good idea of its structure first.

Hi Pieter, as a front-end vet we'd of course be very happy to have you on board! Don't worry too much about rustiness, I have the same (especially when it comes to C++) but I'm sure we'll manage. By all means look through the existing code but I'm expecting 2.0 to be a complete rewrite.

 

Steve, could you give any insight into the coding process you have in mind? Assuming more developers would be interested to work on this, how would you like to streamline this process?

I'm a fan of starting out lean and adding features as time goes on. Once we have a skeleton which does something useful, it's then "just" a matter of picking features off the list and implementing them one by one. Hopefully a simple issue/feature log will be enough to get started.

 

Since you're looking at a rewrite based on new libraries, setting up a feature list and code/file structure first would probably be a good idea.

 * Whether to keep the XML configuration files or dump them for something else.

XML configuration has its advantages; I currently use the MAME/MESS output internally in my code to create gaming lists, but there's no reason not to write some small tools to automatically create XML files for Cabrio FE in stead. Does Cabrio filter the gaming list in any way, like check whether the games are actually available before showing them?

I think we'll be sticking with XML. Cabrio takes the very simple approach of accepting every game you tell it to. Basically, if you don't want it, it shouldn't be in there. This is a decent starting point which can be built on later. As for tools, I think just now there are about as many solutions for generating lists as there are users ;) Shipping something useful would be a good move.

 

I would consider separating the paths and element types (screenshot, titleshot, etc.) from the actual game list. I believe people generally keep them separated by system (also to prevent overlap of the same game name on multiple systems), so perhaps a fixed directory structure per system would make sense?

Yes, this is all stuff that needs to be able to be stored separately (although lumping it together should be supported too). Just now there is no way to handle games with the same names on different platforms but it's something we should definitely do. Just a matter of checking for a file at games level, not hit then check a directory at "platform" level, if nothing's there, check the global location.

 

 

 * Possibly using an SQL database for game lists, etc.

This would probably make it hard for the end-user, and I'm not sure if it's not a bit of overkill. Automatic generation of game lists would help though.

This was really just something I was toying with. If we do end up doing it, it should remain invisible to the user unless they actually want to manage it themself. 

 * Configuration from within the GUI (optional, protected by password/PIN).

Probably a good thing, though I wouldn't give this the highest priority.

Yep, definitely more important things to do but it would be cool to have eventually. 

 

 * Custom events/actions for games.

Could you give some specific examples of this?

Just now the only action is to start the game. Examples of extra actions would be adding to favourites, removing from the list, running some arbitrary command against a game, etc. Would need to be protected in some way to prevent folks from hosing the lists.

 

 * Arbitrary number of images per game (box, cabinet, control panel, etc.)

I'd consider showing the different elements in order of definition within the defined skin. That way you can create any number of elements, including box, cabinet, control panel, title shot, screen shot, etc., and have them overlap (with transparency) in any way you want to.

I'm figuring there will be certain "primitives" like image, video, sound, whatever, which can be used to place things on screen. Then the theme/skin stuff will mash these together to create the desired effect. We kind of have something like this now but the types of media are fixed. It's all in 3D space though, so you can define position, rotation, transparency and stuff.

 

 

 * Game ratings (0-5 stars or similar).

I'd skip this, but being able to add games to a favourites category with filter (only showing favourite games) would be helpful.

Yep, low prio stuff, the favourites ties in with custom actions above.

  

 * Displaying misc. game info text (synopsis, review stars, etc).

Some of this can be extracted from the emulators; others would have to be downloaded from the internet. There are a few front-ends out there that do this automatically, so it might be of interest to have a look at those?

This is likely to be something for later too but checking how others do it is definitely the way to go.

  

 * Attract mode (randomly flip though games at idle).

Sounds like a screen-saver mode; would probably be nice to have.

I have a kind of vision about this, kind of like Cabrio meets Wheel of Fortune. Not hard to implement, either.

[Steve Maddison]

On 25 September 2014 13:36, Joseph K <jcko...@cs.unm.edu> wrote:

  I agree we do need some sort of feature list. Github does bug tracking, but
we may consider using something like RedMine to actually manage the project.
It's early for me and I haven't even had my coffee yet, but I did want to toss
my $0.02 in.

I suspect the simple GitHub issue list will be good enough to start with for a small number of developers and a modest set of features. If things pick up and it becomes a bottleneck, we should definitely look into something more advanced.

[Steve Maddison]

On 25 September 2014 14:41, Pieter Hulshoff <phuls...@gmail.com> wrote:

Joseph,

We all understand the time problem; I have a full time job and family as well. :) I'm currently still busy getting my arcade setup to function the way I want it too anyway, but I'll have a look at OGRE3D in the mean time to get familiar with its syntax. I'd love to have a look at your code when it's functional. I also should have a look at the repository systems currently in use, since I'm not familiar with any of them. We're using different systems here at work, and I never needed any for my own front-end, since it was a one-man job.

I always used Subversion, even if working on my own, just so I could track the history and didn't have to worry about losing code when making big changes. I was apprehensive of distributed version control until I actually started using it, but now I'd never use anything else. So it's going to be git and I'd like to set up git-flow for handling branches.

 

I also need to have a closer look at Cabrio FE's current feature list (is it written down anywhere?). I've got a base system up and running at the moment, but I don't yet know its limitations. To give you an idea of the features I'm looking for:

There's no list as such but then again it doesn't have a ridiculous number of features I guess. The closest we have is the configuration docs, which are pretty much complete. For 2.0 we should document features as we go.

 

Automated game list generation; for Cabrio FE we should perhaps write a few small tools to generate them, and provide the XML files to users. Since these lists will contain all supported games, Cabrio FE should support a filter that only shows those games that are actually available. Does it already have such a filter?

You've probably seen it already but the main filtering capability is the categories system. It's very flexible as anything you add to your games' categories automatically becomes a filter. You can also use multiple lists and filter on that.

 

The ability to place a game in a favourites list, and only show those games that are in the favourites list. This way a user doesn't need to scroll through all the supported games to find the one he/she's looking for. Does Cabrio FE already support something like that?

Custom action again :)

I need to delve a bit deeper into the skinning as well; I'm not yet familiar with all the Cabrio FE options to that regard. Being able to show either a video or a snapshot, depending on what's available, would probably be nice. For the rest, I think the skin should allow any number of elements to be placed with a defined ordering for overlapping. As said: I need to have a look at how it's currently working before commenting on any additional features.

The current theme support is very customisable but lacking in a few areas. I've been thinking about this quite a lot and have a pretty clear idea of what it should become. I really need to sit down and describe it formally and have you guys take shots at it.

 

A quick way to work through large lists. As written above: I currently use x10, x100, and x1000 buttons, but I'm open to alternative suggestions. Reading in large lists can also take a long time; I once auto generated a complete MESS list, and ended up with almost 2000 supported systems, and 600k supported games, which took about 20s just to read into the program...

I'm all for flexibility. Even if there are a hundred different ways to do exactly the same thing, they're all equally valid in my book. Big lists are just a hard problem.

 

I'd also love to see a complete Linux distribution for Cabrio FE, possibly with support for XBMC as well. I currently have something like that set up on my HTPC (well, with my own front-end in stead of Cabrio FE for now), and thought it would be nice to offer users a complete live USB solution with the possibility of installing it on a HD/SSD.

Check out Fred B's livemamecab. XBMC support would be wicked!

[Steve Maddison]

On 25 September 2014 22:05, Pieter Hulshoff <phuls...@gmail.com> wrote:

All,

I'm not sure if this should be discussed on a Google group or if we should create a developer's mailing list (if Steve's interested of course)?

The Google group is for all intents and purposes the developer mailing list right now (if you subscribe for updates it's functionally pretty much equivalent).

 

Some feature proposals, assuming we start with a clean development for version 2 (not necessarily backwards compatible):
- State configuration split between static and dynamic; the last saved as save action or autosave.

Can you explain a bit more about this one?

 

- XML emulator game lists generated by added tools.

Definitely.

 

- Filter on available, mature, clone, verified, ...?

Right now you can do this, it just needs to be part of your game list using categories.

 

- Selectable favourites lists (multiple for multiple users)?
- Skins using elements; overlapping via Z-axis or fixed order?
- Element types: game name, genre, manufacturer, screenshot, titleshot, marquee, cabinet/game system, flyer, control panel, video, ...?
- Element parameters: x, y, z, x-rotation, y-rotation, z-rotation, width, height, transparency, animation, font, ...?
- Distribution: source code, package, installable live CD/DVD/USB, ...?

Yes to all :)

 

Some questions:
- Should we search for graphics artists to create new skins and/or graphics or do we point towards available packages on the internet?

AFAIK no-one but me has sat down and created a theme for Cabrio from scratch, although it is possible. I think to get others involved, you'd need to provide pretty good tools (preferably WYSIWYG) for theme design.

 

- Which emulators do we wish to provide XML game lists for? MAME and MESS can do this (almost) automatically, but what support do other emulators offer?

I suppose we start with MAME/MESS as they provide XML we can use pretty easily. I'm not aware of any other emulators that provided lists themselves but as long as it's parable, we can do it. The other (big) use case is generating a list from a simple directory of files.

 

- Should we set up repositories, mailing-list(s), ...? Steve, do you have download limitations on your website?
- Should we (also) use torrents for distribution?

I don't expect to need any huge amounts of bandwidth to start with. If we're going to be hosting large themes, images, videos etc. that's a different kettle of fish. 

[Steve Maddison]

Yep, this is quite a challenge. A big list shouldn't be too hard to handle on its own but the associated resources are significant. I guess we'll need to make this tuneable in some way, so the user can decide if they want to sacrifice start-up time or memory for speed. Some sane defaults for different sizes of lists will need to be world out.

[Steve Maddison]

On 28 September 2014 01:28, Joseph K <jcko...@cs.unm.edu> wrote:

The solution that comes to mind for me is to minimize the overhead by tying in on of my ideas in the "2.0" thread. Have a default 'font' and background for a particular system. Think a rectangle of the red stripes for Genesis, with a distinctly Genesis font. I would think this would work well for the fast scan, since at most you're looking at roughly 60 small-ish images that can be reused for lettering, plus another simple image for the game "logo" background. When doing a fast scan, no movies or screenshots show up. After stopping for some determined time (e.g. 1 or 2 seconds), we figure out what is drawn on-screen and load the appropriate imagery. I believe some of this can be done by Ogre3D automagically, but will have to investigate once I get there. I have been able to get font and flat imagery loaded in Ogre3D before... dynamic resource management may be interesting.

Interesting stuff. I guess the order in which things are loaded is important in these situations, e.g. theme background before title image, etc. That is of course something we can easily influence.

I remember thinking about having an image-loading thread when working on the earliest versions of Cabrio but in the end it wasn't required. But that's only because the scrolling is limited and skips in the list just load what's needed to populate the screen as it is. There are no doubt some clever solutions to stuff like this, so it'd definitely be interesting to see how Ogre (and others) do this.

[Steve Maddison]

On 28 September 2014 08:39, Pieter Hulshoff <phuls...@gmail.com> wrote:

That's basically what Cabrio FE is already doing at the moment, isn't it? Show the static as screenshot/video until game rotation has stopped. What would you consider an acceptable scrolling speed?

Right now it's really crude but works well at modest scrolling speeds. Basically everything is loaded (and freed) on the fly and in most situations that's enough.

 

In my current code, I manage about 3-5 games per second at 1920x1080, and loading all fixed images on boot (e.g. background), and all dynamic images (screenshot, titleshot, cabinet) on scroll. Cabrio FE does something similar on my system: 4-5 games per second, though I'm not sure if it's internally slowed down or if that's the maximum it can handle.

The animations are indeed limited right now simply by waiting a fixed about of time between frames. What's possible without this limit is of course very dependent on the hardware but I think a reasonably fast PC could scroll a whole lot quicker.

 

In my old code, I was at about 15-20 games per second at 1024x768, and showing only the screenshots. I haven't figured out which part of this slowdown is due to new scaling functions, screen size increase, and number of images displayed. It would be interesting to see what impact the Ogre3D library will have.

There's quite a lot to do for even a simple image. Load from disk, scale to power-of-two dimensions, convert to texture... caching some of this could already save a lot of time. The big killer is of course decoding/scaling video, but thankfully that's only done when everything else has stopped.

 

Speaking of images, and especially when it comes to game skin images (like the wheel): do we leave it up to the user, make our own (we'd need a community for that), or should we get in touch with the repository owners like the Hyperspin community? I remember that Steve had a discussion about this on their forum once, since some developers thought he had taken their images for his demo's, but since they were his own that was resolved peacefully. Since they're not interested in developing a Linux version they may be open to the idea as long as proper recognition is given, but we'd have to wait and see. It's difficult enough to get all the resources together for a properly installed system; they're spread out over multiple sites IF you even know where to look.

Tricky... to start with we could always help out by compiling lists of sources and sites.

 

With regards to the game lists: my little test showed me it's rather simple to create a full game list for at least MAME and MESS; I could write one or two small separate tools in C++ to write them out as soon as we've decided what information should be stored in there. Still provided that Steve's interested of course; it makes little sense to define anything without his input and decision. :)

I'd say, if it's useful, go for it ;) I'm not really sure how the format will differ in 2.0 yet, though. There's no reason you couldn't use another language either, if that's easier or better suited. That said, some kind of common library for reading/writing the lists could be useful.

I'd love to take a look at your Ogre3D code though; I've taken a quick look at the website, but it's an extensive library to use, and I for one don't use a very fast system for my Arcade setup. Speed would depend on the chosen skin of course.

I've been tinkering with Ogre too and it's not exactly easy to get into. I'm wondering if it might be overkill for Cabrio and how it might perform on more modest machines. I've also been looking at Irrlicht, which seems a bit easier to handle. I've not done a proper comparison but it seems a bit more light-weight and less bloated (in terms of features we wouldn't require).

Cheers,

Steve

[Joseph K]

  What piqued my interest about Ogre3D is just how broad spectrum the engine really can be as robust or as small as you need it to be. How I heard about it is the game Torchlight is developed in Ogre3D, and it will run just fine on a netbook. Of course, nothing stupidly fancy going on for that, such as tesselation, high particle count, etc... but we wouldn't need that for our application anyway. Plus, Ogre3D is cross-platform, so we are that much closer to a single code base for all of Ogre's supported platforms. Not so sure it'd be an answer to a Raspberry Pi though.

  All we would really need is a state machine, some textured 'planes' (billboarded, probably), and movie/audio plugins. Ogre only handles imagery, no sound or user input. Of course, if we really wanted minimalist, we'd just stick with OpenGL, or a very thin rendering engine. Part of what I like about Ogre is the c++ nature of it, lots of things are just handled for you, and there's lots of capability for customization. This is far off, but I think it would be cool to import some mesh for logos, and have some interesting lighting on it. Ogre would handle that easy. OpenGL would be a little more difficult, unless we have some pros in the audience.

Regards,
Joseph

[Joseph K]

Another thought is to just go straight to the SDL. No bells and whistles there, and should be simple enough to get a handful of images loaded in, displayed, etc... we'd also have sound and user input, though each thing is a separate .so/.dll file.

-Joseph

[Pieter Hulshoff]

I think it's important to have a look at features and ambitions before deciding upon a library. If we want to do anything 3D, then just SDL is out of the question; SDL + OPENGL could be used (like it is now). If our ambitions go a bit beyond that, then Ogre3D may not be such a bad option considering what I've read about it so far. Sure, it's not that easy to step into, but at least it's not likely to leave us hanging if we grow more feature ambitious either. I do however find it unlikely that the three of us will build something that's feature comparable to Hyperspin; that's a huge program that will require more developers. We may want to consider some compatibility towards it though.

From features we should probably take a look at class structures and file structures, and one of us should build a simple code base on that; I don't think it's easy to write a code base with multiple coders at this time. Individual features could afterwards be added by any of us. Considering that I've already written some code for MAME/MESS output parsing I figure I'll spend some time writing a tool that will generate the XML game lists for all supported systems. Users can then decide which systems they want to include. I would suggest filtering such lists on available games before printing though; this could be done on front-end startup (adding a sorting algorithm is a good feature too). I'll make a proposal for a file format as well. Steve, could you write down your current views on the skinning so I can compare it to what I have in mind?

I propose to load images etc. on the fly until we figure out a way to properly cache this information. It's the easiest solution while still being able to maintain large game lists. I figure most users will want to be able to use a full MAME set at least (I know I do, and then some (NES, SNES, MSX, Megadrive, etc.)), and that took me 5 minutes to load with the current version.

With regards to configuration: I consider anything that can be changed from within the front-end dynamic, and everything that is not would be static. File lists would be static, while favourites list(s?) would be dynamic. Other dynamic information might be: last game played (for each system?), last system played, etc. That way the next boot will bring you exactly where you were when you left. Since not all users want that, such state information saving should be optional.

[Pieter Hulshoff]

On Sunday, September 28, 2014 7:27:24 PM UTC+2, Steve Maddison wrote:

On 28 September 2014 08:39, Pieter Hulshoff <phuls...@gmail.com> wrote:

That's basically what Cabrio FE is already doing at the moment, isn't it? Show the static as screenshot/video until game rotation has stopped. What would you consider an acceptable scrolling speed?

Right now it's really crude but works well at modest scrolling speeds. Basically everything is loaded (and freed) on the fly and in most situations that's enough.

I almost missed this part. If everything is loaded (and freed) on the fly, then why does it take 5 minutes to start up with a full MAME games list? What does it need that much time for?

[Steve Maddison]

On 28 September 2014 21:31, Pieter Hulshoff <phuls...@gmail.com> wrote:

I think it's important to have a look at features and ambitions before deciding upon a library. If we want to do anything 3D, then just SDL is out of the question; SDL + OPENGL could be used (like it is now). If our ambitions go a bit beyond that, then Ogre3D may not be such a bad option considering what I've read about it so far. Sure, it's not that easy to step into, but at least it's not likely to leave us hanging if we grow more feature ambitious either.

As Joseph says, we really don't need very much. As long as we can put images on the screen and manipulate them, the rest is all "regular" coding. The big advantage of using an existing 3D engine/library is that it would abstract away the tricky OpenGL stuff and offer an easy path to supporting multiple platforms.

 

I do however find it unlikely that the three of us will build something that's feature comparable to Hyperspin; that's a huge program that will require more developers. We may want to consider some compatibility towards it though.

 

No, we probably won't reach that level of features, at least not any time soon. Some compatibility with HS would be cool, e.g. reusing themes or stuff like that. Or we could offer conversion/import tools.

 

From features we should probably take a look at class structures and file structures, and one of us should build a simple code base on that; I don't think it's easy to write a code base with multiple coders at this time. Individual features could afterwards be added by any of us.

Yep, we need a foundation to build on really. That is however likely to be rather dependent on the choice of 3D library, although ideally there would to be some kind of layer in there which maps to Orge/Irrlicht/raw OpenGL or whatever. In that case it wouldn't matter and we'd be free to switch between engines without affecting the higher-level features.

 

Considering that I've already written some code for MAME/MESS output parsing I figure I'll spend some time writing a tool that will generate the XML game lists for all supported systems. Users can then decide which systems they want to include. I would suggest filtering such lists on available games before printing though; this could be done on front-end startup (adding a sorting algorithm is a good feature too). I'll make a proposal for a file format as well.

Sounds cool. Maybe your tool(s) could output the existing Cabrio format too? You could also do filtering in the tool, that would help a quick start-up.

 

Steve, could you write down your current views on the skinning so I can compare it to what I have in mind?

 

Will do, I just need to sit down and describe it some time. I'll try and get it done this week.

I propose to load images etc. on the fly until we figure out a way to properly cache this information. It's the easiest solution while still being able to maintain large game lists. I figure most users will want to be able to use a full MAME set at least (I know I do, and then some (NES, SNES, MSX, Megadrive, etc.)), and that took me 5 minutes to load with the current version.

Agreed, loading on-the-fly is simplest. We only need to get into caching and other such stuff if that turns out to be too slow.

 

With regards to configuration: I consider anything that can be changed from within the front-end dynamic, and everything that is not would be static. File lists would be static, while favourites list(s?) would be dynamic. Other dynamic information might be: last game played (for each system?), last system played, etc. That way the next boot will bring you exactly where you were when you left. Since not all users want that, such state information saving should be optional.

Aah, I get what you mean now. Sounds like a good plan to save that kind of stuff for a future session.

Cheers,

Steve

 

[Steve Maddison]

I suspect that this has to do with XML validation/parsing (libxml does this just now) and the rather utilitarian way the configuration and lists are pieced together. Plenty of room for improvement there.

--Steve

[Pieter Hulshoff]

As Joseph says, we really don't need very much. As long as we can put images on the screen and manipulate them, the rest is all "regular" coding. The big advantage of using an existing 3D engine/library is that it would abstract away the tricky OpenGL stuff and offer an easy path to supporting multiple platforms.

Ok, a more fundamental question is then: do we need 3D object manipulation or would SDL be sufficient? I couldn't find much in the Cabrio and HS themes that requires 3D; merely 2D scaling and rotation. What type of features are we looking at that would require 3D? Joseph, what's your status on the Ogre3D conversion?
 

No, we probably won't reach that level of features, at least not any time soon. Some compatibility with HS would be cool, e.g. reusing themes or stuff like that. Or we could offer conversion/import tools.

From what I could find, HS has a very specific theme setup, using multiple fixed layers. Every game though can have its own mini theme as to how it's presented. The wheel spins until it stops, and is then pushed back while the game theme kicks in. HS has a huge community that builds these themes and artwork. Converting them would require permission from the individual theme designers, and compatibility would require users to get their own themes from the HS repositories. I'm not sure what their policy is regarding such compatibility.
 .

Sounds cool. Maybe your tool(s) could output the existing Cabrio format too? You could also do filtering in the tool, that would help a quick start-up.

Sure, that would be no problem at all. We do need to fix that XML loading though. Is libxml really that slow? I used some simple C++ string parsing myself; nothing nearly as sophisticated as XML validation, but it loads a full MAME list in a fraction of a second.
 

Will do, I just need to sit down and describe it some time. I'll try and get it done this week.

Sounds good; perhaps you could also take a look at the HS themes to see how that matches your views?

[Pieter Hulshoff]

Question with regards to the game list: what exactly does Cabrio use the rom-image parameter for and how? Should it contain the ROM extension, like .7z or .zip or is the extension stripped, and the name used to find the matching video/snapshot/....?

[Joseph K]

Get ready... my brain is functioning again and this is a lengthy response.

On 9/30/2014 9:48 AM, Pieter Hulshoff wrote:

As Joseph says, we really don't need very much. As long as we can put images on the screen and manipulate them, the rest is all "regular" coding. The big advantage of using an existing 3D engine/library is that it would abstract away the tricky OpenGL stuff and offer an easy path to supporting multiple platforms.

Ok, a more fundamental question is then: do we need 3D object manipulation or would SDL be sufficient? I couldn't find much in the Cabrio and HS themes that requires 3D; merely 2D scaling and rotation. What type of features are we looking at that would require 3D? Joseph, what's your status on the Ogre3D conversion?

I thought 3D object manipulation would be a cool feature, though I don't really know how useful it would be beyond eye candy. My thought was to be able to incorporate some 3D models into it. Maybe have a theme that is a real arcade, complete with a couple flickering lights. That sort of thing.

I've been sick for the past 3 days or so and my brain hasn't been able to function beyond "hungry" or "sleepy". Thinking more about it, a C++ minimalist conversion wouldn't do terribly well with OGRE... the "libogremain" is on the order of 18MB. And while it does offer some built in resource handling (see http://www.ogre3d.org/docs/api/1.9/group___resources.html), it's intended for more robust visualization than we currently need.

Looking again at SDL (http://libsdl.org/), it interfaces with built-in OpenGL or Direct3D libraries. It's a smaller layer that we could build on. I have developed a bit in SDL as well, as I was trying to get simplistic games running. It shouldn't take terribly long for anyone to pick up.

I just propose as we go toward a C++ implementation, we do so in a very logical way, and each class only performs one job. e.g.:
1) ConfigParser
2) DisplayManager
3) InputManager
4) EmulatorList
5) RomList
6) ImageList
7) MovieList
8) ConfigManager (Parser can go away if we have an XML library we link in here)

Or something to that effect.

No, we probably won't reach that level of features, at least not any time soon. Some compatibility with HS would be cool, e.g. reusing themes or stuff like that. Or we could offer conversion/import tools.

From what I could find, HS has a very specific theme setup, using multiple fixed layers. Every game though can have its own mini theme as to how it's presented. The wheel spins until it stops, and is then pushed back while the game theme kicks in. HS has a huge community that builds these themes and artwork. Converting them would require permission from the individual theme designers, and compatibility would require users to get their own themes from the HS repositories. I'm not sure what their policy is regarding such compatibility.

Themes in HyperSpin have to be specific, otherwise a static parser would barf and you'd get seg faults. All they are is a folder/zip file, an xml file, and a series of images (PNG and GIF for transparency). I doubt there would need to be any "conversion" for a theme itself, though it would definitely be in good taste to get in touch with their community. Their WYSIWYG editor is "okay", I found it cumbersome to use and downright infuriating to get to work right. It crashed. A lot.

Sounds cool. Maybe your tool(s) could output the existing Cabrio format too? You could also do filtering in the tool, that would help a quick start-up.

Sure, that would be no problem at all. We do need to fix that XML loading though. Is libxml really that slow? I used some simple C++ string parsing myself; nothing nearly as sophisticated as XML validation, but it loads a full MAME list in a fraction of a second.

Looking at the XML code I pulled from GIT, libXML doesn't have much stake in it. There's manual string tokenization and comparison to a slew of #define statements. While we may consider moving that workload off to some other library, the problem still remains that for a full MAME set (including duplicates and such), you're looking at thousands of titles. Mamedb.com says there are 6326 good games with clones... include preliminary and it balloons to 18,382. That is a lot of linkage to keep in memory. Hyperspin barfs over roughly 100 items in a list, so we can certainly outdo that.

Lets put some thought into how to minimize the overhead. There is one rule that comes to mind from my web dev days, "it shouldn't take more than 3 clicks to find what you want". Lets see if we can apply that to a drill down list. System/Genre/StartingLetter is 3. I'm sure there are others.

Also, Hyperspin has separate XML files for separate systems. It's an XML file hierarchy. A main that defines the "systems" with emulators. Then "system" xml's that define the game list and attributes. The latter of which can be generated in CLRMamePro. I vote we make ourselves comfortable with that format, it's the gold standard as far as I can tell. It would ease any conversion pain from prospective users as well.

Will do, I just need to sit down and describe it some time. I'll try and get it done this week.

Sounds good; perhaps you could also take a look at the HS themes to see how that matches your views?

While I used Hyperspin on my cabinet while it was running Windows, I still wasn't overly impressed by it.  Some complaints:
1) It maintained a static background
2) Limited to 3 "extra" images (box art, cartridge, +1)
3) "themed" the wheel based on a game list and matching titles
4) Movies could be downloaded, but the titles MUST match EXACTLY (none of this (! T+Eng) bullshit).
5) The font choices sucked, color choices sucked worse
6) The "wheel" was pretty limited, you could make it straight up and down, or adjust the "radius" of the circle it sat on... as well as a limited +/- offset. In addition, wheel images had to be a particular size, or they just looked miserable and overlapped. There was no "highlight" of the current one.
7) Extra animations were in a weird adobe flash format.
8) It was frustrating to find themes that worked together. I might like an NES theme that has some of the 8-bit nostalgia going for it, but if the placement of all the images is completely off from the rest I'm using, it creates a harsh transition for a user.

I think we can do much better. We can support timed fade backgrounds much like selecting a folder for wallpapers in windows. Better transitions between themes (instead of everybody out, black screen, everybody in). We can support more imagery. We can do themes for systems/genres/games as well (though I think games are overkill... who wants to create 16k themes for MAME?). We can bundle a couple open fonts, then allow the user to select their own if they choose. We can allow a default "background" for a game title with the theme, to make it more uniform if the image doesn't exist. We can do many different transitions, such as a Playstation like bar drill-down (left-right selects system, down to get to a game select). We can do a Steam-like grid, with a custom font I imagine we could have "A - D" and "E - L" to help with the selection. Yes, handling different theme "types" means a bit more coding, but the underlying imagery and themes don't necessarily have to change that much. The user can define a "wheel.xml", a "grid.xml" or a "bar.xml", and make that selection in the primary "cabrio.xml" file.

That might actually be a good thing, instead of a dozen different themes, we define a top-level structure that ALL systems adhere to. They just select different "background=" and such. What do you guys think?

-Joseph

[Pieter Hulshoff]

I thought 3D object manipulation would be a cool feature, though I don't really know how useful it would be beyond eye candy. My thought was to be able to incorporate some 3D models into it. Maybe have a theme that is a real arcade, complete with a couple flickering lights. That sort of thing.

I don't see an immediate need for it either, beyond perhaps 3D rotation, but by combining SDL with OPENGL such features could easily be added at a later time. If Ogre3D is as large as you say, perhaps we should consider sticking to the current setup. Perhaps we should take a look at SDL 2.0? My own front-end was written in SDL as well, so I'm familiar with its concepts.
 

Sure, that would be no problem at all. We do need to fix that XML loading though. Is libxml really that slow? I used some simple C++ string parsing myself; nothing nearly as sophisticated as XML validation, but it loads a full MAME list in a fraction of a second.

Looking at the XML code I pulled from GIT, libXML doesn't have much stake in it. There's manual string tokenization and comparison to a slew of #define statements. While we may consider moving that workload off to some other library, the problem still remains that for a full MAME set (including duplicates and such), you're looking at thousands of titles. Mamedb.com says there are 6326 good games with clones... include preliminary and it balloons to 18,382. That is a lot of linkage to keep in memory. Hyperspin barfs over roughly 100 items in a list, so we can certainly outdo that.

I never had any trouble running with large lists; things didn't get out of hand until I loaded all supported MESS systems (about 2k) and games (about 600k), and that was only a problem for loading the game list (took about 20s). Keeping, sorting, and selecting from the game lists was not a problem at all.
 

Lets put some thought into how to minimize the overhead. There is one rule that comes to mind from my web dev days, "it shouldn't take more than 3 clicks to find what you want". Lets see if we can apply that to a drill down list. System/Genre/StartingLetter is 3. I'm sure there are others.

Originally I supported that system as well (though selection of any of those 3 is not a 1 click matter when using arcade controls), but as the lists grew I switched to a system of using 2 buttons to allow selection step sizes of 1, 10, 100, and 1000 (on top of the system selection). We'll need to have a look at what we'll want to use here. I also used the other arrows (the ones not used for game selection) for system selection, rather than using a back button. Both have their advantages; a back button is probably more flexible.
 

Also, Hyperspin has separate XML files for separate systems. It's an XML file hierarchy. A main that defines the "systems" with emulators. Then "system" xml's that define the game list and attributes. The latter of which can be generated in CLRMamePro. I vote we make ourselves comfortable with that format, it's the gold standard as far as I can tell. It would ease any conversion pain from prospective users as well.

I agree, and I'd also prefer a fixed directory structure for other files similar to theirs. This will allow much easier distribution of large sets.
 

While I used Hyperspin on my cabinet while it was running Windows, I still wasn't overly impressed by it.  Some complaints:
1) It maintained a static background
2) Limited to 3 "extra" images (box art, cartridge, +1)
3) "themed" the wheel based on a game list and matching titles
4) Movies could be downloaded, but the titles MUST match EXACTLY (none of this (! T+Eng) bullshit).
5) The font choices sucked, color choices sucked worse
6) The "wheel" was pretty limited, you could make it straight up and down, or adjust the "radius" of the circle it sat on... as well as a limited +/- offset. In addition, wheel images had to be a particular size, or they just looked miserable and overlapped. There was no "highlight" of the current one.
7) Extra animations were in a weird adobe flash format.
8) It was frustrating to find themes that worked together. I might like an NES theme that has some of the 8-bit nostalgia going for it, but if the placement of all the images is completely off from the rest I'm using, it creates a harsh transition for a user.

It's gone through a lot of improvements from what I can see, but I do agree with you on some of these. I'd prefer a more flexible theme setup, allowing skin elements of different types to be placed wherever you want in a consistent matter to allow a common look and feel to a theme. I don't see a need for a "wheel" for instance; simply a matter of allowing different elements with an offset to the current game to be placed on the screen at a specific location, size, and rotation. The amount of community work put into those wheel graphics however is nothing short of impressive. I'd love to be able to use them, and would like to write a short post on their forums to see if it would be allowed to create compatibility with their repositories. Perhaps they'd even be interested in torrent based distribution? Matching names is not an issue; they're using the same names as put out by e.g. the MAME/MESS output; either the short name or the full name. It's the same naming system most graphics/rom repositories use.
 

That might actually be a good thing, instead of a dozen different themes, we define a top-level structure that ALL systems adhere to. They just select different "background=" and such. What do you guys think?

I too would prefer a common theme selection over all systems, with a few differences between systems, such as background images. Let's see what Steve comes up with, and work from there.

On another note: some issues may not be suitable for discussion on an open forum; would you two mind sending me an email so we can discuss them privately? My email address is pie...@towel42.nl.
 

[Pieter Hulshoff]

Ok, I've got a first raw version ready, and created xml files for all MAME/MESS systems with software lists. I'll refine it a bit more and clean up the code in the upcoming days.
Any thoughts on MAME category files you'd like to see in addition? I did read in the catver.ini file, so I've got the games categorized as well.

[Pieter Hulshoff]

I'm running into my first snag. I tested cabrio with 2 systems:
  <emulators>
    <emulator>
      <name>Super Nintendo Entertainment System (PAL)</name>
      <display-name>Super Nintendo Entertainment System (PAL)</display-name>
      <executable>mess</executable>
      <params>
        <param>
          <name>snespal</name>
        </param>
        <param>
          <name>-cart1</name>
        </param>
      </params>
    </emulator>
    <emulator>
      <name>NMS-8250</name>
      <display-name>NMS-8250</display-name>
      <executable>mess</executable>
      <params>
        <param>
          <name>nms8250</name>
        </param>
        <param>
          <name>-cart1</name>
        </param>
      </params>
    </emulator>
  </emulators>

All games however try to start with the second emulator, even though they're split between the two. Any thoughts on what might cause this?

[Joseph K]

Pieter,
  Just taking a stab at this... It looks like config_read_game (config.c:738) has an "emulator" tag, make sure that if you are using that, it's tied to the appropriate one. There is also a "platform" node common to both the "emulator" node and "game" node. Though I can't weasel out how that comes together right now, been a long day and my brain is turning off.

  As a wild guess, it may be looking at the second "executable" instead of "emulator->name". Try using another emulator for the SNES (like zsnes or snes9x) and see if it still gives you a headache.

  My schedule recently became more open, so I'm going to get cranking on the C++ conversion hopefully soon. At near 2500 lines, that config.c is just plain unwieldy.

Regards,
Joseph

--
You received this message because you are subscribed to the Google Groups "Cabrio FE Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cabrio-fe-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pieter Hulshoff]

Thanks for the tips, Joseph, but unfortunately I have the same problem when I use one list for MAME and one for MESS.
We certainly need to solve that long list issue (loading both MAME and SNES lists took forever), and forking also seems to have its problems. It took a long time to get back from launching the first game, and when I tried to launch the second game it told me it couldn't fork anymore. Cabrio was taking up a ton of memory by then. Oh well, gives us something to work on, neh? :) At least I've got a first version of xml file generation to work from; I'll need to look into detail regarding each system, because some systems use other media than cartridges, and currently my system generation's rather static in that regard. I believe I can pull the required information from the MAME/MESS output, but I'll need to have a good look at how to do it.

[Pieter Hulshoff]

Gentlemen,

I believe we have some decisions to make with regards to features:
I've been very impressed with the HS community results when it comes to art (wheel/systems/etc.). I'd love to work together with them to share as much work as possible, even though we'll define our own set of features.
1. Do we follow the HS two-step selection of system -> game, do we use a three-step approach of system->genre->game (only automatic XML file generation possible for MAME at the moment; we'd need catver information for the other systems or do it by hand), or do we come up with a new approach (I use one direction for game selection and another for system selection in my latest code)?
2. Should genre selection be a part of game selection, or should it be an intermediate step? This goes into the heart of the class definition of course: is genre simply a separate system XML file with games, or is it a part of the game definition?
3. I would prefer a fixed directory structure; possibly the same as HS to allow us to share as much code/art/themes as possible. This will make Cabrio much simpler to set up, and it will make debugging user problems a lot simpler as well. Obviously we'll lack some of HS's feature, and perhaps have some they lack (like only showing available games for instance).
4. In fact: I'd like that to be the default: only show the games actually on the system. That way all systems can be in the systems.xml file, and the game XML files for all supported system can be present as well. It doesn't take much room, but it makes adding new systems much easier for the user, simply by adding the corresponding ROM and art files.
5. I would like these files to be a part of the standard directory structure; not a part of a $HOME/.cabrio directory. This way we can distribute packed directory structures with files (possibly as torrent) to allow users to quickly set up their environment.
6. Hopefully we can get permission from HS and Emumovies to do the same for their files, but if not I'll write some tools to automate the installation process after users download the files from their servers using membership there. Obviously we'll add our own art/themes to the process.
7. We need to have a look at file detection. I think identification should be based on:
  1. file name
  2. full name
  3. cloneof file name
  4. cloneof full name
  This should cover most naming systems used by the available repositories.
8. As far as I can tell, the HS game XML files already cover all fields we're interested in. If we were to re-use their format we could share the results of our work with them, and contribute to their community like we benefit from theirs.
9. Is the fork call to MAME/MESS really taking up that much memory (and not freed perhaps?)? I used system calls in the past, which probably have their own problems, and I don't know which system works better.

Let me know what you think. I'll post more if thoughts pop up. :) If we agree that the current XML parsing takes up too much time, and we've decided on file formats and class definitions, I could write the file I/O functions. It would save me some time if I don't have to delve into the OPENGL functionality at this time, have one of you handle that, and make myself useful by writing supporting functions and tools. :) If you could send me an email I could send you some intermediate results as soon as they come available.

[Steve Maddison]

On 30 September 2014 20:31, Pieter Hulshoff <phuls...@gmail.com> wrote:

Question with regards to the game list: what exactly does Cabrio use the rom-image parameter for and how? Should it contain the ROM extension, like .7z or .zip or is the extension stripped, and the name used to find the matching video/snapshot/....?

Yes, rom-image includes the extension and is passed to the emulator to tell it which game to run. If using "locations" the extension is ignored and the remaining part of the file name is used to match images, etc. with any extension.

[Steve Maddison]

On 1 October 2014 01:54, Joseph K <jcko...@cs.unm.edu> wrote:

Get ready... my brain is functioning again and this is a lengthy response.

On 9/30/2014 9:48 AM, Pieter Hulshoff wrote:

As Joseph says, we really don't need very much. As long as we can put images on the screen and manipulate them, the rest is all "regular" coding. The big advantage of using an existing 3D engine/library is that it would abstract away the tricky OpenGL stuff and offer an easy path to supporting multiple platforms.

Ok, a more fundamental question is then: do we need 3D object manipulation or would SDL be sufficient? I couldn't find much in the Cabrio and HS themes that requires 3D; merely 2D scaling and rotation. What type of features are we looking at that would require 3D? Joseph, what's your status on the Ogre3D conversion?

I thought 3D object manipulation would be a cool feature, though I don't really know how useful it would be beyond eye candy. My thought was to be able to incorporate some 3D models into it. Maybe have a theme that is a real arcade, complete with a couple flickering lights. That sort of thing.

I'd never even thought about using actual models... that would allow some pretty awesome effects.

In any case, the existing themes are "real" 3D; rotation and scaling on a 2D plane alone isn't quite enough. Even if it were, you soon end up using OpenGL anyway so you can get hardware acceleration. Software rendering is slow and completely unusable on modest systems like the Pi.

 

I've been sick for the past 3 days or so and my brain hasn't been able to function beyond "hungry" or "sleepy". Thinking more about it, a C++ minimalist conversion wouldn't do terribly well with OGRE... the "libogremain" is on the order of 18MB. And while it does offer some built in resource handling (see http://www.ogre3d.org/docs/api/1.9/group___resources.html), it's intended for more robust visualization than we currently need.

Looking again at SDL (http://libsdl.org/), it interfaces with built-in OpenGL or Direct3D libraries. It's a smaller layer that we could build on. I have developed a bit in SDL as well, as I was trying to get simplistic games running. It shouldn't take terribly long for anyone to pick up.

 

Yeah, the more I think about it, the more it looks like we'll need to bite the bullet and do the 3D stuff ourselves. What would really have been nice was a very lightweight library which just does simple drawing, texturing, etc. of primitives but I've not found anything like that. I still think it would be good to have an abstract graphics layer though, just so it makes it easier to change later.

 

I just propose as we go toward a C++ implementation, we do so in a very logical way, and each class only performs one job. e.g.:
1) ConfigParser
2) DisplayManager
3) InputManager
4) EmulatorList
5) RomList
6) ImageList
7) MovieList
8) ConfigManager (Parser can go away if we have an XML library we link in here)

Or something to that effect.

If we're not going the Ogre route we could feasibly stick to straight C. I do prefer an object oriented approach though, and to maintain the option of using these kind of libraries/engines in the future I think C++ still has the edge. I think what we really need at the moment is to define the minimum viable product on which all the other features can be built. I should be able to whip something like that up this evening.

No, we probably won't reach that level of features, at least not any time soon. Some compatibility with HS would be cool, e.g. reusing themes or stuff like that. Or we could offer conversion/import tools.

From what I could find, HS has a very specific theme setup, using multiple fixed layers. Every game though can have its own mini theme as to how it's presented. The wheel spins until it stops, and is then pushed back while the game theme kicks in. HS has a huge community that builds these themes and artwork. Converting them would require permission from the individual theme designers, and compatibility would require users to get their own themes from the HS repositories. I'm not sure what their policy is regarding such compatibility.

Themes in HyperSpin have to be specific, otherwise a static parser would barf and you'd get seg faults. All they are is a folder/zip file, an xml file, and a series of images (PNG and GIF for transparency). I doubt there would need to be any "conversion" for a theme itself, though it would definitely be in good taste to get in touch with their community. Their WYSIWYG editor is "okay", I found it cumbersome to use and downright infuriating to get to work right. It crashed. A lot.

That sounds encouraging, we could definitely offer some kind of compatibility there.

 

Sounds cool. Maybe your tool(s) could output the existing Cabrio format too? You could also do filtering in the tool, that would help a quick start-up.

Sure, that would be no problem at all. We do need to fix that XML loading though. Is libxml really that slow? I used some simple C++ string parsing myself; nothing nearly as sophisticated as XML validation, but it loads a full MAME list in a fraction of a second.

Looking at the XML code I pulled from GIT, libXML doesn't have much stake in it. There's manual string tokenization and comparison to a slew of #define statements. While we may consider moving that workload off to some other library, the problem still remains that for a full MAME set (including duplicates and such), you're looking at thousands of titles. Mamedb.com says there are 6326 good games with clones... include preliminary and it balloons to 18,382. That is a lot of linkage to keep in memory. Hyperspin barfs over roughly 100 items in a list, so we can certainly outdo that.

 

Maybe we'll end up with some kind of database backend after all. So, at start-up, read in the XML files (possibly ignore those which are unchanged if we saw them before) and pump it into tables. Then you can quickly pull what you want with some simple queries. But for starters I think the "just stick it all in RAM" approach will be OK.

 

Lets put some thought into how to minimize the overhead. There is one rule that comes to mind from my web dev days, "it shouldn't take more than 3 clicks to find what you want". Lets see if we can apply that to a drill down list. System/Genre/StartingLetter is 3. I'm sure there are others.

Also, Hyperspin has separate XML files for separate systems. It's an XML file hierarchy. A main that defines the "systems" with emulators. Then "system" xml's that define the game list and attributes. The latter of which can be generated in CLRMamePro. I vote we make ourselves comfortable with that format, it's the gold standard as far as I can tell. It would ease any conversion pain from prospective users as well.

Right-o, I want to get a good handle on these formats and offer compatibility, as long as it doesn't limit what we're able to do ourselves. The hierarchical approach sounds a lot like what I had in mind too. I still owe you guess a proper description, coming Real Soon Now(™).

Will do, I just need to sit down and describe it some time. I'll try and get it done this week.

Sounds good; perhaps you could also take a look at the HS themes to see how that matches your views?

While I used Hyperspin on my cabinet while it was running Windows, I still wasn't overly impressed by it.  Some complaints:
1) It maintained a static background
2) Limited to 3 "extra" images (box art, cartridge, +1)
3) "themed" the wheel based on a game list and matching titles
4) Movies could be downloaded, but the titles MUST match EXACTLY (none of this (! T+Eng) bullshit).
5) The font choices sucked, color choices sucked worse
6) The "wheel" was pretty limited, you could make it straight up and down, or adjust the "radius" of the circle it sat on... as well as a limited +/- offset. In addition, wheel images had to be a particular size, or they just looked miserable and overlapped. There was no "highlight" of the current one.
7) Extra animations were in a weird adobe flash format.
8) It was frustrating to find themes that worked together. I might like an NES theme that has some of the 8-bit nostalgia going for it, but if the placement of all the images is completely off from the rest I'm using, it creates a harsh transition for a user.

I think we can do much better. We can support timed fade backgrounds much like selecting a folder for wallpapers in windows. Better transitions between themes (instead of everybody out, black screen, everybody in). We can support more imagery. We can do themes for systems/genres/games as well (though I think games are overkill... who wants to create 16k themes for MAME?). We can bundle a couple open fonts, then allow the user to select their own if they choose. We can allow a default "background" for a game title with the theme, to make it more uniform if the image doesn't exist. We can do many different transitions, such as a Playstation like bar drill-down (left-right selects system, down to get to a game select). We can do a Steam-like grid, with a custom font I imagine we could have "A - D" and "E - L" to help with the selection. Yes, handling different theme "types" means a bit more coding, but the underlying imagery and themes don't necessarily have to change that much. The user can define a "wheel.xml", a "grid.xml" or a "bar.xml", and make that selection in the primary "cabrio.xml" file.

Yeah, that's the spirit ;) Eventually it should be possible to do all this and the system needs to be flexible enough to do even more.

 

That might actually be a good thing, instead of a dozen different themes, we define a top-level structure that ALL systems adhere to. They just select different "background=" and such. What do you guys think?

This should definitely be possible. I'll address this better when I sit down later.

[Steve Maddison]

The idea was (IIRC, this is a while ago now) that matching would be done on the "platform" tag. I.e. give both the game and the emulator a platform tag with the same value and it should match the up. Whether it actually works like that is however anyone's guess ;) 

--

[Steve Maddison]

On 6 October 2014 04:58, Joseph K <jcko...@cs.unm.edu> wrote:

  My schedule recently became more open, so I'm going to get cranking on the C++ conversion hopefully soon. At near 2500 lines, that config.c is just plain unwieldy.

I've often thought about automatically generating the code for this. It's very long and error-prone right now.

 

[Steve Maddison]

On 6 October 2014 15:25, Pieter Hulshoff <phuls...@gmail.com> wrote:

Gentlemen,

I believe we have some decisions to make with regards to features:
I've been very impressed with the HS community results when it comes to art (wheel/systems/etc.). I'd love to work together with them to share as much work as possible, even though we'll define our own set of features.

This is kind of a key thing. We need to allow reuse but not allow ourselves to be limited by other similar projects.

 

1. Do we follow the HS two-step selection of system -> game, do we use a three-step approach of system->genre->game (only automatic XML file generation possible for MAME at the moment; we'd need catver information for the other systems or do it by hand), or do we come up with a new approach (I use one direction for game selection and another for system selection in my latest code)?

I honestly think we should allow all of these options, somehow. There are so many different ways people want to set up their cabs; some just have one list of arcade games, others want different systems/emulators, others want a complete compendium of every video game ever made ;)

 

2. Should genre selection be a part of game selection, or should it be an intermediate step? This goes into the heart of the class definition of course: is genre simply a separate system XML file with games, or is it a part of the game definition?

Genre is in essence "just" another attribute of a game; a many-to-many relationship. You can label a file with a particular genre and automatically tag every game in that file with that genre, or put the genre in with the game. If the one in the game takes precedence you could quite easily support both approaches.

 

3. I would prefer a fixed directory structure; possibly the same as HS to allow us to share as much code/art/themes as possible. This will make Cabrio much simpler to set up, and it will make debugging user problems a lot simpler as well. Obviously we'll lack some of HS's feature, and perhaps have some they lack (like only showing available games for instance).

Yep, flexibility is all well and good but we still need *some* structure. We do need to be careful we don't end up working ourselves into a corner though.

 

4. In fact: I'd like that to be the default: only show the games actually on the system. That way all systems can be in the systems.xml file, and the game XML files for all supported system can be present as well. It doesn't take much room, but it makes adding new systems much easier for the user, simply by adding the corresponding ROM and art files.

Sure, we could do this. This would allow people to publish their complete lists and others to reuse them, even if they don't have all the games. I'm not completely sold on it being the default though, it depends on what the user is expecting and you don't want to go silently dropping things if the use thinks they're meant to be there.

 

5. I would like these files to be a part of the standard directory structure; not a part of a $HOME/.cabrio directory. This way we can distribute packed directory structures with files (possibly as torrent) to allow users to quickly set up their environment.

If the data is truly authoritative it can go in /usr/share (or wherever) for sure. It should be possible to override/supplement at the user level too though.

 

6. Hopefully we can get permission from HS and Emumovies to do the same for their files, but if not I'll write some tools to automate the installation process after users download the files from their servers using membership there. Obviously we'll add our own art/themes to the process. 

It might be tricky to strike the right deals but making it easier to use external resources would indeed be a huge plus.

 

7. We need to have a look at file detection. I think identification should be based on:
  1. file name
  2. full name
  3. cloneof file name
  4. cloneof full name
  This should cover most naming systems used by the available repositories.

I have a suspicious feeling this is really difficult to do well. I also rather expect someone's had a good crack at it though and we can probably find some open source solution.

 

8. As far as I can tell, the HS game XML files already cover all fields we're interested in. If we were to re-use their format we could share the results of our work with them, and contribute to their community like we benefit from theirs.
9. Is the fork call to MAME/MESS really taking up that much memory (and not freed perhaps?)? I used system calls in the past, which probably have their own problems, and I don't know which system works better.

Not sure what's going on there.

 

Let me know what you think. I'll post more if thoughts pop up. :) If we agree that the current XML parsing takes up too much time, and we've decided on file formats and class definitions, I could write the file I/O functions. It would save me some time if I don't have to delve into the OPENGL functionality at this time, have one of you handle that, and make myself useful by writing supporting functions and tools. :) If you could send me an email I could send you some intermediate results as soon as they come available.

Cool. I think we need to look at why the list reading stuff is slow right now. It could also be that the XML part is fine but the delay comes from the rather simplistic way the list is built, e.g. it's also sorted just by walking though the whole list until the right spot is found.

I think I'll start looking into the OpenGL stuff once I get the basics worked out and some kind of specs written.

[Pieter Hulshoff]

Ok, that should not be an issue with MAME and MESS then; when using the software lists the emulator will figure out where to find the correct ROM file. This is particularly handy with all the merged and packed formats out there.

[Pieter Hulshoff]

On Tuesday, October 7, 2014 10:40:48 AM UTC+2, Steve Maddison wrote:

The idea was (IIRC, this is a while ago now) that matching would be done on the "platform" tag. I.e. give both the game and the emulator a platform tag with the same value and it should match the up. Whether it actually works like that is however anyone's guess ;) 

From what I can tell it does not work at the moment. Question is of course if it's worth fixing it in 1.0 or if we just keep it in mind when building 2.0. Personally I think the latter is probably the better option.

[Pieter Hulshoff]

On Tuesday, October 7, 2014 11:05:35 AM UTC+2, Steve Maddison wrote:

On 6 October 2014 15:25, Pieter Hulshoff <phuls...@gmail.com> wrote:

Gentlemen,

I believe we have some decisions to make with regards to features:
I've been very impressed with the HS community results when it comes to art (wheel/systems/etc.). I'd love to work together with them to share as much work as possible, even though we'll define our own set of features.

This is kind of a key thing. We need to allow reuse but not allow ourselves to be limited by other similar projects.

I agree; use when it fits our needs; improve when it does not.
 

1. Do we follow the HS two-step selection of system -> game, do we use a three-step approach of system->genre->game (only automatic XML file generation possible for MAME at the moment; we'd need catver information for the other systems or do it by hand), or do we come up with a new approach (I use one direction for game selection and another for system selection in my latest code)?

I honestly think we should allow all of these options, somehow. There are so many different ways people want to set up their cabs; some just have one list of arcade games, others want different systems/emulators, others want a complete compendium of every video game ever made ;)

True, but we should probably agree on a way to find and select games. Leaving everything programmable will create a huge pile of spaghetti. :) Proposal: system selection; if only one system exists then skip -> genre selection; if only one genre exists then skip -> game selection. Games are checked on availability at startup, and if no games are available in a genre or system, then that selection is not shown either.

 

4. In fact: I'd like that to be the default: only show the games actually on the system. That way all systems can be in the systems.xml file, and the game XML files for all supported system can be present as well. It doesn't take much room, but it makes adding new systems much easier for the user, simply by adding the corresponding ROM and art files.

Sure, we could do this. This would allow people to publish their complete lists and others to reuse them, even if they don't have all the games. I'm not completely sold on it being the default though, it depends on what the user is expecting and you don't want to go silently dropping things if the use thinks they're meant to be there.

We could leave it configurable, but I think the majority of the users would prefer to only have games shown that are actually available for play. That's why I think it should be the default choice in the configuration file.

 

5. I would like these files to be a part of the standard directory structure; not a part of a $HOME/.cabrio directory. This way we can distribute packed directory structures with files (possibly as torrent) to allow users to quickly set up their environment.

If the data is truly authoritative it can go in /usr/share (or wherever) for sure. It should be possible to override/supplement at the user level too though.

What I meant was that the directory structure of Cabrio should be fixed, starting from a user configurable starting point of course. This will make it much easier for users to set up their system, and for us to offer support and downloads.
 

6. Hopefully we can get permission from HS and Emumovies to do the same for their files, but if not I'll write some tools to automate the installation process after users download the files from their servers using membership there. Obviously we'll add our own art/themes to the process. 

It might be tricky to strike the right deals but making it easier to use external resources would indeed be a huge plus.

It would be best if we could work together with them, and help them build one repository for this kind of material, but worst case we can be compatible, and have users download the material themselves. We just need to make it convenient for them to do so.

7. We need to have a look at file detection. I think identification should be based on:
  1. file name
  2. full name
  3. cloneof file name
  4. cloneof full name
  This should cover most naming systems used by the available repositories.

I have a suspicious feeling this is really difficult to do well. I also rather expect someone's had a good crack at it though and we can probably find some open source solution.

I did something similar in my own front-end, so it's really not that difficult. Since I'm volunteering to write the file I/O functions, I'll take care of this problem as well. :)
 

Let me know what you think. I'll post more if thoughts pop up. :) If we agree that the current XML parsing takes up too much time, and we've decided on file formats and class definitions, I could write the file I/O functions. It would save me some time if I don't have to delve into the OPENGL functionality at this time, have one of you handle that, and make myself useful by writing supporting functions and tools. :) If you could send me an email I could send you some intermediate results as soon as they come available.

Cool. I think we need to look at why the list reading stuff is slow right now. It could also be that the XML part is fine but the delay comes from the rather simplistic way the list is built, e.g. it's also sorted just by walking though the whole list until the right spot is found.

It might be worth having a look at to find out what the real cause is. Proper XML parsing would be nice, but if it's really too slow I'll just write something simpler, probably without the validation. Do you see any issue with using the HS XML list format? I can easily reprogram my tool to output that format in stead of the Cabrio 1.0 format, since I'm already storing all that information internally anyway. Just a matter of slightly rewriting the write function.

[Joseph K]

I've added to the subject line to differentiate this thread.

On Tuesday, October 07, 2014 04:54:38 AM Pieter Hulshoff wrote:
> On Tuesday, October 7, 2014 11:05:35 AM UTC+2, Steve Maddison wrote:

> > On 6 October 2014 15:25, Pieter Hulshoff <phuls...@gmail.com <javascript:>

> >
> > > wrote:
> >> Gentlemen,
> >>
> >> I believe we have some decisions to make with regards to features:
> >> I've been very impressed with the HS community results when it comes to
> >> art (wheel/systems/etc.). I'd love to work together with them to share as
> >> much work as possible, even though we'll define our own set of features.
> >
> > This is kind of a key thing. We need to allow reuse but not allow
> > ourselves to be limited by other similar projects.
>
> I agree; use when it fits our needs; improve when it does not.
>

...and use as many hello kitty pictures as possible.. ;-)

> > 1. Do we follow the HS two-step selection of system -> game, do we use a
> >
> >> three-step approach of system->genre->game (only automatic XML file
> >> generation possible for MAME at the moment; we'd need catver information
> >> for the other systems or do it by hand), or do we come up with a new
> >> approach (I use one direction for game selection and another for system
> >> selection in my latest code)?
> >
> > I honestly think we should allow all of these options, somehow. There are
> > so many different ways people want to set up their cabs; some just have
> > one
> > list of arcade games, others want different systems/emulators, others want
> > a complete compendium of every video game ever made ;)
>
> True, but we should probably agree on a way to find and select games.
> Leaving everything programmable will create a huge pile of spaghetti. :)
> Proposal: system selection; if only one system exists then skip -> genre
> selection; if only one genre exists then skip -> game selection. Games are
> checked on availability at startup, and if no games are available in a
> genre or system, then that selection is not shown either.
>

HS allows two "modes" that can be switched on the fly. Default is system->game.
Other is genre->game that is system agnostic.

The user can press a button to skip by a #, skip to next letter of alphabet,
or pull up an alpha select (up/down by char).

Personally, i really like the grid idea instead of a wheel. Think something
like the game grid view in steam. I'd also like some sort of "bread crumb"
display to cue the user where they are. Maybe show small icons up top "SNES >
F".

> > 4. In fact: I'd like that to be the default: only show the games actually
> >
> >> on the system. That way all systems can be in the systems.xml file, and
> >> the
> >> game XML files for all supported system can be present as well. It
> >> doesn't
> >> take much room, but it makes adding new systems much easier for the user,
> >> simply by adding the corresponding ROM and art files.
> >
> > Sure, we could do this. This would allow people to publish their complete
> > lists and others to reuse them, even if they don't have all the games. I'm
> > not completely sold on it being the default though, it depends on what the
> > user is expecting and you don't want to go silently dropping things if the
> > use thinks they're meant to be there.
>
> We could leave it configurable, but I think the majority of the users would
> prefer to only have games shown that are actually available for play.
> That's why I think it should be the default choice in the configuration
> file.
>

Hyperspin uses a clrmamepro format. Game lists can be generated automagically
(in windows native... possibly in wine) and only include what the user has
locally. HS will read the whole thing in and just not execute missing
games/exes. It tries, then fails right back to their GUI, no prompt.

We need to be careful about word choice. To me, afull game list is like MAME's
multi-thousand list... i'd wager most users only actually play a few dozen
games... collections may be one or two hundred max, but we want to handle
arbitrary size without too much overhead. The user should be free to clutter
their HD however they wish with images and movies,, however we should not
allow them to try to play a game that isn't there.

Another thought. I used my arcade to play steam games and windows games in HS.
I had to create a link launching exe (e.g. an "emulator" )to get steam to
work, and threw all relevant links into a specific folder. Its an oddball case,
but what are peoples thoughts on handling direct executables?

> > 5. I would like these files to be a part of the standard directory
> >
> >> structure; not a part of a $HOME/.cabrio directory. This way we can
> >> distribute packed directory structures with files (possibly as torrent)
> >> to
> >> allow users to quickly set up their environment.
> >
> > If the data is truly authoritative it can go in /usr/share (or wherever)
> > for sure. It should be possible to override/supplement at the user level
> > too though.
>
> What I meant was that the directory structure of Cabrio should be fixed,
> starting from a user configurable starting point of course. This will make
> it much easier for users to set up their system, and for us to offer
> support and downloads.
>

HS requires all xmls reside in subfolders from its exe. Lets not do that ;-).
we can use an environment variable instead.

I'm not sure how this works without deep inspection of xml. Personally, i
avoided clones unless they were the english version. I found it annoying to
have a dozen of the same game show up in the list... then remember i wanted
"world, 4-player" not "japan, 2 player"... especially when there was an
arbitrary character limit that might cut that data from being displayed.

> >> Cool. I think we need to look at why the list reading stuff is slow right
> >
> > now. It could also be that the XML part is fine but the delay comes from
> > the rather simplistic way the list is built, e.g. it's also sorted just by
> > walking though the whole list until the right spot is found.
>
> It might be worth having a look at to find out what the real cause is.
> Proper XML parsing would be nice, but if it's really too slow I'll just
> write something simpler, probably without the validation. Do you see any
> issue with using the HS XML list format? I can easily reprogram my tool to
> output that format in stead of the Cabrio 1.0 format, since I'm already
> storing all that information internally anyway. Just a matter of slightly
> rewriting the write function.

A database may be the answer. Its trivial to say "SELECT * FROM snes WHERE
genre LIKE "fighting" LIMIT 50". the only gotcha is we would need to store xml
modification times and be able to update intelligently. we could just blow away
a section "GENESIS" and reimport...

[Steve Maddison]

On 7 October 2014 13:54, Pieter Hulshoff <phuls...@gmail.com> wrote:

 

1. Do we follow the HS two-step selection of system -> game, do we use a three-step approach of system->genre->game (only automatic XML file generation possible for MAME at the moment; we'd need catver information for the other systems or do it by hand), or do we come up with a new approach (I use one direction for game selection and another for system selection in my latest code)?

I honestly think we should allow all of these options, somehow. There are so many different ways people want to set up their cabs; some just have one list of arcade games, others want different systems/emulators, others want a complete compendium of every video game ever made ;)

True, but we should probably agree on a way to find and select games. Leaving everything programmable will create a huge pile of spaghetti. :) Proposal: system selection; if only one system exists then skip -> genre selection; if only one genre exists then skip -> game selection. Games are checked on availability at startup, and if no games are available in a genre or system, then that selection is not shown either.

I think that's a fine starting point but we need to make it easy(-ish) to change/make configurable later. 

4. In fact: I'd like that to be the default: only show the games actually on the system. That way all systems can be in the systems.xml file, and the game XML files for all supported system can be present as well. It doesn't take much room, but it makes adding new systems much easier for the user, simply by adding the corresponding ROM and art files.

Sure, we could do this. This would allow people to publish their complete lists and others to reuse them, even if they don't have all the games. I'm not completely sold on it being the default though, it depends on what the user is expecting and you don't want to go silently dropping things if the use thinks they're meant to be there.

We could leave it configurable, but I think the majority of the users would prefer to only have games shown that are actually available for play. That's why I think it should be the default choice in the configuration file.

I guess I'm coming from the old (existing?) situation where we're defining everything up front. In that case I've put these games in the list, so I want to see them. Looking at it from your standpoint it would be just as reasonable to drop non-existent games. As long is it's easy to determine that a game has been dropped and why, I think it's a fine default in that case.

  

5. I would like these files to be a part of the standard directory structure; not a part of a $HOME/.cabrio directory. This way we can distribute packed directory structures with files (possibly as torrent) to allow users to quickly set up their environment.

If the data is truly authoritative it can go in /usr/share (or wherever) for sure. It should be possible to override/supplement at the user level too though.

What I meant was that the directory structure of Cabrio should be fixed, starting from a user configurable starting point of course. This will make it much easier for users to set up their system, and for us to offer support and downloads.

I think we're on the same page here. The structure would be fixed but it would be possible to override the global config at a user level (both configuration sets having the same structure).

  

6. Hopefully we can get permission from HS and Emumovies to do the same for their files, but if not I'll write some tools to automate the installation process after users download the files from their servers using membership there. Obviously we'll add our own art/themes to the process. 

It might be tricky to strike the right deals but making it easier to use external resources would indeed be a huge plus.

It would be best if we could work together with them, and help them build one repository for this kind of material, but worst case we can be compatible, and have users download the material themselves. We just need to make it convenient for them to do so.

7. We need to have a look at file detection. I think identification should be based on:
  1. file name
  2. full name
  3. cloneof file name
  4. cloneof full name
  This should cover most naming systems used by the available repositories.

I have a suspicious feeling this is really difficult to do well. I also rather expect someone's had a good crack at it though and we can probably find some open source solution.

I did something similar in my own front-end, so it's really not that difficult. Since I'm volunteering to write the file I/O functions, I'll take care of this problem as well. :)

OK, that make you our name matching expert then ;)

  

Let me know what you think. I'll post more if thoughts pop up. :) If we agree that the current XML parsing takes up too much time, and we've decided on file formats and class definitions, I could write the file I/O functions. It would save me some time if I don't have to delve into the OPENGL functionality at this time, have one of you handle that, and make myself useful by writing supporting functions and tools. :) If you could send me an email I could send you some intermediate results as soon as they come available.

Cool. I think we need to look at why the list reading stuff is slow right now. It could also be that the XML part is fine but the delay comes from the rather simplistic way the list is built, e.g. it's also sorted just by walking though the whole list until the right spot is found.

It might be worth having a look at to find out what the real cause is. Proper XML parsing would be nice, but if it's really too slow I'll just write something simpler, probably without the validation. Do you see any issue with using the HS XML list format? I can easily reprogram my tool to output that format in stead of the Cabrio 1.0 format, since I'm already storing all that information internally anyway. Just a matter of slightly rewriting the write function.

I rather suspect we can get away with a standard library for the actual XML and that the performance issue lies elsewhere. No problem generating HS XML format; even if it doesn't become our standard we'll want to be able to support reading them anyway.

[Pieter Hulshoff]

On Tuesday, October 7, 2014 2:30:16 PM UTC+2, Joseph K wrote:

On Tuesday, October 07, 2014 04:54:38 AM Pieter Hulshoff wrote:
> On Tuesday, October 7, 2014 11:05:35 AM UTC+2, Steve Maddison wrote:
> > On 6 October 2014 15:25, Pieter Hulshoff <phuls...@gmail.com <javascript:>

Personally, i really like the grid idea instead of a wheel. Think something
like the game grid view in steam. I'd also like some sort of "bread crumb"
display to cue the user where they are. Maybe show small icons up top "SNES >
F".

I'm familiar with the grid idea, but I don't yet know how I would fit this into a flexible skinning system other than as a specific mode.
 

Hyperspin uses a clrmamepro format. Game lists can be generated automagically
(in windows native... possibly in wine) and only include what the user has
locally.  HS will read the whole thing in and just not execute missing
games/exes. It tries, then fails right back to their GUI, no prompt.

I could add a file check to my list generator; do you see a use for this over simply checking availability at startup? It means that if a user adds a game rom he/she also needs to rerun the program to have it add the game to the game list.
 

We need to be careful about word choice. To me, afull game list is like MAME's
multi-thousand list... i'd wager most users only actually play a few dozen
games... collections may be one or two hundred max, but we want to handle
arbitrary size without too much overhead. The user should be free to clutter
their HD however they wish with images and movies,, however we should not
allow them to try to play a game that isn't there.

That would be my preference as well. I don't really see much advantage to showing games that can't be played anyway, but perhaps some user may want it. Question remains if we should provide it.
I agree that most users will probably not play more than a few dozen or perhaps a few hundreds. I also believe however that many users get a complete game set, while still playing a small section of these games. We should at least be able to handle such large lists.
 

Another thought. I used my arcade to play steam games and windows games in HS.
I had to create a link launching exe (e.g. an "emulator" )to get steam to
work, and threw all relevant links into a specific folder. Its an oddball case,
but what are peoples thoughts on handling direct executables?

I would like to have something like that. I currently have a menu option to launch xbmc from my front-end (my arcade set up boots to the front-end), but a more flexible and generic approach would be better.
 

HS requires all xmls reside in subfolders from its exe. Lets not do that ;-).
we can use an environment variable instead.

I would suggest using .cabrio/config.xml to define such paths.
 

I'm not sure how this works without deep inspection of xml. Personally, i
avoided clones unless they were the english version. I found it annoying to
have a dozen of the same game show up in the list... then remember i wanted
"world, 4-player" not "japan, 2 player"... especially when there was an
arbitrary character limit that might cut that data from being displayed.

Both MAME and MESS already define whether a game is a clone or not. My tool already reads and stores that information; it just doesn't write it out at the moment for Cabrio 1.0. I did however use it in my own front-end to allow the user to configure whether it wanted to display clones or not. Such information could be extended to include number of players, control, etc.
 

A database may be the answer. Its trivial to say "SELECT * FROM snes WHERE
genre LIKE "fighting" LIMIT 50". the only gotcha is we would need to store xml
modification times and be able to update intelligently. we could just blow away
a section "GENESIS" and reimport...

I agree, though I'm not sure we should focus on that for version 2.0. I'd rather have something simpler soon, and work on a database system when we've got 2.0 up and running.

[Pieter Hulshoff]

On Tuesday, October 7, 2014 3:29:12 PM UTC+2, Steve Maddison wrote:

On 7 October 2014 13:54, Pieter Hulshoff <phuls...@gmail.com> wrote:

 

I think that's a fine starting point but we need to make it easy(-ish) to change/make configurable later.

Adding that configuration option from the start should not be an issue; just define a (global) variable, and set it to filter available as a default. Users can overwrite it in the .cabrio/config.xml file.
 

I guess I'm coming from the old (existing?) situation where we're defining everything up front. In that case I've put these games in the list, so I want to see them. Looking at it from your standpoint it would be just as reasonable to drop non-existent games. As long is it's easy to determine that a game has been dropped and why, I think it's a fine default in that case.

Perhaps it would be good to keep a log file in which such information is stored?
 

I rather suspect we can get away with a standard library for the actual XML and that the performance issue lies elsewhere. No problem generating HS XML format; even if it doesn't become our standard we'll want to be able to support reading them anyway.

I'll work with the HS XML format as a base then. I'll also have a look at the current Cabrio loading routines to see if I can figure out what's slowing it down. If it's a structural issue we can solve it. If it's an XML validation issue, I'll write my own functions in stead. I used to read in about 30k games per second, though that was as a compact format rather than an XML format. I'll have to run some small tests to see what works best.

[Steve Maddison]

On 7 October 2014 14:30, Joseph K <jcko...@cs.unm.edu> wrote:

Personally, i really like the grid idea instead of a wheel. Think something
like the game grid view in steam. I'd also like some sort of "bread crumb"
display to cue the user where they are. Maybe show small icons up top "SNES >
F".

Nice... there would have to be some kind of distinction between skins/themes that are simply images/ layout and that which actually use code. And I suppose we'd need to think about how the former would map to various forms of the latter.

A database may be the answer. Its trivial to say "SELECT * FROM snes WHERE
genre LIKE "fighting" LIMIT 50". the only gotcha is we would need to store xml
modification times and be able to update intelligently. we could just blow away
a section "GENESIS" and reimport...

Indeed, using the database like this is essentially a cache and needs to cater for updates properly, tracking files by name, timestamp, maybe some hash like MD5.

[Steve Maddison]

On 7 October 2014 16:20, Pieter Hulshoff <phuls...@gmail.com> wrote:

On Tuesday, October 7, 2014 3:29:12 PM UTC+2, Steve Maddison wrote:

On 7 October 2014 13:54, Pieter Hulshoff <phuls...@gmail.com> wrote:

 

I think that's a fine starting point but we need to make it easy(-ish) to change/make configurable later.

Adding that configuration option from the start should not be an issue; just define a (global) variable, and set it to filter available as a default. Users can overwrite it in the .cabrio/config.xml file.

Yeah, definitely do that, I'm thinking more about the selection sequence, i.e. system -> genre -> game or some other scheme.

 

I guess I'm coming from the old (existing?) situation where we're defining everything up front. In that case I've put these games in the list, so I want to see them. Looking at it from your standpoint it would be just as reasonable to drop non-existent games. As long is it's easy to determine that a game has been dropped and why, I think it's a fine default in that case.

Perhaps it would be good to keep a log file in which such information is stored?

Sure, logging is vital, maybe even a config option to allow messages of a certain severity to be echoed on the GUI. 

I rather suspect we can get away with a standard library for the actual XML and that the performance issue lies elsewhere. No problem generating HS XML format; even if it doesn't become our standard we'll want to be able to support reading them anyway.

I'll work with the HS XML format as a base then. I'll also have a look at the current Cabrio loading routines to see if I can figure out what's slowing it down. If it's a structural issue we can solve it. If it's an XML validation issue, I'll write my own functions in stead. I used to read in about 30k games per second, though that was as a compact format rather than an XML format. I'll have to run some small tests to see what works best.

Sounds like a plan. XML is always going to come as some cost. I'm pretty sure most parsers want to validate the whole document before doing anything, which adds a lot of overhead before any real work can be done. We don't particularly need that so maybe we can shave some time off there by disabling this behaviour or indeed writing a custom parser.

[Pieter Hulshoff]

On Tuesday, October 7, 2014 4:45:10 PM UTC+2, Steve Maddison wrote:

On 7 October 2014 14:30, Joseph K <jcko...@cs.unm.edu> wrote:

Nice... there would have to be some kind of distinction between skins/themes that are simply images/ layout and that which actually use code. And I suppose we'd need to think about how the former would map to various forms of the latter.

I believe HS uses flash and shockwave for that. We'll have to take a good look at how we'd like to support more dynamic themes. Not something I'd like to worry about for the first release.
 

Indeed, using the database like this is essentially a cache and needs to cater for updates properly, tracking files by name, timestamp, maybe some hash like MD5.

Using a standard database is probably a lot better than anything we can come up with. Also something I'd like to have a look at after we finish 2.0. Of course 2.0 will need to be built flexible enough to allow such features to be added easily at a later time.

[sergio-br2]

Just one question, do you think in bezel artwork support? I mean, together with the snap or video.

sergio-br2


Em domingo, 31 de agosto de 2014 16h26min17s UTC-3, Steve Maddison escreveu:

Hi all,

Before anyone gets too excited: no, there is no 2.0 version yet, nor is there even a 1.0 for that matter ;-) I am however thinking about tackling some of the niggly things in Cabrio and whether these would be best retro-fitted to the existing code or part of a complete rewrite.

One thing I'd like to do is to get away from the old OpenGL 1.x code and on to something that will work on OpenGL ES devices as well as the desktop. The pain of doing so may be somewhat mitigated by using an existing 3D engine which abstracts the differences away. I've been looking at Irrlicht and am now playing with OGRE, both of which are C++ based and would probably suggest more of a rewrite than an update.

This brings me to another point, which is whether to stick with C of move to C++ (which seems to be the norm for 3D engines) or even something completely different like Python or Go.

Back on the topic of abstraction, some kind of wrapper around the ever-changing ffmpeg libraries would be great, but I've not found anything like this as yet.

Some other spitballs:

 * Whether to keep the XML configuration files or dump them for something else.

 * Possibly using an SQL database for game lists, etc.

 * Configuration from within the GUI (optional, protected by password/PIN).

 * Custom events/actions for games.

 * Redoing themes properly, with absolute offsets for everything.

 * Building with autoconf (Psychomantis had a crack at this but I never managed to get it working).

 * Arbitrary number of images per game (box, cabinet, control panel, etc.)

 * Game ratings (0-5 stars or similar).

 * Displaying misc. game info text (synopsis, review stars, etc).

 * Attract mode (randomly flip though games at idle).

 * Background pan and zoom.

As fellow developers I'd like to hear your opinions on this stuff, especially the technical decisions if you have experience building 3D apps for multiple platforms.

Cheers,

Steve

[Pieter Hulshoff]

As so often, life got in the way of progress, and I haven't spent much time on Cabrio 2 in the past weeks. Are any of you making progress at the moment?

I just received an offer from the HS team to get an API key that would allow us to hook directly into the HS repositories. Of course a user would need a platinum account to make use of it, but it would allow us to directly manage all HS artwork from Cabrio 2 or an accompanying configuration tool. Now I wouldn't put this on the top of our development list, but it sounds like it could be interesting to keep in mind. Would you agree?

[Joseph K]

With assorted holiday madness I haven't been treating into development that much either. Lots of family stuff on top of broken hand. Cast comes of today though, so hopefully I'll be capable of typing soon.

Regarding the HS media, that sounds like a good opportunity to work with them. I don't know how many users would really make use of it, but it is definitely a neat concept. I would lean toward a separate management tool, let's keep the frontend focused on efficiency... not a monolithic arcade panacea.

Regards,
Joseph

[Pieter Hulshoff]

Steve/Joseph,

What's our planning? I'm still considering a menu rewrite to work from a database structure, and allow on the fly menu creation based on certain sorting criteria as opposed to a fixed menu structure. Both have their advantages and disadvantages. Any preference on your side?

By when do you believe you could have something up and running? I would like to integrate the menu structure and menu/game selection into the code, so I'm wondering when you expect a first skinned gui to be up and running. Steve? What are your programming plans for the upcoming months? Joseph, I presume yours are tied to your recovery?

Kind regards,

Pieter Hulshoff

[jcko...@cs.unm.edu]

Pieter/Steve,
Apologies for not being as active these past few weeks. Along with only
having one hand, I've had my daughter and of course all the holiday
madness with family that comes with it. I hope to devote a couple
evenings a week (est 2-3 hour blocks, maybe longer) to get something
going.
Last week I got my cast off and pins out, so a good deal of focus has
been on getting my hand flexibility back. My typing speed is a bit
slower than it was, and I have to take more frequent breaks, but I am
getting better.

My next plan for the code is to integrate your structures into the
rendering and display code (class names elude me right now, I'm at
work). My intent is to minimize redundancy by having the user interface
code peer into the GameList and related classes. I'm trying to make it
so my code "doesn't care" about the underlying structure, as long as
there is a concept of "next" and "previous".

To answer your question, I think a database approach would be robust and
potentially very fast. It is much simpler to say "SELECT * WHERE
type='ACTION'" than it is to store a 10K+ list and sort things yourself.
The question then becomes "How do we make it easy for the user to
populate it?". I think the answer there is another application that
reads XML or pulls directly from given directories. I think this could
even start out as a Perl script... as long as we had a well documented
means for the user to provide input. We just need a top-level XML or
folder that informs the rest of the tree, and thus the DB tables.

Then of course there is licensing. We obviously wouldn't want MS SQL
Server or OracleDB... and MySQL or PGSQL could be overkill, but still
usable. It'll have to be abundantly clear which we are using. We'll also
likely have to have some auto-install and auto-run in place. Doable, but
I haven't actually done it before.


Regards,
Joseph

[Pieter Hulshoff]

Joseph,

Good to hear you're up and about again; hopefully you'll be up to speed again in no-time. :)

There's quite a few people at HS interested in our plans, and willing to work together on this one, so I'm having some discussions there to get things up and running. One of the highest on the wish list there is to have HD support, which I think shouldn't be much of a problem. Several artists would love to create HD art for a new front-end, though Windows and HyperLaunch support would be appreciated. I'll have a closer look at either loading (and converting internally) and/or converting externally the HS themes to make all our lives easier. I'm not an artist, so I'd rather leave theming to people who know what they're doing. :)

I'm not yet planning on using a real database system for now; just a simple internally generated version of it. If I set it up correctly, it could always be replaced with a real database system later. At the moment, I'm considering building both: an XML based menu structure which also fills the database, and which can be replaced by an internally generated menu structure as well (though that may have to wait for a later release; let's first get something simple working).

In the mean time: do we want to spend any time on improving Cabrio 1.0? It could probably do with a few (simple?) updates to fix some user problems (like the large list problem). Alternatively we need to get this project off the ground. :)

Steve? What's your situation at the moment? Do you foresee having any time available for this in the near future?

[Pieter Hulshoff]

Are you familiar with RetroFE? Should we contact its developer to check if he wishes to reconsider making his code F/OSS, and work together?

[Steve Maddison]

On 16 December 2014 at 11:12, Pieter Hulshoff <phuls...@gmail.com> wrote:

There's quite a few people at HS interested in our plans, and willing to work together on this one, so I'm having some discussions there to get things up and running. One of the highest on the wish list there is to have HD support, which I think shouldn't be much of a problem. Several artists would love to create HD art for a new front-end, though Windows and HyperLaunch support would be appreciated. I'll have a closer look at either loading (and converting internally) and/or converting externally the HS themes to make all our lives easier. I'm not an artist, so I'd rather leave theming to people who know what they're doing. :)

Nice, and indeed no problem at all. As long as your machine's quick enough even Cabrio 1.0 could do HD, given the right image resources. Conversion, whether real-time or with some kind of import tools, all sounds very cool indeed.

When working on my own configuration a lot of the available images were really low resolution, so I ended up tracing a fair number to make SVGs out of them. This is ideal as you can of course poop out bitmaps at whatever resolution you like. I'd really encourage this approach and making the source images freely available, then they can be used in practically any front end.

 

I'm not yet planning on using a real database system for now; just a simple internally generated version of it. If I set it up correctly, it could always be replaced with a real database system later. At the moment, I'm considering building both: an XML based menu structure which also fills the database, and which can be replaced by an internally generated menu structure as well (though that may have to wait for a later release; let's first get something simple working).

Sure, database vs. vectors vs. linked lists isn't really important right now. We do need to be careful about what exactly the "menu" and "game list" constitute. The main problem with integrating all the code right now is that these two concepts are intertwined in different ways. Feel free to shoot at it, but my interpretation is as follows:

  * Game list is just something containing all the games individually, with their names, platforms, genres, etc. It may well be a list of all possible games on all possible platforms, it may even be populated from different sources. The game list however knows nothing about the menu structure.

  * The menu is how you navigate through your list. This has a (configurable) structure so you can start out on platform, drilling down to genre, or the other way around, or something completely different. The menu however doesn't actually contain any games; it queries the game list to generate the selection of games that currently matches the user's selection.

  * All the theme/layout business sits on top of all of this and instructs the renderer to put images in particular places on the screen.

 

In the mean time: do we want to spend any time on improving Cabrio 1.0? It could probably do with a few (simple?) updates to fix some user problems (like the large list problem). Alternatively we need to get this project off the ground. :)

As far as I'm concerned Cabrio 1.0 is still a "live" project, even if it's very, very inactive. If anyone wants to work on it: by all means! There are already some nice forks out there with more features. I'm also happy to receive pull requests, although as I don't have time to review/build/test huge changes, any pull requests back to the "official" repo really need to be small(-ish), easily manageable and in themselves complete.

Steve? What's your situation at the moment? Do you foresee having any time available for this in the near future?

I hope to at least have a good look at things over the holidays and get back to coding again in the new year.

Cheers,

Steve

[Steve Maddison]

On 21 December 2014 at 14:04, Pieter Hulshoff <phuls...@gmail.com> wrote:

Are you familiar with RetroFE? Should we contact its developer to check if he wishes to reconsider making his code F/OSS, and work together?

I'd never heard of it until now, looks pretty swish. Can't hurt to reach out to the developer(s), even if only to let them know what we're up to - would you like to do that?

[Pieter Hulshoff]

Consider it done. :) I'll try a few ways of contacting him to see if he'd be interested in working together.

[Pieter Hulshoff]

On Mon, Dec 22, 2014 at 5:51 PM, Steve Maddison <st...@cosam.org> wrote:

Nice, and indeed no problem at all. As long as your machine's quick enough even Cabrio 1.0 could do HD, given the right image resources. Conversion, whether real-time or with some kind of import tools, all sounds very cool indeed.

I've got a working HS setup on my Windows partition now to work from, so I'll see how far I can get with that. I did notice we'll be needing .zip support for it though.

 

  * Game list is just something containing all the games individually, with their names, platforms, genres, etc. It may well be a list of all possible games on all possible platforms, it may even be populated from different sources. The game list however knows nothing about the menu structure.

  * The menu is how you navigate through your list. This has a (configurable) structure so you can start out on platform, drilling down to genre, or the other way around, or something completely different. The menu however doesn't actually contain any games; it queries the game list to generate the selection of games that currently matches the user's selection.

I integrated these two, since some users (including myself) would like full control over what their menu structure looks like. I also plan on adding the type of menu support you're describing here; I've pretty much got it worked out in my head, so I'll get to programming it soon.

 

  * All the theme/layout business sits on top of all of this and instructs the renderer to put images in particular places on the screen.

That should indeed be separate, and possibly programmable per system or even per game like HS allows. If a game theme doesn't exist, it reverts to the system theme, and if that doesn't exist it uses the overall theme.

 

As far as I'm concerned Cabrio 1.0 is still a "live" project, even if it's very, very inactive. If anyone wants to work on it: by all means! There are already some nice forks out there with more features. I'm also happy to receive pull requests, although as I don't have time to review/build/test huge changes, any pull requests back to the "official" repo really need to be small(-ish), easily manageable and in themselves complete.

I may have a look at it then. Cabrio 1.0 still suffers from problems with large lists, which makes it hard to work with for any larger emulation setup.
 

I hope to at least have a good look at things over the holidays and get back to coding again in the new year.

That's good to hear. :) Let's get this thing on the road then! I'll update my menu code soon so you or Joseph can work it into the general code. It already provides menu manipulation, like enter/exit submenu, game filters, etc. If there's anything missing, please let me know, and I'll add it.

Kind regards,

Pieter

[Steve Maddison]

On 12 December 2014 at 16:10, <jcko...@cs.unm.edu> wrote:

Pieter/Steve,
  Apologies for not being as active these past few weeks. Along with only
having one hand, I've had my daughter and of course all the holiday
madness with family that comes with it. I hope to devote a couple
evenings a week (est 2-3 hour blocks, maybe longer) to get something
going.
  Last week I got my cast off and pins out, so a good deal of focus has
been on getting my hand flexibility back. My typing speed is a bit
slower than it was, and I have to take more frequent breaks, but I am
getting better.

No worries, glad to hear you're on the mend ;) 

 

  My next plan for the code is to integrate your structures into the
rendering and display code (class names elude me right now, I'm at
work). My intent is to minimize redundancy by having the user interface
code peer into the GameList and related classes. I'm trying to make it
so my code "doesn't care" about the underlying structure, as long as
there is a concept of "next" and "previous".

Sounds great!

 

  To answer your question, I think a database approach would be robust and
potentially very fast. It is much simpler to say "SELECT * WHERE
type='ACTION'" than it is to store a 10K+ list and sort things yourself.

Yep, I think it'll solve a lot of potential performance issues when it comes to reading and filtering.

 

The question then becomes "How do we make it easy for the user to
populate it?". I think the answer there is another application that
reads XML or pulls directly from given directories. I think this could
even start out as a Perl script... as long as we had a well documented
means for the user to provide input. We just need a top-level XML or
folder that informs the rest of the tree, and thus the DB tables.

What I'm thinking of is using the database as a kind of cache. You can still list all your games, config, etc. in XML files but instead of populating some in-memory list, you write to the database. You could potentially throw the database away at start-up and repopulate from XML. To start with it could well be done with an external tool, later on it could be integrated and do smart stuff like checking if any XML files have changed and only reloading those files.

  Then of course there is licensing. We obviously wouldn't want MS SQL
Server or OracleDB... and MySQL or PGSQL could be overkill, but still
usable. It'll have to be abundantly clear which we are using. We'll also
likely have to have some auto-install and auto-run in place. Doable, but
I haven't actually done it before.

MySQL and Postrges would be good candidates, especially for more advanced setups. In a lot of cases we'll probably get away with using sqlite, which is a lot simpler as you don't even need a server process running. I think the logical order would be to get it working with basic data structures like a vector and basically brute-force filtering. After that sqllite, then some abstract database stuff that can talk to servers like MySQL, etc.

Cheers,

Steve

[Pieter Hulshoff]

Are you familiar with http://www.hyperspin-fe.com/forum/showthread.php?t=31916 ?
Is that something we may want to add to Cabrio 2?

[Pieter Hulshoff]

Gentlemen,

What's your status? Are there any updates on your side for Cabrio 2? What are your plans for the near future?

[Joseph K]

Pieter,
Apologies for being a ghost lately. My focus has been on a job hunt and now getting ready to move to another city. With most of my toys packed up, I hope to make more productive use of free time. Though it may be a couple weeks before the dust settles for me.

My next step is still to grab your code and get to integrating. Unless of course someone beat me to it.

Regards,
Joseph

On January 28, 2015 5:54:59 AM MST, Pieter Hulshoff <phuls...@gmail.com> wrote:

Gentlemen,

What's your status? Are there any updates on your side for Cabrio 2? What are your plans for the near future?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Steve Maddison]

Hi chaps,

Not a lot to report this end, still tinkering with the OpenGL stuff and hopefully get textures working soon.

Cheers,

Steve

--

[Pieter Hulshoff]

I'm working on a redo of my menu code, and integrate the selection and criteria based generation while I'm at it. That should suffice for now.

[Pieter Hulshoff]

With suffice I mean that it should contain all the features we will need for Cabrio 2, and will allow us to see if a true database system is required or not. I also plan on analysing the RetroFE code to see what I can learn from it, and see if there's grounds for shared development. I may start an intermediate Cabrio version (combining my menu code with the Cabrio 1 OpenGL/theme structure) to get things tested and rolling while you two work out the new OpenGL/theme structure. Any thoughts on when you'll be having something ready to work with for Cabrio 2?

[Pieter Hulshoff]

Gentlemen,

Other than 3D support, what is RetroFE currently missing that we want to have in Cabrio 2? The Code Base (please check it out) seems very solid, and well designed, and Don's already well known for his tools in the emulation scene. Should we consider using his code base or even join the RetroFE project or do we wish to design our own code base? I guess that comes down to the first question:is it missing something we vitally want in our new frontend?

[Fred B]

I don't know RetroFe very much, but his design seems more poor to me, no ? RetroFe
Cabrio-fe can do some very nice thing.

But maybe I'm wrong, I should make some tests 

[Pieter Hulshoff]

That Cabrio theme looks very similar to the behaviour shown later in that RetroFE video actually. All in all it's just a theming thing though; theme preferences differ. I'm mostly interested in the code base; is it usable for what we want or not?

[Pieter Hulshoff]

I had a closer look, and the front-end is highly flexible, though as a result also a bit hard to set up properly (though I've been assured that's being tackled). It already supports a large amount of object animations, as well as animations to switch from one game to the next, one menu to the next, etc. I'm still not sure whether it would be a good base to add to, start from or be inspired by though. There's a few aspects I would have preferred to've been designed differently, though it did point me to some flaws in the ideas I had. For example:

We currently plan to support different skins for different menus, e.g. a SNES menu may look very different from a MAME menu. We also wish to support dynamic menu structures from a database using a SELECT type option. Question is: which skin should be used for such a purpose? If I for instance select all driving games, what will that menu look like? Will it require a new skin file (to be named appropriately) or will it use the skin depending on the currently selected game (I doubt that would look good; all that skin switching within one menu) or ... ?

[Pieter Hulshoff]

Have a look at http://www.retrofe.com/documentation/Layouts.html to get an idea of the theming features available.

[Fred B]

Le mercredi 18 février 2015 10:04:25 UTC+1, Pieter Hulshoff a écrit :

Have a look at http://www.retrofe.com/documentation/Layouts.html to get an idea of the theming features available.

Ok I will, seems very impressive

Thanks Pieter