Minimum Viable Product (2.0)

[Steve Maddison]

I'd like to sketch out the features required to build a base that can be worked upon simultaneously by a team of developers. It might even be possible to split up the load of building this MVP.

1. Basic interface events/controls

  a. define actions for up/down/left/right, select, back, exit

  b. main loop (using SDL?)

2. Basic graphical theme (need not yet be hierarchical)

  a. Pluggable graphics back-end.

  b. OpenGL implementation for image primitives.

3. Game list (in memory)

  a. Reading in XML list, paths to all resources explicitly defined.

I'm not sure there's a lot more that's really mandatory and can't be added later.

As usually, comments and additions welcome!

Cheers,

Steve

[Pieter Hulshoff]

Would you prefer to work with global variables or would you rather pass the variables as function parameters? I found global variables to be rather helpful when I was programming, but I'd leave the decision up to you.
I'd be willing to volunteer myself for step 3: reading of the game list and other XML files.
Should we read all XML files for all systems at start up (also so we can check which systems/games are available) or should we load them whenever a user selects them (and perhaps then find out there's nothing in there)?

[Joseph K]

On Tuesday, October 07, 2014 09:50:45 PM Steve Maddison wrote:
> I'd like to sketch out the features required to build a base that can be
> worked upon simultaneously by a team of developers. It might even be
> possible to split up the load of building this MVP.
>

My development with Ogre3D is heavily based on this:
http://www.ogre3d.org/tikiwiki/Advanced%20Ogre%20Framework

I think it has great utility for the overall design of the code. Graphical
work is its own singleton class, so is user input. GameStates are generic way
to add levels, though we can use them for "intro", "SystemSelect",
"GameSelect", and "GenreSelect". Each state has three functions that are
called by the state manager:
Enter: called when loading the state, here is where we load relevant data and
can do transitional animation. I say we fade for now. Note the call to the
graphics->draw function (or equivalent)
Execute: The actual meat of it. capture user input and update accordingly.
Exit: Cleanup as we leave a state.

I think we should have a "config" singleton that houses variables for reference
elsewhere. We can maintain a call like:
config->GetImagePath("genesis")

or something like it.

We can even enforce a "splash" state that does some animation while things are
read in that happens before "sysemselect". Note that all the states inherit
from gamestate.

> 1. Basic interface events/controls
> a. define actions for up/down/left/right, select, back, exit
> b. main loop (using SDL?)

Handled by a user interface class (group of functions)

> 2. Basic graphical theme (need not yet be hierarchical)
> a. Pluggable graphics back-end.
> b. OpenGL implementation for image primitives.

Handled with a UI class. we define some API and can switch out SDL for Ogre, or
DirectX, or whatever we need. This means all system/opengl calls are localized
somewhere.

> 3. Game list (in memory)
> a. Reading in XML list, paths to all resources explicitly defined.
>

Partially handled by enter/exit. We can make it a little smarter in execute,
too.


I realize this is heavily C++. I have found in my tinkering with game engines
they all behave similarly. This approach is easily expandable and really easy
to maintain. It also clearly divides the work.

-Joseph

[Pieter Hulshoff]

On a more basic level: do we wish to use (double) linked lists, vector or deque for our lists?

[Steve Maddison]

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

Would you prefer to work with global variables or would you rather pass the variables as function parameters? I found global variables to be rather helpful when I was programming, but I'd leave the decision up to you.

Hopefully we wouldn't need much to be global in a fully OO implementation, probably singletons for important things like the config, renderer, etc.

 

I'd be willing to volunteer myself for step 3: reading of the game list and other XML files.

Cool, I guess the next step is to define some classes to put all this data into.

 

Should we read all XML files for all systems at start up (also so we can check which systems/games are available) or should we load them whenever a user selects them (and perhaps then find out there's nothing in there)?

Whatever's simplest to start with, I guess just read everything into memory.

[Steve Maddison]

I'll go through it properly later but even from a quick scan this looks like a nice, tried-and-tested concept and everything we need fits very nicely. Even better, it makes it easy to swap things out for better/extra alternatives as things progress.

[Steve Maddison]

On 8 October 2014 08:34, Pieter Hulshoff <phuls...@gmail.com> wrote:

On a more basic level: do we wish to use (double) linked lists, vector or deque for our lists?

A deque is the first thing that comes to mind. What's best practise though? I suppose to isolate things properly you'd have first/last/next/previous methods in your list class and you'd be free to use any data structure you like.

[Pieter Hulshoff]

From what I could find, vectors will reduce cache misses during linear search since all memory is allocated contigously, and we generally search down through the list.Once lists are created, we generally don't need to inject or delete objects very often, which reduces the advantages of deque over vector. In all honesty: I haven't used either that much, since I've had more experience programming in C than in C++, but I think we can use them to our advantage. Joseph, care to give us your 2 cents?

[Pieter Hulshoff]

Btw, when it comes to classes: what are your views on public fields vs private fields with public functions? I've noticed in the past that the second option left me with a lot of code that really wasn't very helpful (mostly a lot of set and get functions to use in stead of direct field assignment using the "." separator. I understand the principle behind using private fields, but I haven't found much advantage to it in front-end development yet.

[Steve Maddison]

On 8 October 2014 14:36, Pieter Hulshoff <phuls...@gmail.com> wrote:

Btw, when it comes to classes: what are your views on public fields vs private fields with public functions? I've noticed in the past that the second option left me with a lot of code that really wasn't very helpful (mostly a lot of set and get functions to use in stead of direct field assignment using the "." separator. I understand the principle behind using private fields, but I haven't found much advantage to it in front-end development yet.

It's a bit of a case-by-case thing but separate set/get methods generally make it easier to change things later down the line without having to fiddle with a class's interface. For this reason we'll probably want to use this approach in most cases to be able to stay agile enough to implement big changes (like swapping out database backends, for example).

[Joseph C Koprivnikar]

Both answers in one! (in the name of efficiency, or laziness since I broke my left hand on monday...) I've added some explanation for those that lean toward C.

more info at www.cplusplus.com

 

On Wed, 8 Oct 2014 05:36:28 -0700 (PDT), Pieter Hulshoff wrote

> Btw, when it comes to classes: what are your views on public fields vs private fields with public functions? I've noticed in the past that the second option left me with a lot of code that really wasn't very helpful (mostly a lot of set and get functions to use in stead of direct field assignment using the "." separator. I understand the principle behind using private fields, but I haven't found much advantage to it in front-end development yet.
>

First, in C++ the only difference between structs and classes is that structs by default have publicly accessible variables. Classes, by default, are private. In practice, structs are used as data containers, classes are used for encapsulation and built-in functions. I would use a struct for a 2D Point for ease of pt.x and pt.y. I would use a class for a vector, to overload functions like Multiply, Add, Subtract, etc...

The way I was taught was to think about Get/Set vs. public access is to think more about 'who' really needs access and whether you want input validation. While you could make some screen layout widget a struct and give direct access to coordinates, having a "set" function will allow you to ensure the value is within bounds, or truncate/handle accordingly.

Basically, its an API approach along the lines of forcing the class to handle itself (encapsulation). If I am the control class and you are the UI, I should tell you the user pressed the down arrow, not muck around in your internal variables. For small programs this is pretty immaterial. However, looking forward we may have SteveAndPietersSuperFancyXMLClass, which we pull out into a library that can be reused by other projects.

> From what I could find, vectors will reduce cache misses during linear search since all memory is allocated contigously, and we generally search down through the list.Once lists are created, we generally don't need to inject or delete objects very often, which reduces the advantages of deque over vector. In all honesty: I haven't used either that much, since I've had more experience programming in C than in C++, but I think we can use them to our advantage. Joseph, care to give us your 2 cents?

>

Now we are getting into the low-level stuff. A vector is more or less an array with some extra sugar. Yes, primary storage is contiguous, but can be set to a specific size. By default, vector will allocate an array of size "N" (i'm sure its somewhere in vector.h). Once the needed storage gets larger than "N", a vector will allocate a larger block and, as of C++11 if memory serves, move stuff over (or copy if necessary). Reading/writing are cheap,,, but insertions/deletions are expensive since to insert between to existing things (or remove a chunk) may force a new copy to happen. Is being able to say "Item[7]" really more valuable than clearing/repopulating the vector for some subset of the overall list?

Lists are not contiguous, and have the overhead of pointers at each "node". Doubly linked lists have two pointers and allow for bidirectional search. However, searching for entry "X" is expensive because you have to start at the head pointer and count. Finding a subset to display can be done, but it might be a little slow and computationally expensive. Iterators improve this a bit... We can keep "currentSelection" and go forward/back a few as needed.

A queue/deque is a first-in-first-out (FIFO) container. Best used when you only care to visit something oncem then throw it away. Think about entering grades into a gradebook. You have a stack of papers from one student. You "dequeue" or "pop" the top, process it, then toss it aside (free or delete). A dequeue does that from both sides.

For our purposes the most important thing is to eliminate redundancy and maintain usability. I think a combination would probably be the best. I would use a deque or circular linked list for pulling/displaying games/systems. I would use an array or vector to grab a set size then could loop and push_front, or push_back to populate the deque... while "pop"ing from the opposite side. We also maintain an iterator at the "middle" which would be the current selection. Then all that remains is finding a way to say "give me the previous 50" on the list, which may circle from a to z.

Clear as mud?

-Joseph

[Pieter Hulshoff]

You propose an interesting solution here. Originally I was considering setting up a fixed structure for all gaming lists as defined by the files, but it could just as easily be created as a simple internal database system where the required list is generated on the spot by searching the database. All the gaming lists do then is define the required parameters needed to construct the list at a later time. I'll have to give that some more thought; it would make it much easier to switch to a real database system later, which in turn could be used to create all sorts of flexibility. It does make programming the base system more complex though.

[Pieter Hulshoff]

I've started my XML experiments by writing a game file parser (fileio.cpp; do we want to use .cpp or .c for our file extensions?) using xmllib2. Using xmllib++ proved too much hassle, so I'll just convert to std::string whenever I need to, and use C++ wherever appropriate. I'll need classes for games and game lists though; who will be writing those? I could write something for now that can be either temporary until replaced or updated/reused later; it's up to you.

I'll use this experiment to see if xmllib works fast enough to use for this purpose or if I have to rewrite the functions using something less validating. :)

[Steve Maddison]

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

I've started my XML experiments by writing a game file parser (fileio.cpp; do we want to use .cpp or .c for our file extensions?) using xmllib2.

Cool. Definitely .cpp extension and .hpp for headers. You never know when we might need to mix in a bit of straight C. While we're at it: quick show of hands on naming conventions? I'm used to using CamelCase for class names in C++ and naming the files in the same way.

 

Using xmllib++ proved too much hassle, so I'll just convert to std::string whenever I need to, and use C++ wherever appropriate. I'll need classes for games and game lists though; who will be writing those? I could write something for now that can be either temporary until replaced or updated/reused later; it's up to you.

Feel free to write any classes you need to get going. Also, the sooner we can start integrating things the better. If you're able to work on a branch of the GitHub repo, that's ideal as it makes merging a lot easier down the line.

 

I'll use this experiment to see if xmllib works fast enough to use for this purpose or if I have to rewrite the functions using something less validating. :)

Nice. I also came across this, no idea if it fits the bill: http://vtd-xml.sourceforge.net

[Joseph K]

On 10/9/2014 9:06 AM, Steve Maddison wrote:

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

I've started my XML experiments by writing a game file parser (fileio.cpp; do we want to use .cpp or .c for our file extensions?) using xmllib2.

Cool. Definitely .cpp extension and .hpp for headers. You never know when we might need to mix in a bit of straight C. While we're at it: quick show of hands on naming conventions? I'm used to using CamelCase for class names in C++ and naming the files in the same way.

C++ classnames: CamelCase
member variables: <type>_lowerThenCamel (e.g. i_myInteger, p_myPointer)
functions: CamelCase

.cpp and .hpp definitely. Some compilers get confused based on file extensions (Visual C++ treats .c as C, gcc will do the same. cpp will trigger C++ compiles)

 

Using xmllib++ proved too much hassle, so I'll just convert to std::string whenever I need to, and use C++ wherever appropriate. I'll need classes for games and game lists though; who will be writing those? I could write something for now that can be either temporary until replaced or updated/reused later; it's up to you.

Feel free to write any classes you need to get going. Also, the sooner we can start integrating things the better. If you're able to work on a branch of the GitHub repo, that's ideal as it makes merging a lot easier down the line.

 

Part of my.. upbringing... with version control is to never commit something that is broken. I may break that rule as i tear into the deque stuff. I hope to work on that a bit today.

I'll use this experiment to see if xmllib works fast enough to use for this purpose or if I have to rewrite the functions using something less validating. :)

Nice. I also came across this, no idea if it fits the bill: http://vtd-xml.sourceforge.net

There is also a couple xml libraries in the ubuntu repositories. xerces is pretty common.

-Joseph

[Steve Maddison]

On 9 October 2014 17:22, Joseph K <jcko...@cs.unm.edu> wrote:

On 10/9/2014 9:06 AM, Steve Maddison wrote:

Cool. Definitely .cpp extension and .hpp for headers. You never know when we might need to mix in a bit of straight C. While we're at it: quick show of hands on naming conventions? I'm used to using CamelCase for class names in C++ and naming the files in the same way.

C++ classnames: CamelCase
member variables: <type>_lowerThenCamel (e.g. i_myInteger, p_myPointer)
functions: CamelCase

.cpp and .hpp definitely. Some compilers get confused based on file extensions (Visual C++ treats .c as C, gcc will do the same. cpp will trigger C++ compiles)

I'll see if I can find some suitable and well-documented style guide online which we can refer to - open to suggestions though if anyone knows of a good one. Everyone will hate something about any chosen convention, so that kind of makes it fair in the end ;-)

[Joseph K]

Just a thought:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html
http://smacked.org/docs/cpp_style_google.pdf

...different than I'm used to, but well codified.

--
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]

It looks interesting, but I couldn't find a repository for it, and it errored out during compilation.

I made a quick and dirty XML parser using xmllib, and ran it 100x over the entire MAME lis (30551 gamesx100): it took 32s, so about 95k games/second. That's faster than my own XML parsing code, so certainly acceptable from that point of view. Is this performance sufficient or do we (I) need to take a look at alternative parsers?

[Steve Maddison]

On 9 October 2014 18:19, Joseph K <jcko...@cs.unm.edu> wrote:

On 10/9/2014 9:56 AM, Steve Maddison wrote:

I'll see if I can find some suitable and well-documented style guide online which we can refer to - open to suggestions though if anyone knows of a good one. Everyone will hate something about any chosen convention, so that kind of makes it fair in the end ;-)

Just a thought:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html
http://smacked.org/docs/cpp_style_google.pdf

...different than I'm used to, but well codified.

I came across the exact same thing. Different indeed, but well thought out and justified. Let's adopt this for now and see how it goes in practise.

 

[Steve Maddison]

95K/second sounds pretty quick to me and using an existing library will drastically reduce the amount of code required. Id' leave it at that for now.

This does suggest that the current performance issues are just down to processing the data, which I sort of expected. Is the list sorted already? I think that might be one of the performance killers in the current code.

[Pieter Hulshoff]

The list is currently already sorted when written out by my tool, but I used to do sorting on the fly in my old MAMEd code (switching between different sort criteria). Sorting a 30k list hardly took any time. I'm not sure what causes the delay in the current code, but I'm confident that won't be an issue in 2.0.

[Pieter Hulshoff]

I've added the catver.ini information to the XML game list creation tool, as well as the directory structure as used by Hyperspin (Databases->system name->system name.xml). This will allow us to re-use their files as well as offering our own to their database. As far as I can tell, using mess for console emulation is still quite rare on Windows. Personally I rather like it, since it creates a common interface and setting for multiple systems.

I would like to take a decision with regards to our game list class structure. Assuming the new game list structure, how do we connect them to our system list, and how do we store the game list for each system?

[Pieter Hulshoff]

On Friday, October 10, 2014 2:17:02 PM UTC+2, Pieter Hulshoff wrote:

I would like to take a decision with regards to our game list class structure. Assuming the new game list structure, how do we connect them to our system list, and how do we store the game list for each system?

I've not been able to come up with an answer to this yet. Using vectors/deques as elements of a class is a huge hassle. Using pointers was a lot easier in that regard. Alternatively we could use separate vectors/deques for the systems lists and the games lists, and use matching indices. That does however sacrifice some flexibility. I've also considered adding the system name to the game class, so each game is automatically linked to a system via its name, and use a list of all games as a database from which a game list can be selected based on criteria (like system or genre). Any thoughts? I'm a bit stuck here at the moment, so I'd welcome any insights. :) The more flexibility we want, the more difficult this class setup and interaction seems to become.

[Joseph K]

I think my suggestion was misunderstood. Particularly with a large list, we want to minimize redundancy. That means as few duplicates as possible. I was imagining we keep an xml reference structure for the "full" list. We use the deque ONLY for what is shown on screen, possibly with a half screen slack on either side. If we are using a wheel that has 10 items on screen, the deque will have 20 items, with a "currentSelection" iterator. It sounds reasonable in my head since we will have a small list to go through for redraws. How that links to execution is still a little fuzzy (maybe the deque type is XMLNode*). There should be a DisplayIFace that interfaces with OpenGL/DX/whatever... then a GUIClass that owns the deque, and sends updates to DisplayIFace (say).

With regards to the system<->game linkage, HS implicitly links based on the list the game resides in. e.g., if "sonic & knuckles" is in "genesis.xml" it will use the emulator defined for "genesis" in the "system.xml". It also allows explicit links via an optional tag in the game entry (I think "executable"). The execution is done via an executable script made in AutoHotKey, that looks a little like this:
http://www.autohotkey.com/board/topic/89435-hyperlaunch-script-and-xpadder/

HS really only calls "HyperLaunch <system> <title>", unless you tell it otherwise. The optional tag was handy as I used demul instead of mame for games like fist of the north star and dolphin blue. Literally, the call would be "HyperLaunch.exe MAME mslug3" or "HyperLaunch demul fotns". The "MAME" portion would be parsed in the giant if/else autohotkey script, then execution would happen within AHK. Also notice that AHK steals focus so hyperspin goes idle.

We could get a similar effect with perl or even bash. PERL would be more portable, and we would have a localized place for executables and parameters.

Yesterday was a day of hand throbbing pain and i couldnt focus for longer than 30 min... hope to be productive today

[Pieter Hulshoff]

On Friday, October 10, 2014 4:17:51 PM UTC+2, Joseph K wrote:

I think my suggestion was misunderstood. Particularly with a large list, we want to minimize redundancy. That means as few duplicates as possible. I was imagining we keep an xml reference structure for the "full" list. We use the deque ONLY for what is shown on screen, possibly with a half screen slack on either side. If we are using a wheel that has 10 items on screen, the deque will have 20 items, with a "currentSelection" iterator. It sounds reasonable in my head since we will have a small list to go through for redraws. How that links to execution is still a little fuzzy (maybe the deque type is XMLNode*). There should be a DisplayIFace that interfaces with OpenGL/DX/whatever... then a GUIClass that owns the deque, and sends updates to DisplayIFace (say).

We don't need a deque for what's shown on screen; simply a pointer to the current game, and skin elements indexed by an offset compared to the current game (taking into account certain filters). Searching through these lists is very fast. I'm not in favour of keeping the XML structure in memory; it's very inefficient, and slow to work through compared to a linked list, vector or deque.
 

With regards to the system<->game linkage, HS implicitly links based on the list the game resides in. e.g., if "sonic & knuckles" is in "genesis.xml" it will use the emulator defined for "genesis" in the "system.xml". It also allows explicit links via an optional tag in the game entry (I think "executable"). The execution is done via an executable script made in AutoHotKey, that looks a little like this:

A fixed link between emulator and game could be done by keeping a link between the game list and the system list or by using the same index. It's also possible to keep one huge game list (rather than several smaller ones), and create a new smaller list whenever the system is switched. This last options comes closer to a database, which would allow easier switching to a true database at a later time. It's also more complex to build.
In my own front-end I had a vector of systems and a vector of (pointers to) game lists (double linked lists). Since the index of both vectors was the same, all I had to do was remember the index of the current system. I was hoping for something more flexible for Cabrio 2.0, but it does bring a lot of complexity with it. When I switched to a vector for the game list, I ended up with a vector of vectors for the set of gamelists; that really didn't work too well for me. I also noticed that sorting a (double) linked list was a lot easier than sorting a vector.

[Pieter Hulshoff]

My current view is:
Game class, containing all game related information.
A system class, containing the emulation command and a pointer to a vector of games.
A vector of systems.
For a first release the game will not contain separate fields to overwrite the system's emulation command. The games list XML file format doesn't appear to have fields defined for that purpose anyway.

Some systems support multiple media formats (cartridge, disk, cassette, cdrom); I haven't quite figured out how best to handle those. The consoles don't have that problem, so that part should be relatively easy. I'll write up some class files soon, and update the file I/O accordingly. System information will probably be put in a systems.xml file as Joseph mentioned. I'll start out with a small set of systems to see how that works; not all systems are interesting to be added anyway, and for many of those systems we don't have any art available either.

Any thoughts?

[Pieter Hulshoff]

Scratch that; sometimes a night of sleep works wonders. :)
Menu class: contains:
- pointer to emulator settings (separate class?)
- pointer to child menu(s)
- pointer to parent menu
- pointer to game information (separate class?)
This way I can set up any dynamic menu structure I want, and overwrite emulator settings of the parent in a child menu.
If this sounds acceptable, I'll have a crack at implementing it. :)

[Steve Maddison]

On 10 October 2014 23:46, Pieter Hulshoff <phuls...@gmail.com> wrote:

Some systems support multiple media formats (cartridge, disk, cassette, cdrom); I haven't quite figured out how best to handle those. The consoles don't have that problem, so that part should be relatively easy. I'll write up some class files soon, and update the file I/O accordingly. System information will probably be put in a systems.xml file as Joseph mentioned. I'll start out with a small set of systems to see how that works; not all systems are interesting to be added anyway, and for many of those systems we don't have any art available either.

Any thoughts?

How it's worked up to now (or how it was meant to work) was that each game has a platform (or system) and that the platform can have one or more emulators. Maybe using both terms we can handle the different media formats, etc. So, you have a system (SNES, CPC464, whatever) which contains the path to the emulator and global options (fullscreen, skip intro, etc.). Then these systems are the basis of zero or more platforms (SNES with Satellaview, CPC464 with a disk drive) which contain the supplementary options the emulator needs to know about.

 

[Pieter Hulshoff]

Perhaps I should have been slightly more clear: I know how to do it by hand, but I have to figure out how to detect this automatically so I can autogenerate the corresponding XML files rather than writing them by hand. :)

[Steve Maddison]

What, in this sense, is a menu? I suppose a collection of games, or actually a kind of tree structure containing sub-menus? Something about it seems to be hinting at data and presentation getting mixed up somewhere, but maybe I'm just not grasping the concept.

Maybe it'll help to bang out a provisional data model? What I currently have in mind is something along the lines of:

- A Game class (title, rom image, *platform, *genre, etc)

- A GameList class/singleton, which contains all the Games we know about. The UI can then set filters on this, which influence what comes out when it asks for first(), next(), previous(), etc. With no filter, asking next() just goes through sequentially. With a filter set, asking next() will skip through until it finds the next game matching the current filter. This maps nicely to both a simple list (vector/deque/linked-list) and a relational database, should we decide to move to that later. It also makes drill-down approach possible, not only in terms of system -> genre -> whatever but also in terms of "give me the games starting with 'a', 'ab', 'abc'" and so on.

- Classes (or subclasses of some abstract class) for reading different file formats and adding the contents to the GameList. This includes linking the games to a platform, genre, etc.

In this concept, I'd consider a "menu" to be part of the UI layer which basically just consumes data from the GameList and presents the necessary things to the user. It would also keep track of where in any tree/hierarchy of menus the user is at any moment, and handle transitions to/from higher/lower menus.

Genre here would be a fine example of what in 1.0 is called a category, which is basically a sort of tagging system. I'd really like to keep the flexibility this system offers as the user can literally filter on any property of the game they want. The GameList would need to support arbitrary categories/tags by some kind of abstract Category class and allow filtering on any combination of these.

The downside of this flexibility, at least in the current implementation, is that there's a lot of lazy instantiation and housekeeping to do as start-up to build up the game list and create categories (and values for categories) where necessary. This could be alleviated somewhat by making sure all systems, platforms and categories are defined up-front, like in a separate config file.

Well, that turned out to be more of a brain dump than I'd intended, hopefully you guys can make some sense of it! 

--Steve

[Steve Maddison]

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

Perhaps I should have been slightly more clear: I know how to do it by hand, but I have to figure out how to detect this automatically so I can autogenerate the corresponding XML files rather than writing them by hand. :)

Aah, that is indeed another story :) I suppose you're always going to need some help from the user, either on the command line (i.e. "generate a list for this directory and tag them all as platform X") or though some kind of configuration saying what to do for particulate directories/subdirectories. Maybe some intelligence can be gleaned from the directory structure itself, i.e. tag everything in the "snes" directory with platform "snes".

