bsnes/higan/target-higan/settings/settings.cpp

113 lines
2.9 KiB
C++
Raw Normal View History

Update to v106r21 release. byuu says: Changelog: - higan: target-tomoko has been renamed to target-higan - Super Famicom: event has been renamed to processor(architecture=uPD78214) - Super Famicom: SNES-EVENT supported once more; under board IDs EVENT-CC92 and EVENT-PF94 - Super Famicom: SNES-EVENT preliminarily set up to use DIP switch settings ala the Nintendo Super System (incomplete) - Super Famicom: MCC PSRAM moved inside the MCU, as it is remappable - Super Famicom: MCC emulation rewritten from scratch; it is now vastly more accurate than before - Super Famicom: added BSC-1A5B9P-01 board definition to database; corrected BS-MCC-RAM board definition - Super Famicom: moved SHVC-LN3B-01 RAM outside of processor(identifier=SDD1) - higan: when selecting a default game to load for a new system entry, it will change the system option to match the media type - higan: the load text box on the system entry window is now editable; can be used to erase entries - icarus: fixed bug in Famicom importing - icarus: importing unappended SNES coprocessor firmware will now rename the firmware properly - hiro/GTK,Qt: WM_CLASS is now set correctly in `argv[0]`, so applications should show “higan”, “icarus” instead of “hiro” now Note: if you wish to run the BS-X town cartridge, the database currently lists the download RAM as type “PSRAM”. This needs to be changed to “RAM” in order to load properly. Otherwise, the emulator will bomb out on the load window, because BSC-1A5B9P-01 expects PSRAM to always be present, but it won't find it with the wrong memory type. I'll correct this in the database in a later release. For now, you can copy the game portion of the manifest to a new manifest.bml file and drop it into the gamepak folder until I fix the database.
2018-05-17 03:37:29 +00:00
#include "../higan.hpp"
Update to v106r15 release. byuu says: Changelog: - Super Game Boy: fixed loading of boot ROM - hiro: added ComboEdit::setEditable(bool = true); - tomoko: added new systems settings panel Note!!: this release will not compile on Windows or macOS due to the missing ComboEdit control! I'll try to merge in hex's implementation for the Windows release here soon. macOS users will probably be out of luck for a while, sorry. The new systems panel is an idea I've been meaning to implement for quite a while, but finally got around to starting on it. It's still fairly unpolished, but the basic idea is there for Linux/BSD users to try out now. So imagine the Super Game Boy, BS-X Satellaview, Sufami Turbo, and the associated BS Memory Pack-slotted SNES cartridges. To play any of those, you needed to choose Nintendo→Super Famicom, and then select the relevant cartridge, and then select any slotted cartridges to play with it. This was acceptable-ish, if not ideal. But now imagine in the future if we wanted to support the Famicom Disk System, which is technically a cartridge that plugs into the Famicom deck. Or the PC Engine CD, which has one of three special HuCards that must be inserted (ignoring the Turbo Duo where it's built-in—I'm going to be emulating the Super CD as if you're using a stock PCE CD.) Or the Mega CD, where there are probably a half dozen or more BIOS + hardware revisions that are region-specific, which connect to an expansion port that is identical to the cartridge port save for the Mega Drive seeing an I/O register bit toggled here. In all of these cases, it's going to be a real pain to have to choose the 'BIOS' every time you want to play a game for them. I can't distribute these BIOSes with higan due to copyright restrictions, and trying to ship dummy folders for every possible combination would become quite odious, and difficult for people to use (compare to setting up the Game Boy Advance system BIOS.) And so I've created the new systems settings panel. Here, you can manage a list of systems that show up under the higan library menu (now renamed to “System”), where each entry contains name, boot, and hidden parameters. The name parameter is what shows up in the system menu. You can call any system higan emulates whatever you like here. Don't like “Super Famicom”? Change it to “SNES”, then. The boot parameter is a combo edit with a dropdown for all of the systems higan emulates. If you choose one of these, then the higan system menu option will work exactly like in previous releases, and prompt you for a cartridge. But if you choose the browse button next to the combo edit control, you'll get to pick any gamepak from the higan library of your choosing. So you could choose the SGB2 BIOS, and name the menu option “Super Game Boy 2”, and when you choose the menu option, it will load the SFC core, load the SGB2 BIOS, and only prompt you for the Game Boy game you wish to play on it. The same deal goes for the FDS, PCE-CD, Mega CD, Mega Drive Sonic & Knuckles lock-on cartridge, BS-X Satellaview, SD Gundam G-Next, etc. Whatever you want to be in the menu, you can put in there by pointing higan at the appropriate 'BIOS' gamepak to load. Astute readers have probably already noticed, but you can technically use this on non-slotted games as well, thus creating instant boot options for your absolute favorite games, if you so wanted. Point it at Zelda 3, and you can boot it instantly from the main menu, without any need for file selection. The hidden option is a way to hide the system entries from the system menu. Primarily this would be a fast way for users to disable emulation cores they never use in higan, without having to remove the options. The major concession with this change is the collapsing of the per-manufacturer submenus. What this means is you will now have all twelve higan emulated systems in the main menu by default. This makes the list rather long, but ... oh well. I may try to offer some form of grouping in the future, but the grouping defeats the “list order = display order” design, and I'm not willing to auto-sort the list. I want people to be able to control the ordering of the system menu, and have added (as yet non-functional) sorting arrows for that purpose. I also don't have a combined tree+table view widget in higan to try to and group things. But ... we'll see how things go in the future. Another idea is to add a specialty load option that opens up the user's Emulation library path, and lets you pick a gamepak for any system, which would boot the same way as when you drop a gamepak onto the higan executable or main window. So say you almost never play Wonderswan games, this would be a way to play them without them cluttering your system menu list. The “import ROM files” option has been removed. All it does is launch icarus directly. I would rather users become familiar with using icarus. The “load ROM file” option remains. Anyway, this is all still a work in progress, so please give it time and don't overload me with too many suggested changes right now, thanks :3
2018-04-16 08:58:13 +00:00
#include "system-properties.cpp"
#include "systems.cpp"
Update to v094r23 release. byuu says: The library window is gone, and replaced with hiro::BrowserWindow::openFolder(). This gives navigation capabilities to game loading, and it also completes our slotted cart selection code. As an added bonus, it's less code this way, too. I also set the window size to consistent sizes between all emulated systems, so that switching between SFC and GB don't cause the window size to keep changing, and so that the scaling size is consistent (eg at normal scale, GB @ 3x is closer to SNES @ 2x.) This means black borders in GB/GBA mode, but it doesn't look that bad, and it's not like many people ever use these modes anyway. Finally, added the placeholder tabs for video, audio and timing. I don't intend to add the timing calculator code to v095 (it might be better as a separate tool), but I'll add the ability to set video/audio rates, at least. Glitch 1: despite selecting the first item in the BrowserDialog list, if you press enter when the window appears, it doesn't activate the item until you press an arrow key first. Glitch 2: in Game Boy mode, if you set the 4x window size, it's not honoring the full requested height because the viewport is smaller than the window. 8+ years of trying to get GTK+ and Qt to simply set the god damned window size I ask for, and I still can't get them to do it reliably. Remaining issues: - finish configuration panels (video, audio, timing) - fix ruby driver compilation on Windows - add DIP switch selection window (NSS) [I may end up punting this one to v096]
2015-05-30 11:39:09 +00:00
#include "video.cpp"
#include "audio.cpp"
#include "input.cpp"
#include "hotkeys.cpp"
Update to v094r12 release. byuu says: Changelog: * added driver selection * added video scale + aspect correction settings * added A/V sync + audio mute settings * added configuration file * fixed compilation bugs under Windows and Linux * fixed window sizing * removed HSU1 * the system menu stays as "System", because "Game Boy Advance" was too long a string for the smallest scale size * some more stuff You guys probably won't be ecstatic about the video sizing options, but it's basically your choice of 1x, 2x or 4x scale with optional aspect correction. 3x was intentionally skipped because it looks horrible on hires SNES games. The window is resized and recentered upon loading games. The window doesn't resize otherwise. I never really liked the way v094 always left you with black screen areas and left you with off-centered window positions. I might go ahead and add the pseudo-fullscreen toggle that will jump into 4x mode (respecting your aspect setting.) Short-term: * add input port changing support * add other input types (mouse-based, etc) * add save states * add cheat codes * add timing configuration (video/audio sync) * add hotkeys (single state) We can probably do a new release once the short-term items are completed. Long-term: * add slotted cart loader (SGB, BSX, ST) * add DIP switch selection window (NSS) * add cheat code database * add state manager * add overscan masking Not planned: * video color adjustments (will allow emulated color vs raw color; but no more sliders) * pixel shaders * ananke integration (will need to make a command-line version to get my games in) * fancy audio adjustment controls (resampler, latency, volume) * input focus settings * relocating game library (not hard, just don't feel like it) * localization support (not enough users) * window geometry memory * anything else not in higan v094
2015-03-03 10:14:49 +00:00
#include "advanced.cpp"
Settings settings;
unique_pointer<SettingsManager> settingsManager;
unique_pointer<SystemProperties> systemProperties;
Settings::Settings() {
Markup::Node::operator=(BML::unserialize(string::read(locate("settings.bml"))));
auto set = [&](const string& name, const string& value) {
//create node and set to default value only if it does not already exist
if(!operator[](name)) operator()(name).setValue(value);
};
set("UserInterface/ShowStatusBar", true);
set("Library/Location", {Path::user(), "Emulation/"});
set("Library/IgnoreManifests", false);
set("Video/Driver", ruby::Video::safestDriver());
set("Video/Synchronize", false);
set("Video/Shader", "Blur");
set("Video/BlurEmulation", true);
set("Video/ColorEmulation", true);
set("Video/ScanlineEmulation", false);
set("Video/Saturation", 100);
set("Video/Gamma", 100);
set("Video/Luminance", 100);
set("Video/Overscan/Horizontal", 0);
set("Video/Overscan/Vertical", 0);
set("Video/Windowed/AspectCorrection", true);
set("Video/Windowed/IntegralScaling", true);
set("Video/Windowed/Adaptive", true);
set("Video/Windowed/Scale", "Small");
set("Video/Windowed/Scale/Small", "640x480");
set("Video/Windowed/Scale/Medium", "960x720");
set("Video/Windowed/Scale/Large", "1280x960");
set("Video/Fullscreen/AspectCorrection", true);
set("Video/Fullscreen/IntegralScaling", true);
set("Video/Fullscreen/Exclusive", false);
set("Audio/Driver", ruby::Audio::safestDriver());
set("Audio/Device", "");
set("Audio/Frequency", 48000);
set("Audio/Latency", 0);
set("Audio/Exclusive", false);
set("Audio/Synchronize", true);
set("Audio/Mute", false);
set("Audio/Volume", 100);
set("Audio/Balance", 50);
set("Audio/Reverb/Enable", false);
set("Input/Driver", ruby::Input::safestDriver());
set("Input/Frequency", 5);
set("Input/Defocus", "Pause");
set("Emulation/AutoSaveMemory/Enable", true);
set("Emulation/AutoSaveMemory/Interval", 30);
set("Systems", "");
set("Crashed", false);
}
auto Settings::save() -> void {
file::write(locate("settings.bml"), BML::serialize(*this));
}
//
SettingsManager::SettingsManager() {
settingsManager = this;
layout.setMargin(5);
Update to v094r43 release. byuu says: Updated to compile with all of the new hiro changes. My next step is to write up hiro API documentation, and move the API from alpha (constantly changing) to beta (rarely changing), in preparation for the first stable release (backward-compatible changes only.) Added "--fullscreen" command-line option. I like this over a configuration file option. Lets you use the emulator in both modes without having to modify the config file each time. Also enhanced the command-line game loading. You can now use any of these methods: higan /path/to/game-folder.sfc higan /path/to/game-folder.sfc/ higan /path/to/game-folder.sfc/program.rom The idea is to support launchers that insist on loading files only. Technically, the file can be any name (manifest.bml also works); the only criteria is that the file actually exists and is a file, and not a directory. This is a requirement to support the first version (a directory lacking the trailing / identifier), because I don't want my nall::string class to query the file system to determine if the string is an actual existing file or directory for its pathname() / dirname() functions. Anyway, every game folder I've made so far has program.rom, and that's very unlikely to change, so this should be fine. Now, of course, if you drop a regular "game.sfc" file on the emulator, it won't even try to load it, unless it's in a folder that ends in .fc, .sfc, etc. In which case, it'll bail out immediately by being unable to produce a manifest for what is obviously not really a game folder.
2015-08-30 02:08:26 +00:00
statusBar.setFont(Font().setBold());
setTitle("Settings");
setSize({600, 405});
setAlignment({0.0, 1.0});
Update to v103r13 release. byuu says: Changelog: - gb/interface: fix Game Boy Color extension to be "gbc" and not "gb" [hex\_usr] - ms/interface: move Master System hardware controls below controller ports - sfc/ppu: improve latching behavior of BGnHOFS registers (not hardware verified) [AWJ] - tomoko/input: rework port/device mapping to support non-sequential ports and devices¹ - todo: should add move() to inputDevice.mappings.append and inputPort.devices.append - note: there's a weird GCC 4.9 bug with brace initialization of InputEmulator; have to assign each field separately - tomoko: all windows sans the main presentation window can be dismissed with the escape key - icarus: the single file selection dialog ("Load ROM Image...") can be dismissed with the escape key - tomoko: do not pause emulation when FocusLoss/Pause is set during exclusive fullscreen mode - hiro/(windows,gtk,qt): implemented Window::setDismissable() function (missing from cocoa port, sorry) - nall/string: fixed printing of largest possible negative numbers (eg `INT_MIN`) [Sintendo] - only took eight months! :D ¹: When I tried to move the Master System hardware port below the controller ports, I ran into a world of pain. The input settings list expects every item in the `InputEmulator<InputPort<InputDevice<InputMapping>>>>` arrays to be populated with valid results. But these would be sparsely populated based on the port and device IDs from inside higan. And that is done so that the Interface::inputPoll can have O(1) lookup of ports and devices. This worked because all the port and device IDs were sequential (they left no gaps in the maps upon creating the lists.) Unfortunately by changing the expectation of port ID to how it appears in the list, inputs would not poll correctly. By leaving them alone and just moving Hardware to the third position, the Game Gear would be missing port IDs of 0 and 1 (the controller ports of the Master System). Even by trying to make separate MasterSystemHardware and GameGearHardware ports, things still fractured when the devices were no longer contigious. I got pretty sick of this and just decided to give up on O(1) port/device lookup, and moved to O(n) lookup. It only knocked the framerate down by maybe one frame per second, enough to be in the margin of error. Inputs aren't polled *that* often for loops that usually terminate after 1-2 cycles to be too detrimental to performance. So the new input system now allows non-sequential port and device IDs. Remember that I killed input IDs a while back. There's never any reason for those to need IDs ... it was easier to just order the inputs in the order you want to see them in the user interface. So the input lookup is still O(1). Only now, everything's safer and I return a maybe<InputMapping&>, and won't crash out the program trying to use a mapping that isn't found for some reason. Errata: the escape key isn't working on the browser/message dialogs on Windows, because of course nothing can ever just be easy and work for me. If anyone else wouldn't mind looking into that, I'd greatly appreciate it. Having the `WM_KEYDOWN` test inside the main `Application_sharedProc`, it seems to not respond to the escape key on modal dialogs. If I put the `WM_KEYDOWN` test in the main window proc, then it doesn't seem to get called for `VK_ESCAPE` at all, and doesn't get called period for modal windows. So I'm at a loss and it's past 4AM here >_>
2017-07-12 08:24:27 +00:00
setDismissable();
onSize([&] {
input.mappingList.resizeColumns();
hotkeys.mappingList.resizeColumns();
});
}
auto SettingsManager::setVisible(bool visible) -> SettingsManager& {
if(visible) {
input.refreshMappings();
hotkeys.refreshMappings();
}
Window::setVisible(visible);
return *this;
}
auto SettingsManager::show(uint setting) -> void {
panel.item(setting)->setSelected();
setVisible();
setFocused();
doSize();
}