/vr/ - Retro Games

Windows explorer

>>1305120
> manage and organize your collection of ten millions Roms of which you only play three

>>1305127
It's half about the convenience of having all the games available right when I need then, and half about collecting.
It's no different than people who collect thousands of games and never open their boxes. Some people just want to have things for the sake of having them, and there's nothing wrong with that either.

Explorer and 7zip

>>1305123
this, don't be lazy about it

Use a directory hierarchy.
Console manufacturer -> Generation -> System -> Studio (if you want to)

>>1305135
That's dumb, as if console manufacturers develop more than one console per generation or portables follow generation patterns.

>>1305135
I just use the organization the image sets came with and have a folder for every machine. No manufacturers and generations wouldn't really work for computers and the like anyway.

>>1305135
okay, fine. get rid of the generation directory, and just have a handheld directory or lump it into the manufacturer directories.

>>1305148
meant for >>1305139

>>1305146
>No manufacturers and generations wouldn't really work for computers and the like anyway.
organize by computer/OS then studios and series

>>1305151
Sort all my Amiga games by which Kickstart they need? I just got the whole set so that I don't have to download games I want to play individually.

My 16 bit Windows games are in my IBM DOS folder because I run Wiundows 3 in DOSBox and the folder is set up as C: there.

>>1305172
My Amiga images take freaking forever for the emulator I use on my Wii to list them. I should really break them down more than alphabetically.

Well, guess I'll just try and stick to RomCenter then.
Thanks for nothing.

>collecting roms

inb4 PSX/PS1 shitstorm

>>1305120
It's pretty easy.

Each folder breaks into emulator and rom/iso folders.