[Pieter Hulshoff]

With a menu I mean the selection hierarchy to come to a game selection. How those games are connected in the end is up for debate:
1. Like in HS and Cabrio 1.0, games are a part of the menu via XML files.
2. Games are in a database, and each endmenu can make a specific selection. This however does mean that for each list selection criteria must be found.
3. Both: standard menu structure with games, but games are also stored in a database to allow automatic list generation based on criteria, e.g. all racing games starting with "ro".

[Pieter Hulshoff]

Well, I've started with the first class definitions, its functions, and the file I/O. The intention is to auto generate the menu structure based on directory structure and XML files. The idea is to start with supporting a few systems (MAME, NES, SNES, etc.), and work from there.

[Pieter Hulshoff]

I've made a few changes; I'm using xml files for menu structures now as well. I can read in a general menu structure and game XML files now, resulting in a hierarchical menu with game lists at the end. So far it seems to be working fine, so I'll add a few more class functions to allow proper walking through the structure, and getting the proper command to run a game. Next step will be checking whether rom files are available, and adding that information to the database to allow selection of available games only. I'll keep you posted. :)

PS: I wouldn't mind a quick github tutorial. I'd appreciate some command examples needed to check out the Cabrio 2.0 database, check in new files, and check in file updates. It would beat having to work my way through the rather lengthy online tutorial. :)

