2015-04-13 11:16:33 +00:00
|
|
|
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;
|
|
|
|
|
2015-04-21 11:51:57 +00:00
|
|
|
{ auto hotkey = new InputHotkey;
|
2015-04-13 11:16:33 +00:00
|
|
|
hotkey->name = "Toggle Fullscreen";
|
2015-08-24 09:42:11 +00:00
|
|
|
hotkey->press = [] {
|
2015-04-13 11:16:33 +00:00
|
|
|
presentation->toggleFullScreen();
|
|
|
|
};
|
|
|
|
hotkeys.append(hotkey);
|
|
|
|
}
|
|
|
|
|
2015-05-23 05:29:18 +00:00
|
|
|
{ auto hotkey = new InputHotkey;
|
|
|
|
hotkey->name = "Toggle Mouse Capture";
|
2015-08-24 09:42:11 +00:00
|
|
|
hotkey->press = [] {
|
2015-06-20 05:44:05 +00:00
|
|
|
input->acquired() ? input->release() : input->acquire();
|
2015-05-23 05:29:18 +00:00
|
|
|
};
|
|
|
|
hotkeys.append(hotkey);
|
|
|
|
}
|
|
|
|
|
2015-04-21 11:51:57 +00:00
|
|
|
{ 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";
|
2015-08-24 09:42:11 +00:00
|
|
|
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);
|
2015-04-21 11:51:57 +00:00
|
|
|
};
|
|
|
|
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});
|
2015-04-21 11:51:57 +00:00
|
|
|
};
|
|
|
|
hotkeys.append(hotkey);
|
|
|
|
}
|
|
|
|
|
|
|
|
{ auto hotkey = new InputHotkey;
|
|
|
|
hotkey->name = "Pause Emulation";
|
2015-08-24 09:42:11 +00:00
|
|
|
hotkey->press = [] {
|
2015-04-21 11:51:57 +00:00
|
|
|
program->pause = !program->pause;
|
|
|
|
};
|
|
|
|
hotkeys.append(hotkey);
|
|
|
|
}
|
|
|
|
|
2015-08-24 09:42:11 +00:00
|
|
|
{ auto hotkey = new InputHotkey;
|
|
|
|
hotkey->name = "Fast Forward";
|
|
|
|
hotkey->press = [] {
|
|
|
|
video->set(Video::Synchronize, false);
|
|
|
|
audio->set(Audio::Synchronize, false);
|
|
|
|
};
|
|
|
|
hotkey->release = [] {
|
2015-11-16 08:38:05 +00:00
|
|
|
video->set(Video::Synchronize, settings["Video/Synchronize"].boolean());
|
|
|
|
audio->set(Audio::Synchronize, settings["Audio/Synchronize"].boolean());
|
2015-08-24 09:42:11 +00:00
|
|
|
};
|
|
|
|
hotkeys.append(hotkey);
|
|
|
|
}
|
|
|
|
|
2015-04-21 11:51:57 +00:00
|
|
|
{ auto hotkey = new InputHotkey;
|
|
|
|
hotkey->name = "Power Cycle";
|
2015-08-24 09:42:11 +00:00
|
|
|
hotkey->press = [] {
|
2015-04-21 11:51:57 +00:00
|
|
|
program->powerCycle();
|
|
|
|
};
|
|
|
|
hotkeys.append(hotkey);
|
|
|
|
}
|
|
|
|
|
2017-06-08 14:05:48 +00:00
|
|
|
{ auto hotkey = new InputHotkey;
|
|
|
|
hotkey->name = "Rotate Display";
|
|
|
|
hotkey->press = [] {
|
|
|
|
program->rotateDisplay();
|
|
|
|
};
|
|
|
|
hotkeys.append(hotkey);
|
|
|
|
}
|
|
|
|
|
2015-04-13 11:16:33 +00:00
|
|
|
for(auto& hotkey : hotkeys) {
|
2015-11-16 08:38:05 +00:00
|
|
|
hotkey->path = string{"Hotkey/", hotkey->name}.replace(" ", "");
|
|
|
|
hotkey->assignment = settings(hotkey->path).text();
|
|
|
|
hotkey->bind();
|
2015-04-13 11:16:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
2015-04-13 11:16:33 +00:00
|
|
|
for(auto& hotkey : hotkeys) {
|
|
|
|
int16 state = hotkey->poll();
|
2015-08-24 09:42:11 +00:00
|
|
|
if(hotkey->state == 0 && state == 1 && hotkey->press) hotkey->press();
|
|
|
|
if(hotkey->state == 1 && state == 0 && hotkey->release) hotkey->release();
|
2015-04-13 11:16:33 +00:00
|
|
|
hotkey->state = state;
|
|
|
|
}
|
|
|
|
}
|