byuu wrote:Hmm, okay how about this?
Brightness / Contrast / Gamma leave "adjust" off, but display the numbers more like they were meant to: eg show %, 100 = "100%", 5 = "5%", etc. 100% = center = no adjustment. We can also modify the centered text to say "Normal" for all of these, if you'd prefer.
Frequency Skew <-???, ... None, ... +???>
Well, if you block extremities from being chosen, it would be 5-95% with 50% in the middle. I was going to suggest percentages, but my knowledge here is lacking on how the intervals for each can be accurately reflected. For example, I was afraid the real range for gamma was 0-infinity. (I always see people choosing subjective ends, 0-4.0, 0-2.0, etc.) Enlighten me here if a percentage scale can accurately reflect each option.
There's also hue, saturation and tone(?) settings ... but if I offer those, I'd rather they be available to all filters and done through the color table. Not too convinced of their usefulness, but it'd help calibrate to YUV / YIQ TV colors definitely.
The only invaluable option in that entire section is overload's gamma curve, everything else about the image can be destroyed in my video driver or monitor settings. If you keep these and add more, I fear my final suggestions won't even have the room to be possible without you adding branches in the selection area.
Lastly, there's signal quality settings. There's some nice quick presets for quality level: RGB, S-video, composite, RF, etc. Might be nicer to offer that as a drop-down rather than a bunch of sliders.
Wouldn't these just be hardware filters like NTSC that simulate the lossy characteristics of certain type of analog output?
Base processor? Obviously an SNES emulator would internally contain the S-CPU, S-SMP, etc.
....
It would certainly be nice if we could separate the cart co-processors from the emulator, it's just not practical like it is with cart mapping.
There's no fundamental difference between a coprocessor and central processor in the scheme of emulation. That the coprocessor happened to be located on what we would physically categorize as the "cartridge" is immaterial. Emulation only concerns itself with operation, when the parts all interact as a whole. Thus there is nothing "dirty" about not having as separate files from the emulator. It's silly, we may as well be talking about a controller format, too.
Cart mapping info ... I think it'd be easier to have a PCB list inside the emulator so that you only have to say "cart A uses SHVC-FOO-BAR", but that creates a rather inflexible emulator that can't handle any cart.
By externalizing the mapping info, we allow for any conceivable mapping.
Nice for things like new beta dumps or ROM hacking when you need more than 48mbits of storage.
You're right - it couldn't support endless hypothetical hardware that never existed. But you're wrong that beta dumps wouldn't be supported. Most beta boards used official prototype boards, not random-ass manufacturer boards with no name that plagued the NES. Remember, with an external db, detection is externalized to a documented board, the equivalent of a documented (dumped) rom. If the beta board was documented, it works.
Still very possible to run those hacks on hardware using devices like the Game Doctors, or through PCB mods ala d4s' fan-made carts. Very nice because supporting new titles doesn't require a new emulator release. Also very nice because I don't have to manually specify 40+ PCB maps inside the emulator directly.
First of all, most hacks used licensed board mappings. But my argument should have convinced you that that's exactly what you should do. The only imaginary mappings that would be practical enough to support (Star Ocean uncompressed upon request for RE efforts) would be so small in number that internal support would be easy and preferable. You'd be crazy to externalize all your code just to allow people to create imaginary 10ft boards with 2ghz GPUs. It's not SNES development to invent endless "what if" extensions 20 years later that are 1000x slower than coding for modern hardware directly. This is a useless feature that is going to make it 100x more annoying for normal people to use an accurate mapper system.
And realistically, no SNES emulator in at least the next ten years will be able to exist without a cart header parsing backup mechanism.
It's obvious that this is a desirable backup method since we lack complete documention. If no board is documented in the xml for the detected checksum, then the backup method is used. It's that simple, and it could be adopted by every user immediately. It requires no additional work or knowledge by the user. I could have a complete draft with all of my current documentation included in a month.
Ask d4s why he writes new games for the SNES, or ROM hackers who make completely new games through old titles (eg Dragoon X Omega). Personally, I like the portability.
They're all using licensed hardware supported by the emulator, they're immaterial to argument. You can develop a game for SHVC-1A3M-11, make an entry in the xml, and it will work. You could even put all your custom entries under a new sheet in the same xml file for better organization and faster carryover.