bsnes/higan/target-tomoko/input/hotkeys.cpp

108 lines
2.8 KiB
C++
Raw Normal View History

auto InputManager::appendHotkeys() -> void {
Update to v103r08 release. byuu says: Changelog: - emulator: improved aspect correction accuracy by using floating-point calculations - emulator: added videoCrop() function, extended videoSize() to take cropping parameters¹ - tomoko: the overscan masking function will now actually resize the viewport² - gba/cpu: fixed two-cycle delay on triggering DMAs; not running DMAs when the CPU is stopped - md/vdp: center video when overscan is disabled - pce/vce: resize video output from 1140x240 to 1120x240 - tomoko: resize window scaling from 326x240 to 320x240 - tomoko: changed save slot naming and status bar messages to indicate quick states vs managed states - tomoko: added increment/decrement quick state hotkeys - tomoko: save/load quick state hotkeys now save to slots 1-5 instead of always to 0 - tomoko: increased overscan range from 0-16 to 0-24 (in case you want to mask the Master System to 240x192) ¹: the idea here was to decouple raw pixels from overscan masking. Overscan was actually horrifically broken before. The Famicom outputs at 256x240, the Super Famicom at 512x480, and the Mega Drive at 1280x480. Before, a horizontal overscan mask of 8 would not reduce the Super Famicom or Mega Drive by nearly as much as the Famicom. WIth the new videoCrop() function, the internals of pixel size distortions can be handled by each individual core. ²: furthermore, by taking optional cropping information in videoSize(), games can scale even larger into the viewport window. So for example, before the Super Famicom could only scale to 1536x1440. But by cropping the vertical resolution by 6 (228p effectively, still more than NTSC can even show), I can now scale to 1792x1596. And wiht aspect correction, that becomes a perfect 8:7 ratio of 2048x1596, giving me perfectly crisp pixels without linear interpolation being required. Errata: for some reason, when I save a new managed state with the SFC core, the default description is being set to a string of what looks to be hex numbers. I found the cause ... I'll fix this in the next release. Note: I'd also like to hide the "find codes..." button if cheats.bml isn't present, as well as update the SMP TEST register comment from smp/timing.cpp
2017-07-05 05:44:15 +00:00
static int quickStateSlot = 1;
{ auto hotkey = new InputHotkey;
hotkey->name = "Toggle Fullscreen";
hotkey->press = [] {
presentation->toggleFullScreen();
};
hotkeys.append(hotkey);
}
{ auto hotkey = new InputHotkey;
hotkey->name = "Toggle Mouse Capture";
hotkey->press = [] {
input->acquired() ? input->release() : input->acquire();
};
hotkeys.append(hotkey);
}
{ auto hotkey = new InputHotkey;
Update to v103r08 release. byuu says: Changelog: - emulator: improved aspect correction accuracy by using floating-point calculations - emulator: added videoCrop() function, extended videoSize() to take cropping parameters¹ - tomoko: the overscan masking function will now actually resize the viewport² - gba/cpu: fixed two-cycle delay on triggering DMAs; not running DMAs when the CPU is stopped - md/vdp: center video when overscan is disabled - pce/vce: resize video output from 1140x240 to 1120x240 - tomoko: resize window scaling from 326x240 to 320x240 - tomoko: changed save slot naming and status bar messages to indicate quick states vs managed states - tomoko: added increment/decrement quick state hotkeys - tomoko: save/load quick state hotkeys now save to slots 1-5 instead of always to 0 - tomoko: increased overscan range from 0-16 to 0-24 (in case you want to mask the Master System to 240x192) ¹: the idea here was to decouple raw pixels from overscan masking. Overscan was actually horrifically broken before. The Famicom outputs at 256x240, the Super Famicom at 512x480, and the Mega Drive at 1280x480. Before, a horizontal overscan mask of 8 would not reduce the Super Famicom or Mega Drive by nearly as much as the Famicom. WIth the new videoCrop() function, the internals of pixel size distortions can be handled by each individual core. ²: furthermore, by taking optional cropping information in videoSize(), games can scale even larger into the viewport window. So for example, before the Super Famicom could only scale to 1536x1440. But by cropping the vertical resolution by 6 (228p effectively, still more than NTSC can even show), I can now scale to 1792x1596. And wiht aspect correction, that becomes a perfect 8:7 ratio of 2048x1596, giving me perfectly crisp pixels without linear interpolation being required. Errata: for some reason, when I save a new managed state with the SFC core, the default description is being set to a string of what looks to be hex numbers. I found the cause ... I'll fix this in the next release. Note: I'd also like to hide the "find codes..." button if cheats.bml isn't present, as well as update the SMP TEST register comment from smp/timing.cpp
2017-07-05 05:44:15 +00:00
hotkey->name = "Save Quick State";
hotkey->press = [] {
Update to v103r08 release. byuu says: Changelog: - emulator: improved aspect correction accuracy by using floating-point calculations - emulator: added videoCrop() function, extended videoSize() to take cropping parameters¹ - tomoko: the overscan masking function will now actually resize the viewport² - gba/cpu: fixed two-cycle delay on triggering DMAs; not running DMAs when the CPU is stopped - md/vdp: center video when overscan is disabled - pce/vce: resize video output from 1140x240 to 1120x240 - tomoko: resize window scaling from 326x240 to 320x240 - tomoko: changed save slot naming and status bar messages to indicate quick states vs managed states - tomoko: added increment/decrement quick state hotkeys - tomoko: save/load quick state hotkeys now save to slots 1-5 instead of always to 0 - tomoko: increased overscan range from 0-16 to 0-24 (in case you want to mask the Master System to 240x192) ¹: the idea here was to decouple raw pixels from overscan masking. Overscan was actually horrifically broken before. The Famicom outputs at 256x240, the Super Famicom at 512x480, and the Mega Drive at 1280x480. Before, a horizontal overscan mask of 8 would not reduce the Super Famicom or Mega Drive by nearly as much as the Famicom. WIth the new videoCrop() function, the internals of pixel size distortions can be handled by each individual core. ²: furthermore, by taking optional cropping information in videoSize(), games can scale even larger into the viewport window. So for example, before the Super Famicom could only scale to 1536x1440. But by cropping the vertical resolution by 6 (228p effectively, still more than NTSC can even show), I can now scale to 1792x1596. And wiht aspect correction, that becomes a perfect 8:7 ratio of 2048x1596, giving me perfectly crisp pixels without linear interpolation being required. Errata: for some reason, when I save a new managed state with the SFC core, the default description is being set to a string of what looks to be hex numbers. I found the cause ... I'll fix this in the next release. Note: I'd also like to hide the "find codes..." button if cheats.bml isn't present, as well as update the SMP TEST register comment from smp/timing.cpp
2017-07-05 05:44:15 +00:00
program->saveState(quickStateSlot);
};
hotkeys.append(hotkey);
}
{ auto hotkey = new InputHotkey;
Update to v103r08 release. byuu says: Changelog: - emulator: improved aspect correction accuracy by using floating-point calculations - emulator: added videoCrop() function, extended videoSize() to take cropping parameters¹ - tomoko: the overscan masking function will now actually resize the viewport² - gba/cpu: fixed two-cycle delay on triggering DMAs; not running DMAs when the CPU is stopped - md/vdp: center video when overscan is disabled - pce/vce: resize video output from 1140x240 to 1120x240 - tomoko: resize window scaling from 326x240 to 320x240 - tomoko: changed save slot naming and status bar messages to indicate quick states vs managed states - tomoko: added increment/decrement quick state hotkeys - tomoko: save/load quick state hotkeys now save to slots 1-5 instead of always to 0 - tomoko: increased overscan range from 0-16 to 0-24 (in case you want to mask the Master System to 240x192) ¹: the idea here was to decouple raw pixels from overscan masking. Overscan was actually horrifically broken before. The Famicom outputs at 256x240, the Super Famicom at 512x480, and the Mega Drive at 1280x480. Before, a horizontal overscan mask of 8 would not reduce the Super Famicom or Mega Drive by nearly as much as the Famicom. WIth the new videoCrop() function, the internals of pixel size distortions can be handled by each individual core. ²: furthermore, by taking optional cropping information in videoSize(), games can scale even larger into the viewport window. So for example, before the Super Famicom could only scale to 1536x1440. But by cropping the vertical resolution by 6 (228p effectively, still more than NTSC can even show), I can now scale to 1792x1596. And wiht aspect correction, that becomes a perfect 8:7 ratio of 2048x1596, giving me perfectly crisp pixels without linear interpolation being required. Errata: for some reason, when I save a new managed state with the SFC core, the default description is being set to a string of what looks to be hex numbers. I found the cause ... I'll fix this in the next release. Note: I'd also like to hide the "find codes..." button if cheats.bml isn't present, as well as update the SMP TEST register comment from smp/timing.cpp
2017-07-05 05:44:15 +00:00
hotkey->name = "Load Quick State";
hotkey->press = [&] {
program->loadState(quickStateSlot);
};
hotkeys.append(hotkey);
}
{ auto hotkey = new InputHotkey;
hotkey->name = "Decrement Quick State";
hotkey->press = [&] {
if(--quickStateSlot < 1) quickStateSlot = 5;
program->showMessage({"Selected quick slot ", quickStateSlot});
};
hotkeys.append(hotkey);
}
{ auto hotkey = new InputHotkey;
hotkey->name = "Increment Quick State";
hotkey->press = [&] {
if(++quickStateSlot > 5) quickStateSlot = 1;
program->showMessage({"Selected quick slot ", quickStateSlot});
};
hotkeys.append(hotkey);
}
{ auto hotkey = new InputHotkey;
hotkey->name = "Pause Emulation";
hotkey->press = [] {
program->pause = !program->pause;
};
hotkeys.append(hotkey);
}
{ auto hotkey = new InputHotkey;
hotkey->name = "Fast Forward";
hotkey->press = [] {
video->set(Video::Synchronize, false);
audio->set(Audio::Synchronize, false);
};
hotkey->release = [] {
video->set(Video::Synchronize, settings["Video/Synchronize"].boolean());
audio->set(Audio::Synchronize, settings["Audio/Synchronize"].boolean());
};
hotkeys.append(hotkey);
}
{ auto hotkey = new InputHotkey;
hotkey->name = "Power Cycle";
hotkey->press = [] {
program->powerCycle();
};
hotkeys.append(hotkey);
}
Update to v102r22 release. byuu says: Changelog: - higan: Emulator::Interface::videoSize() renamed to videoResolution() - higan: Emulator::Interface::rtcsync() renamed to rtcSynchronize() - higan: added video display rotation support to Video - GBA: substantially improved audio mixing - fixed bug with FIFO 50%/100% volume setting - now properly using SOUNDBIAS amplitude to control output frequencies - reduced quantization noise - corrected relative volumes between PSG and FIFO channels - both PSG and FIFO values cached based on amplitude; resulting in cleaner PCM samples - treating PSG volume=3 as 200% volume instead of 0% volume now (unverified: to match mGBA) - GBA: properly initialize ALL CPU state; including the vital prefetch.wait=1 (fixes Classic NES series games) - GBA: added video rotation with automatic key translation support - PCE: reduced output resolution scalar from 285x242 to 285x240 - the extra two scanlines won't be visible on most TVs; and they make all other cores look worse - this is because all other cores output at 240p or less; so they were all receiving black bars in windowed mode - tomoko: added "Rotate Display" hotkey setting - tomoko: changed hotkey multi-key logic to OR instead of AND - left support for flipping it back inside the core; for those so inclined; by uncommenting one line in input.hpp - tomoko: when choosing Settings→Configuration, it will automatically select the currently loaded system - for instance, if you're playing a Game Gear game, it'll take you to the Game Gear input settings - if no games are loaded, it will take you to the hotkeys panel instead - WS(C): merged "Hardware-Vertical", "Hardware-Horizontal" controls into combined "Hardware" - WS(C): converted rotation support from being inside the core to using Emulator::Video - this lets WS(C) video content scale larger now that it's not bounded by a 224x224 square box - WS(C): added automatic key rotation support - WS(C): removed emulator "Rotate" key (use the general hotkey instead; I recommend F8 for this) - nall: added serializer support for nall::Boolean (boolean) types - although I will probably prefer the usage of uint1 in most cases
2017-06-08 14:05:48 +00:00
{ auto hotkey = new InputHotkey;
hotkey->name = "Rotate Display";
hotkey->press = [] {
program->rotateDisplay();
};
hotkeys.append(hotkey);
}
for(auto& hotkey : hotkeys) {
hotkey->path = string{"Hotkey/", hotkey->name}.replace(" ", "");
hotkey->assignment = settings(hotkey->path).text();
hotkey->bind();
}
}
auto InputManager::pollHotkeys() -> void {
Update to v100r16 release. byuu says: (Windows users may need to include <sys/time.h> at the top of nall/chrono.hpp, not sure.) Unchangelog: - forgot to add the Scheduler clock=0 fix because I have the memory of a goldfish Changelog: - new icarus database with nine additional games - hiro(GTK,Qt) won't constantly write its settings.bml file to disk anymore - added latency simulator for fun (settings.bml => Input/Latency in milliseconds) So the last one ... I wanted to test out nall::chrono, and I was also thinking that by polling every emulated frame, it's pretty wasteful when you are using Fast Forward and hitting 200+fps. As I've said before, calls to ruby::input::poll are not cheap. So to get around this, I added a limiter so that if you called the hardware poll function within N milliseconds, it'll return without doing any actual work. And indeed, that increases my framerate of Zelda 3 uncapped from 133fps to 142fps. Yay. But it's not a "real" speedup, as it only helps you when you exceed 100% speed (theoretically, you'd need to crack 300% speed since the game itself will poll at 16ms at 100% speed, but yet it sped up Zelda 3, so who am I to complain?) I threw the latency value into the settings file. It should be 16, but I set it to 5 since that was the lowest before it started negatively impacting uncapped speeds. You're wasting your time and CPU cycles setting it lower than 5, but if people like placebo effects it might work. Maybe I should let it be a signed integer so people can set it to -16 and think it's actually faster :P (I'm only joking. I took out the 96000hz audio placebo effect as well. Not really into psychological tricks anymore.) But yeah seriously, I didn't do this to start this discussion again for the billionth time. Please don't go there. And please don't tell me this WIP has higher/lower latency than before. I don't want to hear it. The only reason I bring it up is for the fun part that is worth discussing: put up or shut up time on how sensitive you are to latency! You can set the value above 5 to see how games feel. I personally can't really tell a difference until about 50. And I can't be 100% confident it's worse until about 75. But ... when I set it to 150, games become "extra difficult" ... the higher it goes, the worse it gets :D For this WIP, I've left no upper limit cap. I'll probably set a cap of something like 500ms or 1000ms for the official release. Need to balance user error/trolling with enjoyability. I'll think about it. [...] Now, what I worry about is stupid people seeing it and thinking it's an "added latency" setting, as if anyone would intentionally make things worse by default. This is a limiter. So if 5ms have passed since the game last polled, and that will be the case 99.9% of the time in games, the next poll will happen just in time, immediately when the game polls the inputs. Thus, a value below 1/<framerate>ms is not only pointless, if you go too low it will ruin your fast forward max speeds. I did say I didn't want to resort to placebo tricks, but I also don't want to spark up public discussion on this again either. So it might be best to default Input/Latency to 0ms, and internally have a max(5, latency) wrapper around the value.
2016-08-03 12:32:40 +00:00
if(!presentation || !presentation->focused()) return;
for(auto& hotkey : hotkeys) {
int16 state = hotkey->poll();
if(hotkey->state == 0 && state == 1 && hotkey->press) hotkey->press();
if(hotkey->state == 1 && state == 0 && hotkey->release) hotkey->release();
hotkey->state = state;
}
}