[Pieter Hulshoff]

A few more changes: I've reduced the setup to a single class (Menu), and successfully read out a menu structure using 8 different systems (1x MAME, 7x MESS). I'll continue with some code clean up, and add more comments. I also plan to add a check for ROM availability soon, and allow people to overwrite the emulator command within a <game> element.

[Pieter Hulshoff]

This is what I have at the moment as far as functions are concerned. Please have a look, and give me some feedback, especially if there are additional functions that you think you may need. Prelimenary tests seem to indicate that it's working for me, but I plan to extend the testing to make sure. :)

Menu.hpp:
----------
#include <string>
#include <vector>
#include <sys/types.h>
using namespace std;


// Define MENU filters
#define MENU_FILTER_NONE      0      // No filter
#define MENU_FILTER_AVAILABLE 1 << 0 // Filter unavailable games
#define MENU_FILTER_MATURE    1 << 1 // Filter mature games
#define MENU_FILTER_CLONE     1 << 2 // Filter clones


// Menu class, used to store hierarchical menu structures, emulation parameters, and game parameters
class Menu
{

  // Public functions
  public:

    // Constructor and destructor
    Menu( );                                                      // Construct empty menu
    Menu( string path, string filename );                         // Construct new menu, and load it with "<path>/<filename>.xml"
    ~Menu( );                                                     // Destruct menu structure