>>1305120
I downloaded a collection of ROMs for a few different systems (I got one for NES, SNES, and N64 which I'm pretty sure has every US ROM in it.), and from there I just made a folder called "Anon's Favorite ROMs" and copied the ones I play into it. For a while, I'll have to dig around in the big folder of ROMs, but after that I pretty much just replay the ones in my favorites folder.

On semi rare occasions, someone on this board will recommend or bring up something I've never played, and I'll have to dig it up and move it to my favorites folder. Sometimes I'll keep it there and play it once in a while, sometimes I'll just delete it after I finish. No sense in leaving it in a folder if I'm not going to play it again.

i use windows explorer

windows explorer

>>1305214
>implying anyone gives a shit what you name your folders

If you're looking for something more presentable than explorer and if you've got the bandwidth/time/harddrive space, download that 90GB "HyperSpin Project - The Frontend" torrent. Install HyperSpin from the website, ignore all the files in the torrent except for the Media folder (where the videos and game logos are), and dump it into your HyperSpin directory. Looks nice and requires minimal configuration. You can favorite ROMs from within the frontend and filter to show only those, too.

Also for some reason the guy who made that torrent included all the mame videos twice, you can delete all the ones that are in the alphabetically-named subfolders in media\mame\videos. Saves like 10GB.

I use DBGL for DOSBox games.
For everything else, I just keep them in folders.

>>1305123

rom-jacket for windows 7&8.
http://code.google.com/p/rom-jacket

A folder that holds everything. Organized as you see fit. I'm not going to recommend a file structure to use because it will lead to an autism war.

game folders

>>1307016
>recommend a file structure

There was a really good discussion on /vg/ about that not too long ago. Let me see if I can dig it up.

>>1307016
Here:

http://archive.foolz.us/vg/thread/55486227/#55819737

A standardized file system structure -- the libretro of ROMs

>>1307087
I cant tell if this is sarcasm or you agreeing with the man

>>1307161
I agree with him. It was a good discussion. The guy managed to defuse the usual "byuugeyman" accusations somehow.

Even what appears to be mudlord agreed with him, even though he didn't seem interested in implementing something like that himself

>be playing
>figure everything out
>bitch ass judge gives me ultimatum
>YEAH I FUCKING HAVE EVIDENCE
>it doesn't work
>maximum over wat
>get #rekt trying to come up with alternative theories on the fly
>turns out I had to say I couldn't prove it so that Mia could come in and do it for me

Fuck this shit.

>2014
>not just putting a /roms/ folder inside each emulator folder to maximize organization and portability

>>1307178
wrong thread m8

>>1307198
>people can't have more than one emulator for each system
>being this fully retarded

>>1307210
>not installing both emulators to the same folder

>>1307227
>Only having 2 emulators

>>1307227
>mixing the files of two different programs in a single folder
>retard levels off the charts
>beyond the impossible

>>1307198
>Not simply pointing any and all emulators towards C:\Games\Roms\ and organizing games by manufacturer and console.

>>1307254
Why would you nest consoles under manufacturers? That's one extra click for literally no gain.

>>1307691
because pointlessly nested folders are fun if you have OCD

>>1307739
Consoles imply a manufacturer/developer. There is no need to be redundant. Unless you're fucking autistic.

>>1307227
>2 programs installed to the same directory

>>1307739
That's why I also include sub-folders of genre, year, and studio.

>>1307820
>games can only be of 1 genre
>what is filesystem tags

I just put them roms inside each console folder and that's it.

fuck that organized shit

>>1307828
But that's the only sane way of organizing it.

>>1307828

This.

>>1307825
>Not keeping a copy in each applicable genre.

>>1307853
>wasting space for literally no reason

>>1305120
>use
Nothing. I did it once and will never have to do it again.

Or did you mean "used"? Think it was Bash but anything that lets you create a directory called roms and ones under it with console names and then extract your archive to those will do just fine.

Or you can use a retarded directory structure like this guy >>1305135

>>1307860
>not writing a script to parse dat files and manage/checksum your rom library for you

>>1307864
This is what most people do, and the exploded archives are often unsuitable for display/consumption in a frontend.
>>1307860
This is NOT what most people do. Writing software and using dat-tools are WAY beyond what most people want to do to play games.

>>1307943
I think you got the quotes reversed.

>exploded archives are often unsuitable for display/consumption in a frontend

Do you think the stuff proposed in >>1307093 would be reasonable format for frontends/tools to consume?

That seemed to be the entire point of discussion

>>1307974
I agree. The ROM as it exists to the developer is often a very different animal from how it is seen in a zoo.
>>1307210
...yes...
>>1307178
WHAT
THE
FUCK

>>1308005
>The ROM as it exists to the developer is often a very different animal from how it is seen in a zoo.

.. What.

>>1308010
making a rom, and knowing how it looks on a development side is completely different than what the player sees. You really this dumb?

>>1308016
making a rom? development side?

It's just a file. That's exactly how emulators and players see the rom

>>1308023
ROMs are not just plain files. Try making a rom hack and you will see what I mean.

>>1308025
>ROMs are not just plain files

How so? You talking about headers or things like that?

>>1308025
>ROMs are not just plain files
A ROM image is a literal dump of every byte in the game ROM, which is typically mapped directly into the CPU address space in the console. It's as plain as you can get.

>>1308030
I'm talking the coding of a ROM vs playing the rom. The programing side is different from the player view.

>>1308027
>A ROM image is a literal dump of every byte in the game ROM
Yes that is true if you are extracting the image off the game cart or something. In that situation a ROM is just like a disk image ISO file. But if you are making a rom image from scratch the actual programing (making of the bytes) is not "as plain as you can get"


Look at this as an example.
>http://www.loirak.com/gameboy/gbatutor.php
What the developer(s) sees is nothing like the player or copier will see after the initial program is compiled. Developers don't just give away the code for the games, someone has to rip then and even then what they rip is different from what the programer saw

>>1308047
Dude, no one gives a shit. Why are you talking about this?

>>1308047
>The programing side is different from the player view.
I don't understand. The player doesn't ever look at the ROM. They stick it in the CPU's address space (whether by a cartridge or by a emulator's file picker) and let the CPU start executing.

>>1308047
Am I being rused? Surely nobody could be this retarded.

>>1308047
>But if you are making a rom image from scratch the actual programing (making of the bytes) is not "as plain as you can get"
Yes, it is. I usually instruct GCC not to bother with a standard library, I have LD output a raw binary file, I write the linker script myself to be as simple as possible, etc, etc. There's no headers or file sections like in an ELF or PE executable.

