A new Hyperspin?

[phulshof]

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.

For option 1, you could create any structure you want in any order you want. For option 2, you could indeed select 1 criteria: system, and you'd get the current HS setup. Adding an order parameter to that might be a good idea, allowing alphabetical or release year or ... As it stands right now, I'm leaning towards creating option 1 first, and adding option 2 at a later time. Simply a matter of using option 1 to create the database from which a new menu structure can be generated on the fly.

[phulshof]

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.

Well, it's not so much that the frontend follows a naming scheme, but the frontend does need to match up the emulator call (with the game name), the rom file, the artwork file(s), etc. Anything other than name matching is usually too slow for run-time handling. Add in the different (merged) packed formats, and some naming scheme must be followed. As such, the names in the XML file should somehow match up to the other files, whether that's the name or the description is up for grabs (so using a full name like you want to see is not a problem).

As a Linux user, I use MESS for most of my non-arcade emulation. The PD repositories for this use the MESS naming scheme; the HS XML and artwork files do not. In addition, those repositories come as merged or unmerged .7z files, which cannot be called directly from MESS; in stead I call MESS using the game name, and MESS figures out where to find the rom files. So either I unpack and rename the rom files, and use the HS naming scheme, or I have to use MESS (auto-)generated XML files, and rename the HS artwork.

So that's where my question about naming schemes comes from: the names of the different parts need to match up to the XML file in some way, and I haven't quite figured out yet how best to go about this problem.

[brolly]

In Windows HyperLaunch can handle all that for you, in Linux that's a whole different story since you'll have to code your own launchers, but you can always rely to rom mapping files if you need to.

Barely any emulator requires the roms to have specific names though, it's mostly arcade ones like MAME and HS XMLs are already named properly on those cases. For MESS you only need to use the MESS rom names if you are launching the games through softlists which is only required for a very small number of systems.

So the naming schema isn't a big deal. Supporting a specific rom set only which is where you seem to be going towards is a bad idea especially since MESS software lists are far from complete for many systems. Plus you aren't going to be using MESS for most of the common systems anyway since there are usually better emulators available.

[phulshof]

In Windows HyperLaunch can handle all that for you, in Linux that's a whole different story since you'll have to code your own launchers, but you can always rely to rom mapping files if you need to.

Barely any emulator requires the roms to have specific names though, it's mostly arcade ones like MAME and HS XMLs are already named properly on those cases. For MESS you only need to use the MESS rom names if you are launching the games through softlists which is only required for a very small number of systems.

So the naming schema isn't a big deal. Supporting a specific rom set only which is where you seem to be going towards is a bad idea especially since MESS software lists are far from complete for many systems. Plus you aren't going to be using MESS for most of the common systems anyway since there are usually better emulators available.

I'm not sure I completely understand. I was under the impression that the rom and art names for HS followed the naming scheme defined in the HS XML files; is this incorrect? If incorrect, how does HS match the artwork to the current game, and define the game name or rom file with which it launches the game? If correct, the names should match, which means that if the available repositories do not, the files need to be renamed somehow. I understand there are many tools for Windows for this purpose, but I'm not quite sure if this is also the case for Linux. The same goes for emulators for that matter; MESS is quickly pulling up to or ahead of other Linux emulators for many systems.

It's not so much that I want to support a specific naming scheme as that I want to make it easy for people to get a complete set of artwork and rom files for the systems they want supported without having to spend a lot of work trying to figure out how to get it together. PD offers repositories for the MESS software lists; I'm not sure if they offer repositories for all systems using the HS XML naming scheme. From what I read, getting your HS fully up and running can take quite a bit of work.

Edit: I did a quick PD hop over, and found the HS repositories there. I'll see how well they work together with MESS, and work my way from there. That way I can use the HS XML files (possibly extended with new features in the future?), and not have to worry about matching it up with the HS artwork. I'll let you know how it works out for me.

[brolly]

Yes, artwork needs to be named after the XML names of course, but is it your intention to create your own artwork repositories as well? I didn't understand you were.

Because if you aren't and intend to leave up to the users to pick their artwork from somewhere else I think the HS naming schema is the way to go, because this is the best artwork repository for frontends available anywhere. Not sure if you were referring to artwork when you mentioned PD offered repositories for MESS, but if that's the case I suggest you to have a better look at the MESS artwork packs, because they are far from being useful on any frontend that want to excel graphically. So artwork wise HS naming is your best option.

Getting HS fully up and running is a piece of cake once you know how it works and assuming you have all the needed artwork of course, there are plenty of tools to assist you with the renaming part.

Like I said you'll have no issues using any rom set with MESS except for some very particular cases that might require launching through software lists.

[phulshof]

I just got my platinum membership and my EmuMovies membership yesterday, so I'll spend a bit of time getting a small HS system up and running so I know what I'm aiming for.

The documentation link on this website is still dead; is there documentation to be found anywhere? I'd hate to have to reverse engineer everything.

[brolly]

I think the old site got deleted when the FTP servers were moved and this is where the documentation was, not sure if a copy of it has been kept somewhere. This should be asked to the persons currently administering the website. I always thought it was a bad idea to not get the docs moved to this forum.

[nathan1974au]

instead of making a front-end why not an operating system?

linux is open source why not rip apart system then merging

[Guest SirCyranotwo]

Hello, please read my thread, important about Sir Cyrano copyright Boxes

http://www.hyperspin-fe.com/forum/showthread.php?38146-Sir-Cyrano-no-allow-use-his-3D-boxes-until-Baddeolv-clear-the-BAN&p=356535#post356535

[phulshof]

instead of making a front-end why not an operating system?

linux is open source why not rip apart system then merging

Well, we do actually have plans to create a minimized Linux distribution with this front-end as well, but we'd better focus on building the front-end first. Such a distro could be run as live system from a USB, CD or DVD or could be installed on a HD.