    // Set data members
    void SetName( string name );                                  // Set name data member
    void SetParent( Menu *parent );                               // Set parent menu
    void AddChild( Menu *child );                                 // Add child menu
    void SetChild( long offset, uint filter_flags );              // Set the current child based on offset and filter flags
    void SetExecutable( string executable );                      // Set emulator executable data member
    void SetRomPath( string rom_path );                           // Set rom path data member
    void AddParameter( string parameter );                        // Add emulator parameter
    void SetDescription( string description );                    // Set game description data member
    void SetCloneof( string cloneof );                            // Set clone of data member
    void SetManufacturer( string manufacturer );                  // Set manufacturer data member
    void SetYear( string year );                                  // Set year data member
    void SetGenre( string genre );                                // Set genre data member
    void SetAvailable( bool available );                          // Set game available data member
    void SetIsGame( bool is_game );                               // Set game indication data member

    // Get data members
    string        Name( );                                        // Get name data member
    Menu         *Parent( );                                      // Get parent menu
    Menu         *GetChild( long offset, uint filter_flags );     // Get child based on offset and filter flags
    unsigned long GetNrChildren( );                               // Get number of children
    string        Executable( );                                  // Get emulator executable data member
    string        RomPath( );                                     // Get rom path data member
    string        Command( );                                     // Get emulation command to start the game
    string        Description( );                                 // Get game description data member
    string        Cloneof( );                                     // Get clone of data member
    string        Manufacturer( );                                // Get manufacturer data member
    string        Year( );                                        // Get year data member
    string        Genre( );                                       // Get genre data member
    bool          Available( );                                   // Get information whether current menu contains any available games or if the game is available
    bool          IsGame( );                                      // Get game indication data member
    bool          IsMature( );                                    // Get mature indication from the genre

