remove CoreForcingViaGameDb user option.

[adelikat]

We should not give the user the ability to turn this off. If they are power users and want to overwrite our db, they can mod the db entries

[nattthebear]

595a207 is the originating commit

[nattthebear]

595a207 is the originating commit

@zeromus had a differnet idea of how this would work out originally, judging by the comments there. We do put these values in the gamedb and don't just leave it to the end user; maybe his idea was that pure blacklisting should use a different method?

[adelikat]

He was commenting on the fact that quicknes has it's own internal blacklist, which isn't ideal I suppose

[zeromus]

According to my comments we DID have a separate blacklisting method.
At the time of my commit, this option was barely needed -- probably I only added it as an emergency measure in case someone needed it. If we DO manually specify cores now, then it is MORE needed than it was at the time of this commit, since there is automatic behaviour the user might want to cancel.
That said, if you are okay with power users having to hack the gamedb to remove the core-forcing, then this isn't needed.
But I wonder

1. what happened to the separate blacklisting method
2. Remember, at the time of this commit, we may have had more complicated game dbs (else what is dbman for?) If any gamedb is not plain text, then asking users to edit it is a big ask

[adelikat]

1. We still do have a blacklist, in quicknes and only quicknes
2. gamedb is still text based. Dbman is either used by devs to create these db files or not at all. The original idea died out. Also it is an external tool with APIHawk now
3. I'm completely okay with users needing to edit gamedb. When we override it is for a good reason. In most cases the game does not work in said core, or works badly. When it's bad they report it, instead of try a different core. We are very much in the game of trying to make out of the box work as well as possible. It's a power user move to override our decisions.

[adelikat]

4. we are using this option more now. We have a few games we run in picoDrive instead of GPGX. We still have some neshawk vs quicknes (despite quicknes having a hardcoded black list), and snes9x vs bsnes. More will inevitably arise

[YoshiRulz]

Diff looks good. I think as we're adding more cores, it's important that the gamedb is okay with added/removed cores even if no-one remembers to update it. Maybe every rom loads with the most accurate core without flags, common roms get a "fast" flag (and the front-end decides what "fast" means), and the core name overrides are replaced with mapper- or peripheral-based overrides?

[adelikat]

I think we have to simply remember to fix the gamedb if cores are removed.
It isn't so easy to use vague description of the core like "fast" or "acccurate". Our overrides with pico for instance. Pico isn't faster, it is the less accurate core probably but that's unclear, and it just happens to run a few games better than gpgx.

mapper is a nice thing to focus on but doesn't solve the problem entirely, sometimes a core just doesn't get a game right, but not specifically due to a mapper.

These are nice ideas but I think some entries just have to be the core name.