DSD, better alternative to compatible lists & settings t

[Zerothis]

Someone somewhere has perhaps stumbled across an emulator and settings that work for a certain game on their system. They should have the option of automatically sharing this information on a decentralized peer-to-peer network. Emulators could offer the option of automatically accepting settings from this network, and/or provide manual selection to the end-user. Running successfully on certain setting would automatically generate a good rating for it in the database. Users could also manually rate it for graphics, sound, speed, playability, completeness. Instant compatibility and settings lists with minimal effort and no liability for emulator others and maintainers of their official webpages. The P2P could use existing networks and clients, no need to create a new one. All thats required is to establish as standard for how to name the files and their format. XML is versatile and extensible.

Name of file is automatically generated from the data within it so it is uniquely named. Extention: .DSD.XML or .DSD
Unique ID
Emulator Title
Emulator Version
Game/Software CRC/MD5
Game/Software Title
Game/Software Type (GAME/GAME UTILITY/DEMO/SOFTWARE)
Host Operating System
Host Operating System version
CPU name
CPU speed
Video card
Video card driver
Video API (DirectX/OpenGL)
Sound card
Sound card driver
Sound API
Emulator
Emulator settings/config file
Plugings
Plugin Settings
Network (Y/N/Protocol)
Network Settings
Controller/Joystick 1
Controller/Joystick 2
Controller/Joystick 3
Controller/Joystick 4
Cheat/Hack 1
Cheat/Hack 2
Cheat/Hack 3
Cheat/Hack 4
Related Library & Version 1 (DLL/SO, things like sdl 1.2, vbrun300, pygame 1.9.1)
Related Library & Version 2
Related Library & Version 3
Related Library & Version 4
User notes


A separate tracker to keep the ratings for each file based on automatic report of the emulator plus user ratings. It keeps a weighted average for:
emu-runs? [Y/N] {percentage} (automatically rated by emulator)
emu-anyerrors? [Y/N] {percentage} (emulator)
user-runs? [Y/N] {percentage} (user votes)
beatable [Y/N] {percentage} (user votes)
graphics [1-10] (user votes)
sound [1-10] (user votes)
speed [1-10] (user votes)
playability [1-10] (user votes)
completeness [1-10] (user votes) are features missing





- Zerothis

[Deathlike2]

Short answer: No.

Better solution: Make a frontend that does it.

[Zerothis]

Short answer: No.

Better solution: Make a frontend that does it.

But how would one get the emulator itself to cooperate in sending back info?

Each emulator would need its own front-end and unique coding. Many would be left out. As opposed to a universal standard built into each one. Front-ends could be use for emulators that did not integrate DSD.

Universal DSD would both free the developers from maintaining compatibility lists and provide them with one. It also would provide them with other useful information used to improve the emulator. A front-end, if done by a 3rd party, is a barrier between developers and this information.

[Deathlike2]

But how would one get the emulator itself to cooperate in sending back info?

It doesn't. The frontend would handle this, not the emu.

Each emulator would need its own front-end and unique coding.

That's why putting it into an emu is massive fail. The frontend would need to determine the different emus and versions, probably using a hash to determine if they are the same version.

It also would provide them with other useful information used to improve the emulator.

How? When you know the deficiencies of the emulator (in terms of emulation), the common issues and threads come up over time and can be easily searched through the boards. It is not as if this info was hidden from society unless you have no clue how to use Google and/or the ZSNES board search feature.

A front-end, if done by a 3rd party, is a barrier between developers and this information.

The problem as you fail to see is that the developers have to maintain it, which is not very interesting in itself. With a slow release schedule that ZSNES has had, you're waiting for Doomsday.

[byuu]

If a game isn't compatible, the emulator needs to be fixed. We have emulators with 100% compatibility on many systems now.

If there is a hardware or driver issue, that has nothing to do with the emulator and hardware driver settings (eg Direct3D or DirectDraw?) aren't very helpful, as that bug probably only exists on that one unique complete system.

I don't see a point for this. Now do something like this for N64 or newer where you need 40 different plugins and there are 90+ settings in each one that affect which games are compatible, and you have a real winner.

[Deathlike2]

This would be better managed by a frontend though. The information has to be centralized... so it makes no sense to use it in a peer-to-peer sense. If you're going to collect all this info, it has to be made known in a more visible sense (aka Pokemon). Otherwise, it's not very useful other than to people you know... which isn't even a useful or reliable sample size.

[grinvader]

Now do something like this for N64

time better spent on a real n64 emulator that would reduce the need for that feature to jack



same with any plugin-based emu

[Zerothis]

If a game isn't compatible, the emulator needs to be fixed.
For example:
emu-runs = %9 would tend to suggest to the developers that the emu needs fixing to run the game
emu-runs = %98 would suggest the to the developers that a minority of the users need fixing. Probably no need to fix the emulator, nothing to indicate its broken.

If there is a hardware or driver issue, that has nothing to do with the emulator

Exactly, if a certain hardware of driver is not allowing the game to run:
1. Users find out via the tracker rather than harassing the developers about something that is not their problem and that they cannot fix.
2. Rather than wasting time on an issue, developers find out via the tracker about something that is not their problem and that they cannot fix.

Hardware driver settings (eg Direct3D or DirectDraw?) aren't very helpful, as that bug probably only exists on that one unique complete system.

To developers, this is not that useful. Its more helpful to the users. But keep in mind, If the users see from tracker that their unique system is the problem, they are not as likely to be harassing developers.

I don't see a point for this. Now do something like this for N64 or newer where you need 40 different plugins and there are 90+ settings in each one that affect which games are compatible, and you have a real winner.

Correct. It is less useful for established and simpler emulators. But, what happens when newer computers, software, and operating system are not compatible with the established and simpler emulator? The tracker can tell the developers what software they are using, if said software is not compatible with their emulator, and how many people it effects (ie: do we want to create an update for 15 people when the other 112,456 people aren't having a problem?)

Something developers should understand about this idea. In its current form, it is without a doubt, of more benefit to emulator users than developers. However, there is no reason developers cannot insert their own data into the dsd files to track whatever info they believe will help them make the emulator better. Just because it is a universal standard does not remove the possibility of emulator, or even game specific data being stored in it. Especially if it is in XML format. The extra data would simply be ignored by emulators/clients that had no use for it.

The information has to be centralized... so it makes no sense to use it in a peer-to-peer sense.

If every copy of the emulator is broadcasting its data, isn't there enough there for a sufficient sample?
The P2P part is to protect the projects from legal issues. Remember that napster did not store music files, did not copy music files, did not transfer music files. Yet they were found to be aiding copyright infringement. Again, this is less useful for some projects.

[paulguy]

I don't think a compatibility list would be much of a problem legally... there are likely plenty all over the internet as it is.

Anyway, this might be more useful as more of an online game database with maybe some screenshots, information, description, maybe some play statistics, etc... though there's really no reason that this couldn't reasonably just frontend to wikipedia or something. :p

As for game or system specific settings, it's just not worth it at all. compatibility is extremely high on older system emulators to the point where emulator choice is just a matter of preference. Also, computer system specific problems are relatively rare (though they do crop up from time to time, but that's really no different than any other large, complex piece of software.) and just cataloging all the possible different system configurations and trying to attribute problems to certain aspects of a configuration would be near impossible and just impractical. That'd be much more efficient from a user and developer point of view to be handled with google or searching the developer website or forums.

[franpa]

Can ZSNES use a configuration file specified by a command line parameter? If yes then the frontend can just have multiple config files for each game and load ZSNES with the appropriate commands.

I believe DOSBox does something just like that and thats how front ends for it work.