  // Private data members and functions
  private:

    // Data members
    string         name_;                                         // Name data member
    Menu          *parent_;                                       // Parent menu
    vector<Menu*>  children_;                                     // Children menu(s)/game(s)
    unsigned long  current_child_;                                // Current menu/game

    string         executable_;                                   // Emulator executable data member
    string         rom_path_;                                     // Rom path data member
    vector<string> parameters_;                                   // Emulator parameters

    string         description_;                                  // Game description
    string         cloneof_;                                      // Game clone of
    string         manufacturer_;                                 // Game manufacturer
    string         year_;                                         // Game year of publication
    string         genre_;                                        // Game genre
    bool           available_;                                    // Game availability
    bool           is_game_;                                      // Game indication

};

[Pieter Hulshoff]

Word is back from the HS community: no torrents with their material. I guess we'll just point to their repositories in stead, and encourage people to become a member there. For now I only have a few minor changes in mind left for the menu structure (unless you two have some specific changes in mind other than a proper C++ overhaul by Joseph), so I'll focus on writing some more tools for XML generation, theme installation, and file renaming. We'll need those to provide a smooth user experience. Besides: I'd hate to have to do this manually more than once. :)

[Steve Maddison]

Hi Pieter,

Hoped to get back to you earlier than this but have been stuck with a tiny screen every time I got a chance to look at it! I'm having a bit of a hard time "getting it" out of context - do you have some code which uses this class? Does this structure contain the actual game data?

Cheers,

Steve

--
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
http://www.cosam.org/

[Pieter Hulshoff]

On Wednesday, October 22, 2014 9:49:14 PM UTC+2, Steve Maddison wrote:

Hoped to get back to you earlier than this but have been stuck with a tiny screen every time I got a chance to look at it! I'm having a bit of a hard time "getting it" out of context - do you have some code which uses this class? Does this structure contain the actual game data?

Yes, I do. I checked the menu code into the database, but I'm also sitting on a small test program, which reads the menu, and then prints part of that information to the screen (or a file if you pipe it there). I also have a menu.xml file, and xml game files for 7 MESS systems and for MAME. I'm not sure what to do with those files: check them into the database separately, as a tgz file or simply email them to you to play around with.

[Steve Maddison]

On 22 October 2014 14:18, Pieter Hulshoff <phuls...@gmail.com> wrote:

Word is back from the HS community: no torrents with their material. I guess we'll just point to their repositories in stead, and encourage people to become a member there.

I guess that was to be expected. Best we can do is make it easy to import stuff once people have downloaded it themselves.

 

For now I only have a few minor changes in mind left for the menu structure (unless you two have some specific changes in mind other than a proper C++ overhaul by Joseph), so I'll focus on writing some more tools for XML generation, theme installation, and file renaming. We'll need those to provide a smooth user experience. Besides: I'd hate to have to do this manually more than once. :)

Nice, keep us in the loop with the tools - I may not always have much in the way of feedback but I do at least read everything ;)

[Pieter Hulshoff]

Ok, let's give this another try; I posted some half lines of code the previous time. Here's the simple test program I used. The XML files were in a directory called Menu, with a root file called menu.xml.

----- test_menu.cpp
#include <iostream>
#include <string>
#include "menu.hpp"
using namespace std;


void PrintMenu( Menu *menu )
{

  // Indentation based on the hierarchy
  Menu *menu_parser = menu;
  while ( menu_parser->Parent( ) )
  {
    menu_parser = menu_parser->Parent( );
    cout << "  ";
  }

  if ( menu->IsGame( ) ) // Print game command
  {
    if ( menu->Available( MENU_FILTER_NONE ) )
      cout << "Game \"" << menu->Description( ) << "\" uses emulator command \"" << menu->Command( ) << "\", and is available." << endl;
    else
      cout << "Game \"" << menu->Description( ) << "\" uses emulator command \"" << menu->Command( ) << "\", but is not available." << endl;
  }
  else // Print menu name and number of children, and print the child menus
  {
    cout << "Menu \"" << menu->Name( ) << "\" has " << menu->GetNrChildren( ) << " children." << endl;
    if ( menu->GetNrChildren( ) != 0 )
      for ( uint i = 0; i < menu->GetNrChildren( ); i++ )
        PrintMenu( menu->GetChild( i, 0 ) );
  }
  return;
}


int main( )
{

  Menu *menu = new Menu( "Menu", "menu" );
  cout << "Menu \"" << menu->Name( ) << "\" is loaded." << endl;
  PrintMenu( menu );
  return 0;

}

[Steve Maddison]

On 22 October 2014 21:52, Pieter Hulshoff <phuls...@gmail.com> wrote:

On Wednesday, October 22, 2014 9:49:14 PM UTC+2, Steve Maddison wrote:

Hoped to get back to you earlier than this but have been stuck with a tiny screen every time I got a chance to look at it! I'm having a bit of a hard time "getting it" out of context - do you have some code which uses this class? Does this structure contain the actual game data?

Yes, I do. I checked the menu code into the database, but I'm also sitting on a small test program, which reads the menu, and then prints part of that information to the screen (or a file if you pipe it there).

Cool, if you can add that to your repo somewhere I'll pick it up and have a look.

 

I also have a menu.xml file, and xml game files for 7 MESS systems and for MAME. I'm not sure what to do with those files: check them into the database separately, as a tgz file or simply email them to you to play around with.

 I'd say just stick them in the "shared" directory of your repo, unless they're ridiculously large (git will compress stuff when it can anyway).

[Pieter Hulshoff]

Done, and done. Feel free to have a look. :)

[Joseph K]

In other news, I managed to create my own fork... get the singleton and iterator stuff working and submitted to my fork.

I'm still getting used to git, and don't quite have it seamless on my linux laptop.

Just had surgery today too... so I'll be well medicated for a few days.

regards,
Joseph

[Pieter Hulshoff]