>>1308047
Uh, I'm a developer. What the fuck does source code have to do with anything? Players don't store fucking source code in their ROM libraries. They store ROM files, ips patches or bdiffs.

That's like saying "the executables people run are different from the source code files devs work with before they are compiled". So what? Nobody cares.

Also, you suck at quoting.

>>1308048
because >>1308005
made a comment that >>1308010
did not understand. Just explaining it for him.


>>1308058
suck my dick

All you niggaz getting trolled now. Just stop while you can. He clearly has no idea what he is saying

>>1308060
I didn't understand because you suck at getting your point across, and when you finally do, it turns out to have literally no relevancy to what we were discussing about.

>>1308064
You realize that
>>1308005
>>1308016
are different people right?
The point still stands the initial thing that started the shitstorm was irrelevant to the thread

>>1308030
A ROM dump can often be in a multitude of formats. Cover-art and other metadata for the rom may exist for the title, but not the region/version/dump.
It would make sense to isolate the rom and contain it with all available data pertaining to it as it exists as a title simply because the source is not necessarily what you want (pal/ntsc/jap), but what is available.

>>1308085
What. Cover art is not part of the ROM. Anything but a copy of the contents of the ROM chip in the cartridge is not part of the ROM.

>>1308085
"ROM dump" is not the appropriate term for anything but the literal contents of the ROM.

>>1308104
>>1308108
ROMs as they exist for the dumper should not be mistaken for what they are generally considered to be by the average player.
MAME's romset is a perfect example of why.
The contents of a title vary from dump to dump. Metadata (artwork & other assets) are integral components as identifiers and execution paramaters, This information is usually only needed by a fronend but the elements are unique to the rom and the emulator/frontend.

>>1308169
Jesus and I thought I was autistic

So what is the point here? A GUI to organize all your ROMs for you that can translate to emulators? You trying to get a database together that would store any relevant metadate? (CRC, ini seeting, etc.).

I haven't dealth with most of this recent stuff you guys are mentioning with unified emulators, but a lot of it sounds similar to MAME's front end, hopefully with an organized file structure as opposed to a million "click to add another folder of stuff".

>>1308169
I'm... not sure you understand the concept of a ROM.

>>1308170
Can you stop?.

>>1308169
are you >>1308047 ?

No one was originally talking about what a ROM was.

>>1308172
>hopefully with an organized file structure as opposed to a million "click to add another folder of stuff".

This is what this guy was proposing:

http://archive.foolz.us/vg/thread/55486227/#55819737

He said something about writing up and publishing a spec.

>>1308176
Deal with it, nerd.

>>1308179
Yeah, which would be great.

I see people linking RoM-Jacket and talking about RetroArch or whatever emulator does anything similar to organize your games, both of which I haven't tried yet.

Taking off of byuu's idea of making correct categorization in the file structure for each game, it would be amazing if it could work across emulators and all they would need to do is use something that lets them interface with this new GUI/database (or just the newly organized file layout).

Would be great if the program could just be pointed toward a game file, incorporate it into the borg file organization while comparing CRCs to verify what game it is, and be used by everything.

>>1308195
Yeah, that'd be nice as fuck. If emus supported the library file system structure, they'd be able to do away with the entire notion of a file system or rom files.

Retro Arch would present you with a "library" menu. You click it and get a list of games for your currently loaded core. Retro Arch gets that list by simply listing the contents of the folder. You select the game you want and it loads your settings and everything. It also detects patches and shows them as a list so you can choose which settings to apply.

Since this is structured so that the emulator could consume the library, then it follows that some other program would be able to generate the library, no?

With something awesome like the datomatic hash databases, you can make a program that takes an arbitrary file, figures out everything about the ROM by hashing it and pulling the info out of the database, and puts it in the appropriate folder.

Though, the beauty of all this is that you can maintain the folder yourself. It seems quite simple in structure, and easy to navigate.

Honestly I'm hooked. Why didn't byuu think of this shit?