[Aorin]

It would be really something, having a frontend We.could open in any environment, even on Android, ios, etc, Just like retroarch and many other emulators does

[juniorunderground]

Hello, please read my thread, important about Sir Cyrano copyright Boxes

http://www.hyperspin-fe.com/forum/showthread.php?38146-Sir-Cyrano-no-allow-use-his-3D-boxes-until-Baddeolv-clear-the-BAN&p=356535#post356535

[baddeolv]

Har har har. Funny guy here.

[DamnedRegistrations]

Could you please not ban content contributors? Even if they tick you off, just delete their posts or warn them if needed. The last thing we need is less help around here and Cyrano has been making some great new box sets.

[baddeolv]

Could you please not ban content contributors? Even if they tick you off, just delete their posts or warn them if needed. The last thing we need is less help around here and Cyrano has been making some great new box sets.

It was a 3 day ban, that backfired when the auto ban lift failed to work. I already apologized in his other thread. To answer your question, no. We can't let members slander each other just because they are contributing. I made the super admins aware of the situation and they trusted that I made the right call. Cyrano was reinstated this morning btw

[brolly]

@junior: Lol

[nathan1974au]

Well, we do actually have plans to create a minimized Linux distribution with this front-end as well, but we'd better focus on building the front-end first. Such a distro could be run as live system from a USB, CD or DVD or could be installed on a HD.

sounds fully sick!

front-end first first then rip apart a linux distro getting rid of the junk

that would work.

[phulshof]

In Windows HyperLaunch can handle all that for you, in Linux that's a whole different story since you'll have to code your own launchers, but you can always rely to rom mapping files if you need to.

Barely any emulator requires the roms to have specific names though, it's mostly arcade ones like MAME and HS XMLs are already named properly on those cases. For MESS you only need to use the MESS rom names if you are launching the games through softlists which is only required for a very small number of systems.

I just did a few small tests with the PD HS repository for cart systems, but it's not very hopeful. Take Amidar for the Atari 2600 for example:

The rom file is called Amidar (USA).7z.

MESS can't be called with that file directly, since it doesn't understand (no idea why not) that a direct rom call may be packed. That leaves the following options:

1. Rename it to amidar.7z, and call it with mess a2600 -cart amidar, but then it doesn't match the HS XML.

2. Unpack it, and call it with mess a2600 -cart Amidar (USA).bin, but that means I need 2 copies: the .7z to update the torrent without downloading everything again, and the .bin to run the emulator.

Neither seems like an ideal situation to me. How does HS solve this issue? Is this handled by HyperLaunch?

[brolly]

Yeah it's handled by HyperLaunch enabling 7z support, the rom is extracted to a temp folder before launching and that's what's fed to the emulator. There are plenty (most of them actually) emulators that don't support 7z files directly so this is a pretty common feature to use if you want to keep your roms 7z compressed.

Never realized you couldn't send the 7z file directly to MESS (I keep all my roms uncompressed), after all MESS do support 7z files. So that's a very odd behavior, what if you compress it to .zip. will it work?

[phulshof]

Yeah it's handled by HyperLaunch enabling 7z support, the rom is extracted to a temp folder before launching and that's what's fed to the emulator. There are plenty (most of them actually) emulators that don't support 7z files directly so this is a pretty common feature to use if you want to keep your roms 7z compressed.

Never realized you couldn't send the 7z file directly to MESS (I keep all my roms uncompressed), after all MESS do support 7z files. So that's a very odd behavior, what if you compress it to .zip. will it work?

Yes, that will actually work. For .7z I get:

phulshof@SpaceballsM:~$ mess a2600 -cart ./Amidar\ \(USA\).7z

FATALERROR: Device Atari VCS 2600 Cartridge Slot load (./Amidar (USA).7z) failed: Internal error

phulshof@SpaceballsM:~$ mess a2600 -cart ./Amidar\ \(USA\).zip

simply launches MESS with the proper game.

Odd, very odd. Oh well, guess I'll have a chat with the other programmers on how we'll deal with this issue. That, and have a chat with the MESS programmers on why this doesn't work.

[brolly]

I figured it would work, guess they forgot to add support for this since 7z support wasn't added until much more recently

Make a post in the MESS boards and I'm sure this will get fixed, probably no one realized the problem so far.

[phulshof]

I figured it would work, guess they forgot to add support for this since 7z support wasn't added until much more recently

Make a post in the MESS boards and I'm sure this will get fixed, probably no one realized the problem so far.

Already done. They were pretty quick to solve my previous problem too, although that may have been since I'd already found the source code correction they needed to do in order to fix it.

[suspendedhatch]

Yeah then BBB resurrected in the other thread and everyone was on his ass, haha.

[phulshof]

Yeah then BBB resurrected in the other thread and everyone was on his ass, haha.

Why would his return matter in this regard? Hyperspin for Linux is still not going to happen, so my main reason for wanting to write this frontend stll stands.

I'm happy that he's back. Hopefully HS 2.0 will see the light of day, but if life intervenes again I can still make this one cross-platform. Who knows; perhaps there's even room to cooperate, and share the workload.

[Styphelus]

Why would his return matter in this regard? Hyperspin for Linux is still not going to happen, so my main reason for wanting to write this frontend stll stands.

I'm happy that he's back. Hopefully HS 2.0 will see the light of day, but if life intervenes again I can still make this one cross-platform. Who knows; perhaps there's even room to cooperate, and share the workload.

Why do you need to have hyperspin on Linux? By doing that you are depriving yourself of a lot of good PC games and as far as I'm aware, some of the emulators are not available on Linux either. Why not just get another hard drive and have windows on it? Seems like a lot of work for nothing.