Be well Joseph, hope you'll feel better soon.

With regards to directories: do we wish to use a fixed directory structure, a fixed directory structure with an offset for each emulator or a completely configurable directory structure? Should ROMs be a part of this directory structure or should they be separately configurable from the media files? As an example:
Often seen structures:
Media/<system>/<media files>
PD repositories for MESS however:
<media type>/<system>
We should either choose a structure that we feel is handy, and perhaps provide some tools to convert repositories to that format, or we need to set up configurable paths for every media type. Any thoughts?

With regards to the menu structure: I'm considering separating the emulator settings from the rest of the menu. That way, if the same emulator is used in different menus, the paths etc. only need to be defined once.

[Pieter Hulshoff]

Do we wish to add zip support within Cabrio 2.0 with regards to theme and art packaging?
I'm currently having a look at the material available on the HS FTP site, and plan to set up a complete system with it. In the process, I plan on keeping notes so I can write a guide or even a tool to help users set things up. There's about 600 GB of material, so it's quite a lot of work to sift through.

With regards to emulators: I've been focusing on MAME and MESS so far, but are there any others we should consider adding? I know it will be configurable, but I'd like to test things well to make sure we're not missing something. MAME/MESS for instance don't need specific rom file names anymore; it will automatically find them within the .zip or .7z packages available through the usual channels.

[Pieter Hulshoff]

Joseph, are you in the process of improving the C++ capacity of my code, or can I safely make changes in the next few weeks?

Having seen what's available on the HS FTP server, I can imagine people having trouble getting a full system up and running. Without HyperSync, that's really a tough job to do! I think I'm just going to go define a directory structure that'll work for me, and we can take the discussion from there on whether or not we want everything programmable or just use a fixed structure, and (auto)convert the files.

[Joseph K]

I won't be able to make any significant changes until next week. I have my daughter this week too. Feel free to build away and we can work any changes later.

I'm still mostly in my own sandbox anyway, I don't think my code had been pulled yet.

On October 26, 2014 1:26:18 PM MDT, Pieter Hulshoff <phuls...@gmail.com> wrote:

Joseph, are you in the process of improving the C++ capacity of my code, or can I safely make changes in the next few weeks?

Having seen what's available on the HS FTP server, I can imagine people having trouble getting a full system up and running. Without HyperSync, that's really a tough job to do! I think I'm just going to go define a directory structure that'll work for me, and we can take the discussion from there on whether or not we want everything programmable or just use a fixed structure, and (auto)convert the files.

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

[Steve Maddison]

On 24 October 2014 09:51, Pieter Hulshoff <phuls...@gmail.com> wrote:

Be well Joseph, hope you'll feel better soon.

Yeah, all the best Joseph!

 

With regards to directories: do we wish to use a fixed directory structure, a fixed directory structure with an offset for each emulator or a completely configurable directory structure? Should ROMs be a part of this directory structure or should they be separately configurable from the media files? As an example:
Often seen structures:
Media/<system>/<media files>
PD repositories for MESS however:
<media type>/<system>
We should either choose a structure that we feel is handy, and perhaps provide some tools to convert repositories to that format, or we need to set up configurable paths for every media type. Any thoughts?

The problem I see with fixing the directory structure is that it then forces the user to organise things in a particular way, which isn't always going to make sense to them. In Cabrio 1.0 it's all totally configurable so I wouldn't want to lose that feature. What may be useful is to provide some presets that will work with directory structures used by various media archives, etc.

 

With regards to the menu structure: I'm considering separating the emulator settings from the rest of the menu. That way, if the same emulator is used in different menus, the paths etc. only need to be defined once.

Yeah, that sounds like a good plan. A separate Emulator class seems to be the most logical way. On a side note, there are use cases where one game may be playable on several emulators, in which case the user may be prompted to select one when selecting that game.

Re. the rest of the menu code, it looks like a nice start but I'm not really able to integrate very much right now. There's a lot of differences/overlap with the existing GameList/Platform structures so, if you don't mind, I'd like to park it for now until we see how things work in practise. Hopefully it will then all "gel" a bit easier, and we can cherry pick the best bits of code.

[Steve Maddison]

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

Do we wish to add zip support within Cabrio 2.0 with regards to theme and art packaging?

I think it's worth doing where it makes sense, like to group the components of a theme together, for example.

  

With regards to emulators: I've been focusing on MAME and MESS so far, but are there any others we should consider adding? I know it will be configurable, but I'd like to test things well to make sure we're not missing something. MAME/MESS for instance don't need specific rom file names anymore; it will automatically find them within the .zip or .7z packages available through the usual channels.

I think MAME is an obvious favourite but it should be possible to support anything. Most of the emulators I've seen are pretty easy to run, just set a few options and pass it a file name. If the emulator can take zips or whatever, all we'd need is a config option to strip the extensions when the emulator gets run. If it's able to search in multiple places, a similar option to strip any leading directory paths would be possible too. In the grand scheme of things, however, I dare say that this is pretty special behaviour and most emulators will just want the whole path and file name.

[Steve Maddison]

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

Having seen what's available on the HS FTP server, I can imagine people having trouble getting a full system up and running. Without HyperSync, that's really a tough job to do! I think I'm just going to go define a directory structure that'll work for me, and we can take the discussion from there on whether or not we want everything programmable or just use a fixed structure, and (auto)convert the files.

That's cool, at the end of the day you're also a user and if you have a specific set-up in mind, it should work, right ;) At this stage I'm not even worried about hard-coded paths in the code, as long as we can easily make them configurable later.

[Steve Maddison]

On 26 October 2014 20:44, Joseph K <jcko...@cs.unm.edu> wrote:

I'm still mostly in my own sandbox anyway, I don't think my code had been pulled yet. 

Yeah, I'm figuring it's best not to pull stuff too early, so I'm kind of relying on you guys to give the go-ahead. That said, I'll have a crack at merging it now so we don't end up diverging too far.

[Joseph K]

On October 26, 2014 2:20:21 PM MDT, Steve Maddison <st...@cosam.org> wrote:
>On 25 October 2014 16:42, Pieter Hulshoff <phuls...@gmail.com>
>wrote:
>
>> Do we wish to add zip support within Cabrio 2.0 with regards to theme
>and
>> art packaging?
>>
>
>I think it's worth doing where it makes sense, like to group the
>components
>of a theme together, for example.
>

This is sort of how the themes in HS work. They are just zips of folders with some structure.

As a side note, occasionally you'll run into a zip of multiple games. .. such as a single zip that has different versions of the same game. An emulator won't understand that, I'm not so sure we should either.

>
>> With regards to emulators: I've been focusing on MAME and MESS so
>far, but
>> are there any others we should consider adding? I know it will be
>> configurable, but I'd like to test things well to make sure we're not
>> missing something. MAME/MESS for instance don't need specific rom
>file
>> names anymore; it will automatically find them within the .zip or .7z
>> packages available through the usual channels.
>>
>> I think MAME is an obvious favourite but it should be possible to
>support
>anything. Most of the emulators I've seen are pretty easy to run, just
>set
>a few options and pass it a file name. If the emulator can take zips or
>whatever, all we'd need is a config option to strip the extensions when
>the
>emulator gets run. If it's able to search in multiple places, a similar
>option to strip any leading directory paths would be possible too. In
>the
>grand scheme of things, however, I dare say that this is pretty special
>behaviour and most emulators will just want the whole path and file
>name.