>>1308170
>>1308182
>>spergelicious. Thanks Penn. Take your bullshit elsewhere.
>>1308172
well, it would be nice to have a spec that frontends can use to parse a library of titles. Consolidating dats with a _friendly_ tag for the parent-title is a chore.
Personally, I don't care if I'm playing the pal or ntsc version. I don't care if it's the brazillian version with japanese voices.
I do care that when I load up the frontend, it displays as "MVSC2(pal)[!]7z" with no artwork and not "Marvel vs Capcom 2 - New Age of Heroes" with a picture of the box.

>>1308235
Does such artwork even exist for other systems? Are there sets of perfectly scanned artwork of boxes and manuals and other feelies for snes/genesis/ps1 games?

>>1308240
Boxes? Go to Gamefaqs. I seem to recommend that place a lot these days. Do people not go there anymore? I'm not angry or anything, just curious.

Manuals? Replacementdocs, though your mileage may vary. Some scans are good, while others or not.

>>1308243
>pdfs

They are unsuitable for display by a front end. A serially-numbered collection of png images would be ideal for that purpose.

>>1308240
Preservation is getting better. There are some *cough* hyperspin/emumovies *cough* commercial options for content, but you can use adv.launcher/rcb for xbmc to scrape your library and it gets some high-quality stuff for most titles.
*cough* Gamebrowser *cough* for Mediabrowser/WMC can also scrape metadata.

>>1308265
Where do these front ends pull these images from?

>>1308269
They usually have a centralized database, which is why they cost money.

>>1308259
>>pdfs
Its unreasonable to expect a manual archive to be converted to png sequences. Frontend development should account for the pdf format, and until then these assets are stuck in filesystem-land.

>>1308297
It's unreasonable to convert image scans to pdf in the first place.

>>1308269
adv.launcher/rcb for xbmc pull images from quite a few different sources. These are free.
>>1308275
the content provided by hyperspin/emumovies is HIGH QUALITY and in some cases not just scans, but complete recreations.
It's pretty cheap to join hyperspin. The guy who runs emumovies thinks he has the right to control the distribution of his "creations" though. Can't shill for that fucker.

>>1308312
>The guy who runs emumovies thinks he has the right to control the distribution of his "creations" though.

He sounds like a faggot. Why hasn't anyone made a torrent of their local copies?

>>1308316
would be fucking huge. Even the new one in .mp4 format

>>1305214
Wow! Never seen a roms folder with so few systems.

Not trying to be negative, but can someone explain why you might need a rom manager program?

I've always ran with explorer by: game system/games/roms in alphabetical order
systems with cds have another folder: game system/games/individual game folders
emus are in: game system/emulator name

is it about storing/displaying boxart? wii has several loaders that render boxart in 3d, and you can move them around and even zoom to read the fine print. I know someone mentioned hyperspin, but that's a bit too extreme with all the videos in my opinion.

>>1308867
I've always assumed they're for people who have emulation oriented media centers or cabinets set up.

It doesn't seem like something that is immediately useful to me personally but I certainly understand wanting good presentation if you have one of the prior set up in a highly visible manner.

Mine looks like this. CD based systems, I don't really archive I just download for on a game-by-game basis.

>>1308867
A "game folder"-like setup gives you clear advantages even as a PC emulator end user. It'd enhance integration between your library and the emulator, enabling autodetection, application of game-specific settings, cheat lists, sharing of sram data between different emulators, etc.

>>1308867
Same reason any media ever has had any front-end GUI that browses the library of content. Come on, dude, time to use that brain.

>>1305120
windows.

>>1309000
>no sonic 3 complete

http://info.sonicretro.org/Sonic_3_Complete_(hack)

get it faggot

>>1305135
i just have a roms folder
>nes
>snes
>genesis
>sms
>neogeo
>gbc
etc

RetroArch

>>1309127

>>1309000
I like this. Do you have a program that can batch convert images en-masse to large vista+ compatible icons?
>>1309083
Most ppl have this. The problem with that is that the emulator controls and maintains everything from settings to saves. It's preferrable to allow each game to retain this data.
>>1308867
That is super sexy. The big 3 put a lot of effort into their fe's.