A new Hyperspin?

[brolly]

Good, lets get this thread back on track now.

Not sure if I understood exactly what you mean with option 2, but best way for me would be option 1 and then allow users to apply some filters to it as a separate file maybe based on multiple criteria so you can have option 1 and option 2 merged together.

Add enough CLI support as well, so the user can easily feed the FE a different main menu file if he wants to.

[Hyperion]

I think I like Brolly's hybrid version better than options 1 or 2. If I had to choose I might lean towards option 1.

[phulshof]

What I mean by option 2 is this:

Imagine a "database" with all games. The user then selects the criteria from which the menu structure is generated, e.g.:

1. Platform/system

2. Genre

3. Manufacturer

The system will then automatically generate a 3 step menu structure based on those criteria: first you select the platform/system, then the genre, then the manufacturer, and finally the game from a list of games fitting those criteria.

This however does imply that all that information needs to be available for all the games in the database; otherwise the system can't use it to auto generate the menu structure.

I'm yet to decide how to handle a favourites list. In my old front-end I wrote out every game list when the program closed (this also allowed the system to start right back up the way it was turned off), but that doesn't fit too well with pre-fab XML files like HS uses. I did however already include the option to only show games that are actually available based on a simple rom file existence match.

[derekablackburn]

Game collections across platforms would be amazing.

[JSinn]

If I look at all the stuff I have, from the games to the art and videos, smooth launch into bezel screen, friends I made here and awesome hobby... even if Hyperspin never gets updated.... the literal thousands of hours of work that went into making this so shiny reminds me that what I have is well worth the donations/subs here, at emumovies and hyperlaunch.net. I can't thank this community enough for it all, and lets not forget the people making the emulators etc. I have capitalized so much on other people's hard work that I can't fathom complaining about a thing. And hey, if you want to mess with more than one front end, more power to you. But I have a sneaking suspicion that in many cases, what would attract you to another front end isn't the features that Hyperspin doesn't have.... but rather how many Hyperspin features that front end has. I know I'm pretty much nobody here, but it seemed like a good place to say it:

Sincere thanks to you all, even Sir Cyrano because I probably am using some of your art as well.

Walt

+1

[dark13]

For "a single game trought various system feature" consider you will encounter severe incosistency between boxarts. See this example. Consider also that wheel's position may vary trought systems so in this view aligning boxarts may be a problem (it will not if reflex is made trought the frontend, not embed in the .pngs, and boxarts are aligned to bottom). A wheel not linked to the size in .ini but showing the boxarts "as it is" in terms of resolution may help. But this may create some problems in visualization of different sized boxarts I guess.

The way hypersearch handles things is not that bad. Use wheelart instead of game's name and make a better layout for videos and you'll have a pretty cool stuff

[Aorin]

Not me, and I'm far from reaching 100 systems lol

Will it mean having to setup everything from scratch?

Not sure if I have the willpower to do 245 systems again............

[floatingyeti]

I would like the main menu xml to contain more info than just system names

instead of:

<game name="Nintendo Game Boy"/>

include more:

<game name="Nintendo Game Boy"/>

<manufacturer>Nintendo</manufacturer>

<year>1989</year>

<genre>Handheld</genre>

<generation>Fourth Generation</generation>

That way we could easily filter our main wheel by type of machine, release year, generation, or manufacturer. Then anyone with a main wheel of over 100 systems could quickly find any entry.

[nathan1974au]

ready for a new grave here!

i think this idea has gone! lol

[Hyperion]

Give the guy a break. If this is how all new FE projects are to be treated on the HyperSpin forums then we'll scare away all the well intended and enthuisiastic new blood. We have a rich and creative community here. Sure BBB started it, but the artists and coders that heard the call have made it great with themes, boxes, wheel art and the various third party applications like amazing RocketLauncher and HyperPause. Without the content that this community has created over the years HS would never have even made a splash.

I say let someone else have a crack at improving on the best frontend ever made and we will all stand to benefit. Especially as noble and altruistically founded as an opensource program that doesn't live or die by one persons efforts alone. One that all the coders that give a damn can build together to make it great. I keep bringing up XBMC as an analogous comparison but there's a reason why it has persisted so long and become so powerful. It's had both a thriving creative community and it's opensource.

Fly HyperCabrio, fly!!

[phulshof]

I would like the main menu xml to contain more info than just system names

instead of:

<game name="Nintendo Game Boy"/>

include more:

<game name="Nintendo Game Boy"/>

<manufacturer>Nintendo</manufacturer>

<year>1989</year>

<genre>Handheld</genre>