Mame has a user configurable rom search path. I think we may want to do the same to allow for user configurability. It's set like an ENV list, a semicolon delimited lost of fully qualified paths. I like that idea, even though it's a little added complexity.

Personally, I use:
Snes9x
Nestopia
Yabouse
Mupen64
Gens
Epsxe
Dolphin

All of the above will execute a fully qualified path to a rom. The only question is if we want separate search paths by system, or one full-up list.

[Joseph K]

I tried sending a pull request, but my build environment wasn't allowing it. Feel free to pull my code in.

-Joseph

[Steve Maddison]

On 26 October 2014 21:34, Joseph K <jcko...@cs.unm.edu> wrote:

As a side note, occasionally you'll run into a zip of multiple games. .. such as a single zip that has different versions of the same game. An emulator won't understand that, I'm not so sure we should either.

 

Nice... not sure what to make of it either but I suppose if someone wants to pass such a zip to some emulator we should let them.

 

Mame has a user configurable rom search path. I think we may want to do the same to allow for user configurability. It's set like an ENV list, a semicolon delimited lost of fully qualified paths. I like that idea, even though it's a little added complexity.

Personally,  I use:
Snes9x
 Nestopia
Yabouse
Mupen64
Gens
Epsxe
Dolphin

All of the above will execute a fully qualified path to a rom. The only question is if we want separate search paths by system, or one full-up list.

I'm thinking do it the same as the media; allow paths to be specified globally and at all levels down to the individual game. Then just search through the paths heirarchically from specific to general and stop when you find something. With any luck we can even reuse the same code. I hadn't thought of specifying multiple paths at each level though, which we'll no doubt need to allow.

[Steve Maddison]

On 26 October 2014 21:35, Joseph K <jcko...@cs.unm.edu> wrote:

I tried sending a pull request, but my build environment wasn't allowing it. Feel free to pull my code in.

 

Yup, managed to create a PR and it's now merged. I needed to add a C++11 compiler flag to get it working locally, probably because I'm working on a Mac just now.

[Joseph K]

It's because the template is using a couple c++11-isms. I started working a bit on the graphics portion, but it's nowhere near functional.

Regards,
Joseph

[Pieter Hulshoff]

I'm thinking do it the same as the media; allow paths to be specified globally and at all levels down to the individual game. Then just search through the paths heirarchically from specific to general and stop when you find something. With any luck we can even reuse the same code. I hadn't thought of specifying multiple paths at each level though, which we'll no doubt need to allow.

That's basically what my menu code currently does, but I want to add a bit more flexibility still. :)

[Steve Maddison]

Hi chaps,

