[Epsilonsama]

AerosolSP, on 03 December 2012 - 01:56 PM, said:

Some people just don't want to share their work. Sounds selfish but I can understand why someone wouldn't want to open source their project.

I don't get this line of thought. I mean, I understand if you want to make a profit of your work and you think the best way to do so is to keep your software proprietary. I don't agree with it but I certainly understand the motivation of software developers to do so. But if you are working on something that has no monetization involved I cant understand why don't you share your code with others. I mean its the right thing to do. Not only does the software benefits from it but you can do much more by making your code public than by letting it rot in your hard drive chained to your whim. Many times had a proprietary closed source project been lost because the developer's hard drive died or something. This rarely happens with free software because you tend to update your public repository more often more than one individual has a copy of your code.

[Aerosol]

Quote

...it's the right thing to do...

That sounds like entitlement to me.

This is someone's hard work. Maybe they don't want to just give it away?

[TmEE]

I say : "Don't like my way ? make your own !"

[Epsilonsama]

AerosolSP, on 04 December 2012 - 12:18 AM, said:

Quote

...it's the right thing to do...

That sounds like entitlement to me.

This is someone's hard work. Maybe they don't want to just give it away?

Quote

entitlement

That word.

But seriously, you are not giving away your work by making your software free. You are doing a great service to your users by letting them see the code and know the ins and out of your work. You turn a personal project into something more. Something that can grow and mature into something everybody can help build. A work that will live on beyond your lifetime. Thats the best kind of work IMO. I don't get why wouldn't you want this.

[Aerosol]

I understand all that. What you have to understand is some people don't want to give others all the answers to a problem. They worked hard on it and it's their solution. Still others are embarrassed of their shitty coding, and don't want it to be scrutinized. Still others may have reverse engineered code (or something else) that doesn't allow them to redistribute it under an open source license (this can especially true of emulators). There's many reasons why someone may choose not to open source their work.

[Hivebrain]

GerbilSoft, on 02 December 2012 - 05:39 PM, said:

Hence, the only way to handle this is to implement a database of "known-good" ROMs. (Either that, or require a special container format for ROMs with identifying information, but that's problematic.)

Actually, a special ROM format that contains extra hardware info seems like a good idea to me. You'd still use .bin for the majority of games. In what way would it be problematic?

[Flygon]

Hivebrain, on 11 December 2012 - 08:26 PM, said:

GerbilSoft, on 02 December 2012 - 05:39 PM, said:

Hence, the only way to handle this is to implement a database of "known-good" ROMs. (Either that, or require a special container format for ROMs with identifying information, but that's problematic.)

Actually, a special ROM format that contains extra hardware info seems like a good idea to me. You'd still use .bin for the majority of games. In what way would it be problematic?

Yes, but how do you ensure wide distribution and acceptance of the format? That's the question. I also consider backwards compatibility a potential issue (though, I could always see tacking on the info on the end of an otherwise standard .bin ROM working, compatibility-wise. Barring 4096kbyte games...).

[TmEE]

Appended metadata would work for most situations I believe

[ICEknight]

BSNES is already doing it without appending extra data to the ROMs or making up new formats, by using folders that include the needed ROMs, save data, a manifest XML for certain systems, and anything else that could be related to each cartridge.

I think is a nice idea, but I'd change a few things for it to be the "ultimate" and more standard cartridge/board-based format possible:

• Possibility of using compressed files rather than real folders (since they're basically the same thing, but handier).
  
• Besides the manifest.xml file that would tie everything together, I'd only include any stuff that came from the cartridge (any ROMs, battery saves, mapper info, specific schematics for copy protection, etc).
  
• Exclude any external stuff such as covers, cheats, etc, which would just bloat each game folder ad infinitum.
  
• When appliable, change the "program.rom" file, to the actual split ROMs with their respective names.
  
• Also rename the "save.rwm" to whatever the EEPROM is called in games that use it, etc.

I think MAME is doing it almost right except that it lacks an XML for each game, and rather relies on the emulator's own database.
If this system got widely implemented, we'd even be able to load the same Mega-Tech ROMs in both arcade and Genesis emus!

This post has been edited by ICEknight: 12 December 2012 - 10:09 AM

[Andlabs]

Your approach is more or less the MESS approach, though MAME/MESS do need to store the state in the emulator because they store so many diverse systems with different requirements (unless you want to start adding scripting language code to the ROM). The bsnes method is more suited to people who want to not only play games but also move the environemnt they play games around. Both approaches have their dvantages and disadvantages (the MAME approach more closely resembles the hardware, while the bsnes approach is easier for end users and hackers to work with).

I personally would not use XML as it is not a general-purpose data store format (despite being general enough to act as one), though I'm not sure how different markup is from data for this very specific case. JSON (a dedicated data format) would probably be a better choice.

In my honest opinon I would rather keep the flat folder of ROM approach for systmes like the Genesis where you only ever have one ROM when fully combined. Sonic & Knuckles is the only exception that I know if (unless Virtua Racing has an internal ROM for the DSP, but apparently that's not the case?). Why? I'm not entirely sure... partially because I ljust prefer things this way, partially to make handling ROM sets easier, partially to make searching ROMs for binary data easier. byuu does have a program which can automatically build a temporary bsnes ROM folder out of a flat ROM and store the etra data elsehwere, which also helps.


Also if you're going to make a manifest file, I'm not sure how far we can go without starting to introduce game-specific hacks (or having them placed in the emulator). The only real issue is Psy-O-Blade, which has a corrupt SRAM header; not sure how to handle that. 3MB games with SRAM would not be an issue (Phantasy Star IV and The Story of Thor would be explicitly specified as using a mapper; HardBall 95 would not).

This post has been edited by Andlabs: 12 December 2012 - 11:03 AM

[MathUser]

Speaking of emulator accuracy does anyone know a complete list of emulators compatible with Ultimate Mortal Kombat Trilogy? The list on the official site don't seem to be complete as they don't even list picodrive PSP.

[Oerg866]

Epsilonsama, on 02 December 2012 - 09:06 AM, said:

So I was wondering, is there an accurate Genesis/Mega Drive emulator akin to the SNES emulator BSNES? Bonus points if its an Open Source emulator because you can easily check if there's hacks to let certain games run.

No. Emuators right now are fine for playing games, but they SUCK (yes, every single one of them) for homebrew development.

AamirM may say regen is not OFFICIALLY discontinued, but I have low hopes at this point. It's the only decent debugging emulator out there (sans the crashes *sigh*).

This post has been edited by Oerg866: 13 December 2012 - 12:51 AM

[Meat Miracle]

For what its worth, Kega is not discontinued either, Steve is just busy with real life to work on it.

[Oerg866]

Actually no, Steve Snake has disappeared from everywhere.

[MathUser]

Are you guys actually suggesting Headers? Yes they'd be at the back but tampering with the ROM to make it work is not a good idea. It also screws up some patches at ROM hacking sites. Some patchers such as XDelta require the exact ROM to patch. If theres headered and unheadered ROM's then finding the right ROM could be a hassle. I suppose someone would create a tool to remove and add the headers but that'd be another step that alot of noobs that wanna use your patches won't know about. I know they wouldn't be called headers since they are at the end of the ROM but I don't know what else to call it.