<generation>Fourth Generation</generation>

That way we could easily filter our main wheel by type of machine, release year, generation, or manufacturer. Then anyone with a main wheel of over 100 systems could quickly find any entry.

Such information would be needed for menu option 2, where the menu structure is generated automatically. For option 1, you can basically design your menu in any way you'd like.

The problem I have with designing too many filters is that it generally takes a keyboard or mouse to properly select them quickly or you'll spend more time changing your filter settings than it would take you to scroll to the right system.

[phulshof]

ready for a new grave here!

i think this idea has gone! lol

I've recently updated my own front-end for use on my own arcade/emulation setup, so I'm not starting out of the blue. Since I want the HS graphics available for my own system, I'm not too worried about this project going to the grave that quickly either. It just makes sense to me to work together with this community to get it right, and to work together with the Cabrio team to do the work once. There's too many half finished FEs out there already. I agree with Hyperion that what makes HS great is the work of this community, even though BBB provided the foundation to work from. That's why most FEs work with a list rather than a wheel: it's just way too much work to create all the required graphics by yourself.

[floatingyeti]

Such information would be needed for menu option 2, where the menu structure is generated automatically. For option 1, you can basically design your menu in any way you'd like.

The problem I have with designing too many filters is that it generally takes a keyboard or mouse to properly select them quickly or you'll spend more time changing your filter settings than it would take you to scroll to the right system.

Couldn't you make the Genre option available for the main menu? Then we could make any custom arrangement selectable from the Genre(Filter) menu. We couldn't alter the main menu on the fly but select a premade xml of handhelds, computers, consoles, arcade systems, chronological list of all systems, or manufacturer specific list.

[phulshof]

Couldn't you make the Genre option available for the main menu? Then we could make any custom arrangement selectable from the Genre(Filter) menu. We couldn't alter the main menu on the fly but select a premade xml of handhelds, computers, consoles, arcade systems, chronological list of all systems, or manufacturer specific list.

As said: when using option 1 for the menu structure, the user is in complete control over how he/she would like his/her menu structure to look like, including what you describe here. It's just a matter of creating the proper XML files, though that process could be automated via support tools. As mentioned in a previous post though: creating a common view with all the different graphics (e.g. box art for different systems) will be up to the user as well, and may not be an easy task.

[Fromlostdays]

creating a common view with all the different graphics (e.g. box art for different systems) will be up to the user as well, and may not be an easy task.

When its ready, post on the forum and it'll be 20 people uploading awesome sets to the FTP before you can finish typing.

Goodluck and godspeed on this, man. Somewhat odd feature request just to give some thought to it: Different user profiles. When I have friends over they aren't trying to play Tiger Game, for instance. So it would be cool if you could create different profiles that would call on different items in the main menu. That's sort of just an extension on all the previous talk about the main menu, but its a slightly different way reach the same end.

Thanks for all the hard work!

Walter

[Anpanman]

As said: when using option 1 for the menu structure, the user is in complete control over how he/she would like his/her menu structure to look like, including what you describe here. It's just a matter of creating the proper XML files, though that process could be automated via support tools. As mentioned in a previous post though: creating a common view with all the different graphics (e.g. box art for different systems) will be up to the user as well, and may not be an easy task.

IMO, i still think this is a worthy cause, even if its just to give a 1:1 parity HS compatible solution for linux users.

[suspendedhatch]