I just pushed and merged a feature which implements a basic OpenGL 3.3 renderer. The code says it all really: the abstract class Renderer has a number of Quad children with position, size and rotation (just now this is a simple vector, but I think it will benefit from better encapsulation). The OpenGL subclass then implements the actual context creation (just now it's a window) and does the drawing stuff.

I guess the renderer should be a singleton, I'll see if I can use Joseph's abstract class for that. Likewise for the basic Logger class I knocked up which can be used to, well... log stuff. For now it just goes to the console. I've got a bit of copy-pasted code left which just outputs directly which need to be changed to go through the Logger.

Then on to textures: just now I have an Image class which can load images from disk using SDL_image. I figured an SDL_Surface is a decent common denominator for passing bitmaps around (at least for now). Next thing is to convert this to a texture and have the quads rendered using these and with the correct transparency.

Cheers,

Steve

[Joseph K]

Steve,

Thanks for taking care of that part. I've been mulling over how to do an abstraction over such a beast, a sort of intermediate layer that handles a generic outline mode (list, grid, etc. ..) between system calls and the user interface.

My thinking is this layer can be an abstract class in itself, then we can derive stuff from it. Should make it relatively simple to introduce new display formats. I'm planning on tearing into that tonight.

Cheers,
Joseph

[Steve Maddison]

On 28 October 2014 23:46, Joseph K <jcko...@cs.unm.edu> wrote:

Steve,

Thanks for taking care of that part. I've been mulling over how to do an abstraction over such a beast, a sort of intermediate layer that handles a generic outline mode (list, grid, etc. ..) between system calls and the user interface.

I figured being able to place quads however you like in 3D space allows us to do pretty much anything we envisioned up to now. And anything else can be added later.

 

My thinking is this layer can be an abstract class in itself, then we can derive stuff from it. Should make it relatively simple to introduce new display formats. I'm planning on tearing into that tonight. 

Totally with you there. This is essentially the "hard" (as in compile-time) part of something approaching upon a theme. Maybe it actually is a theme and the imagery, colours, etc. are more of a skin. Or maybe a "theme" is a combination of this thing and a skin. It'll be an important class; how were you thinking of naming it?

I suppose what we then need is an equivalent of the Renderer class for event handling, which can then be implemented in different ways (SDL, GLFW, whatever) and manages an (abstract) event queue that can be popped by the above.

[Joseph K]

On 10/29/2014 10:27 AM, Steve Maddison wrote:

On 28 October 2014 23:46, Joseph K <jcko...@cs.unm.edu> wrote:

Steve,

Thanks for taking care of that part. I've been mulling over how to do an abstraction over such a beast, a sort of intermediate layer that handles a generic outline mode (list, grid, etc. ..) between system calls and the user interface.

I figured being able to place quads however you like in 3D space allows us to do pretty much anything we envisioned up to now. And anything else can be added later.

That's along the lines of what I was thinking. We will need some schema for what quads 0 through 200 mean. That could be dependent on the layer above.

 

My thinking is this layer can be an abstract class in itself, then we can derive stuff from it. Should make it relatively simple to introduce new display formats. I'm planning on tearing into that tonight. 

Totally with you there. This is essentially the "hard" (as in compile-time) part of something approaching upon a theme. Maybe it actually is a theme and the imagery, colours, etc. are more of a skin. Or maybe a "theme" is a combination of this thing and a skin. It'll be an important class; how were you thinking of naming it?

My thinking is that a "theme" is more like how HS defines it. It includes things like background, cover art, screen shot, movie, etc... though this I think could (should?) be separate from the x,y positions.

This class would allow for some interpretation for where those are displayed, or if they are displayed. I may reserve space on the side for the grid, or I may position the movie over the current selection. Depends on how the user wants to define the "Layout" for the display type. In this way, "grid" or "list" always means the same thing, and switching between content would still give the same feel.

So in a way, a full-up "theme" would be a combination of the two. By the very nature of having different  ways to display content, we will be breaking some compatibility with HS. Though they aren't completely consistent with their themes either (main wheel theme vs system theme vs game theme).

Naming is still a bit up in the air, though I think "BaseLayout" with derived classes "GridLayout", "ListLayout", and "WheelLayout" (or swapping the words for file list friendliness) would be intuitive and distinct from "theme".

I suppose what we then need is an equivalent of the Renderer class for event handling, which can then be implemented in different ways (SDL, GLFW, whatever) and manages an (abstract) event queue that can be popped by the above.

This is what I was thinking, and its a relatively simple way to do cross-platform work too. Speaking of, the Linux Mint I was using didn't have GLFW libraries recent enough (despite them being 3 years old) to compile cabrio... So I'm switching to Linux Mint Debian edition, which I hope will be more stable and workable. In other words, we have a little time before we decide on names.

-Joseph

[Joseph K]

On 10/29/2014 12:38 PM, Pieter Hulshoff wrote:
> I think we need to define a list of skin element types, and define the
> parameters for each element. IMHO, wheel is not an element type. A
> wheel is just a way of displaying a list of skin elements like
> screenshots, marqueues, etc. By using separate elements we can create
> any type of display that we want rather than having to define the
> parameters of a "wheel", and then consider all kinds of other ways of
> displaying these same elements.
Pieter,
Exactly what I was getting at... though I may not have been clear.

I'm thinking the "Layout" types are really just some codification of how
the GameList (and back to parent) are displayed. We can leave it to the
user to tweak a bit, such as quad definitions for:
GameList
Movie
CoverArt
Screenshot
CartridgeArt
GameLogo (marquee)

The layout doesn't care where these things are, it just helps keep
things consistent... so all "wheel" lists look the same, just with
different imagery. Likewise for all "grid", "vertlist" or maybe
"horizontallist". The user selects which layout type via xml somewhere.

Sounds like we are on the same page, yes?

[Joseph K]

On October 29, 2014 2:44:43 PM MDT, Pieter Hulshoff
<phuls...@gmail.com> wrote:
>My thoughts go more along the line of skin elements:
>- Name
>- Manufacturer
>- Year
>- Screenshot
>- Titleshot
>- Marquee
>- Video
>- Image (can be any kind of image: background, smaller picture; just a
>fixed image name)
>- Box 2D
>- Box 3D
>- Cart 2D
>- Cart 3D
>- HS wheel image
>

I agree with this list, pretty extensive options.
These should have some boolean associated with them, and potentially a
backup. Having all of this will be too cluttered, but we can let the
user shoot themselves in the foot. I say backup in case art is missing
for something, something else gets displayed.
>Each of these elements has parameters, like location (x,y,z), size
>(x,y,z),
>rotation, delay, animation, offset to the current game, etc. You can
>build
>almost any kind of theme with these elements this way.

In talking 3D, let's talk about z values (ordering). We may consider
making the display very flat, translating a z order from 1 to 20 to an
opengl value between 0 and 1. We could do something like a halfway, but
that puts more work on a user. I'd think this should be handled at what
I'm calling the "layout" level.
>A wheel displaying 9 games would simply consist of 9 HS wheel image
>elements, each at a certain location, size, rotation, and with a
>certain
>offset (-4, -3, -2, -1, 0, 1, 2, 3, 4) to the current game.
>
There is a distinction here too. This is a Game List abstraction. How
this ties to a layout and how that is expressed in the skin is a little
fuzzy to me right now.
I could see some "SelectionEffect" function makes the current selection
bigger or highlighted somehow. I could see this being part of the base
layout class, though I think it should really apply to the GUI.


>You do have an important point though: grid lists cannot created this
>way,
>since selection moves along the grid rather than having the selected
>game
>always at a fixed location.

I'm getting started on a "LayoutBase" class that other classes can
derive from. I'm also pushing imagery to be tied to the XML "levels"
such as Game. It makes sense to only navigate one list for everything.

Regards,
Joseph

[Pieter Hulshoff]

Ok, I'm not entirely sure what's going wrong here, but that's the 3rd message I posted that gets swallowed by the system. I can't even see the message you replied to Joseph. Can you see it or did I just forget to remove you from the copylist?

[Pieter Hulshoff]

Once again, my post got swallowed. It pretends it's posted, and even shows it as such in my window, but when I go back to the group overview it's simply not there... Luckily I came prepared this time:
----- Included post -----
I propose that one of you writes a proposal for the XML structure for the themes/skins. We can then discuss additional features or changes, and I could write some code to read and parse such a file. I agree that we need layout structures as well as separate elements to allow maximum flexibility.

I'm currently in the process of wading through 600 GB of HS material in order to find some good bases to work from for our first skins. Of course we'll have to define some alternative skins as well, not dependent on HS material. I'll probably port my own old skin from MAMEd to this format as well; simple as it may be. :)

[Pieter Hulshoff]

Another issue popped up:
I'm currently basing my XML generation on MAME/MESS output, which perfectly matches some game repositories out there. It may however not match with ROMs people already have, nor will it match with the HS XML or the HS art names. For older systems, the lists are unlikely to change since all games for the system are known. I see two paths before us when it comes to these old systems:
1. We stick to the MAME/MESS naming, create our own XML files, and rename the HS art and/or provide tools for users to do so.
2. We use the HS names, possibly the HS XML files, and provide tools for users to rename their games.
I'm leaning towards the first option, though I'm also in discussion with HS developers to add additional information to their XML files.
Any thoughts?

[Joseph K]

As I go through with an implementation of the GUI portion, I'll make note of what makes sense and where. Should be able to weasel out a good v1 out of it.

-Joseph

[Joseph K]

When building my cabinet I used CLRMAMEPRO to test and rename "known" roms from various systems using dat files found here:
http://datomatic.no-intro.org/?page=download&fun=datset

I then used something like HyperROMtoXML (I'd have to tear into my cabinet to see if I still have it) to generate the HS XML. I found that a majority of the game artwork would be found... but there was always some missing. I never cared enough to fix them all manually, and my friends never brought it up.

I'd lean toward MAME format, but I'm not sure how many people want to filter based on manufacturer or year. I could see some shiny factor in displaying it, however. What about those systems not in MESS? How do we get that data?

Are we talking lots of extra stuff over the HS format? Are we talking total incompatibility?

[Pieter Hulshoff]

Some people might be interested in filtering for manufacturer or year, but I indeed mostly put that in there so it can be displayed. I already displayed that information in my 2003 code. :)

MESS is supporting a lot of systems these days, but there's sure to be some that aren't supported; especially considering the large amount of emulators under Windows. We could use the available XML files from the HS project for that (converted to fit our own information needs) or they'll have to be written by hand (like many were for the HS project).

With regards to the extra stuff: it will simply be ignored if it's not supported. The HS community had a lot of ideas for HS 2.0, but that version never came to pass, nor is it likely it ever will be. From what I read, many are simply sticking to HS 1.3 until a better front-end comes along that will support (most of) the HS artwork. The extra XML tags may be used under HyperLaunch for additional effects though, which is why some of the users would like to see it added. For those tags that make sense, I wouldn't mind adding it to our own XML files either.

[Joseph K]

Lets be that something better ;-).

If we go full compatibility, we box ourselves in a bit. If we can do compatible, that'd be better.

As far as the effects... I'm not sure how best to go about that in code just yet.

I'm thinking maybe some enter/exit functions, much like the gamestate Ogre project. The difference being we can hand off to a particular function that has a behavior: fade in/out; zoom in/out; explode; dissolve; etc... I think this would apply to the "Layout*" classes, since they would handle changes between systems, games, etc.

I'm not quite there yet in my own sandbox, but I'm keeping it in mind.