I would love to see this take off at the same time I would love to see HS progress. I have two identical machines already (free discards from my friend's work). One day these will probably be two different cabinets with two different front ends, HyperSpin and something that doesn't exist yet.

I loved that video of using 3D boxes to select games instead of wheels and lining them up on a shelf. What was that? That was a great example of something that makes a great and interesting alternative to HS but not necessarily a replacement for it.

It goes without saying that you should base it around HyperLaunch and HyperSync. There's no reason to start from scratch or for artwork to be frontend-specific.

[dark13]

The video was taken from a wii application http://sourceforge.net/projects/wiiflow.mirror/ (yeah, wii has a more advanced frontend than windows/linux...)

The fact is using hyperlaunch means you need less work while keeping compatibility with emulators already supported by .ahk modules.

As I said, mantaining hyperlaunch the whole thing reduces to a matter of moving stuff on the screen and and pass commands to hyperlaunch

[phulshof]

It goes without saying that you should base it around HyperLaunch and HyperSync. There's no reason to start from scratch or for artwork to be frontend-specific.

I do plan on looking at hooking it into HyperLaunch and HyperSync, but at the same time I have to consider Linux users as well. I'm already considering creating a HyperSync for Linux using the available API, but HyperLaunch for Linux is an entirely different ballgame.

What I'm also wondering about is file names. When I look at the PD repositories, for many systems I can only find the MESS software lists these days. Those names perfectly match the MESS naming convention (for which I can auto-generate XML files), but don't match the HS naming schemes (which match the HS XML files). For this front-end I'm wondering whether I'd want to follow the MESS naming scheme or the HS naming scheme. With more and more systems being supported by MESS, with auto-generation of the XML files being possible, there's something to be said for the MESS naming scheme. This however means a full renaming of the HS artwork. Any thoughts regarding this matter?

[Hyperion]

Could you elaborate on these two? I'm not quite sure how exactly you envision these.

By addon support I mean that third party addons/plugins can be more easily and seamlessly integrated into HyperCabrio in similar ways to XBMC addons.

[Hyperion]

I loved that video of using 3D boxes to select games instead of wheels and lining them up on a shelf. What was that? That was a great example of something that makes a great and interesting alternative to HS but not necessarily a replacement for it.

I hadn't thought of it as on a shelf before. I too was very impressed by those 3D boxes. I like your idea of the shelf. That would be a cool aesthetic. Kind of like the 3Darcade FE in that is mimics a real world space except much more practical. EDIT: Similar to Sony's cross media bar on the PS3 or HyperPause.

Example:

Different shelving units for each system.

A shelf for each letter within a system.

For a controller shoulder buttons would switch between shelving units (systems) and d-pad would navigate the shelves.

If you don't want to use the shoulder buttons you could just press up until you reach the system name above the numbers shelf EDIT: or press "back" (remember, individual shelves hold games in alphabetical order) and then press left and right to choose between systems.

Getting back to option 1 or 2 for the Main Menu, I would probably prefer option one as the default setup with the ability to filter if the the user chooses. But I understand that filters require extra embedded info which isn't that out of the question. The XMLs already have a variety of information in various levels of completion. To be honest, I wouldn't be that upset if I couldn't apply filters in that way but I wouldn't want to abandon a default file structure in favour for a purely filtered system. Am I correct in assuming that if I choose "filter by system" I would get basically the same file structure that HS currently uses? Albeit systems in either alphabetical or release year order instead of personal preference for collecting Nintendo, Sega, Sony etc separately.

[Aorin]

I do plan on looking at hooking it into HyperLaunch and HyperSync, but at the same time I have to consider Linux users as well. I'm already considering creating a HyperSync for Linux using the available API, but HyperLaunch for Linux is an entirely different ballgame.

What I'm also wondering about is file names. When I look at the PD repositories, for many systems I can only find the MESS software lists these days. Those names perfectly match the MESS naming convention (for which I can auto-generate XML files), but don't match the HS naming schemes (which match the HS XML files). For this front-end I'm wondering whether I'd want to follow the MESS naming scheme or the HS naming scheme. With more and more systems being supported by MESS, with auto-generation of the XML files being possible, there's something to be said for the MESS naming scheme. This however means a full renaming of the HS artwork. Any thoughts regarding this matter?

HS has lots of tools, not HS itself but, these tools can be used to batch rename artwork and videos, imo rename files won't be the major issue.

[brolly]

For this front-end I'm wondering whether I'd want to follow the MESS naming scheme or the HS naming scheme. With more and more systems being supported by MESS, with auto-generation of the XML files being possible, there's something to be said for the MESS naming scheme. This however means a full renaming of the HS artwork. Any thoughts regarding this matter?

I'm not sure why would a frontend need to follow any specific naming schema? That being said MESS naming schema is horrible, we are not in 1980 anymore. I like to look at my roms and know exactly what game is what. If you are thinking on supporting HyperLaunch you'll need to follow the HS (It's more HL than HS since for HS the rom names are irrelevant) or No-Intro naming schemas otherwise MultiGame support will never work.

Full auto generation of XML files won't be possible anyway, as dat files don't contain stuff like genres for instance.

[dark13]

If someone is planning to add infos to .xml can .csv creations (for photoshop variables batches) be considered? With photoshop variables you can easily batch .pngs infopanels.

BTW, maybe this is not the right place for this but If someone want to create an artwork layer with the infos contained in hyperspin's xml to match system's font instead of using hyperspin's info it could be done quite easily. On the FTP i've uploaded a java parser that reads hyperspin's xmls and create a .txt file usable in photoshop.

Ah... I dont' want to create another drama but I never get why HS xmls does not follow goodtools naming scheme. Problems with some special chars?

[nathan1974au]

i like where this is going