2015-03-02 09:13:28 +00:00
|
|
|
struct InputMapping {
|
|
|
|
auto bind() -> void;
|
2015-12-21 09:16:47 +00:00
|
|
|
auto bind(shared_pointer<HID::Device> device, uint group, uint input, int16 oldValue, int16 newValue) -> bool;
|
2015-03-02 09:13:28 +00:00
|
|
|
auto poll() -> int16;
|
2015-08-24 09:42:11 +00:00
|
|
|
auto rumble(bool enable) -> void;
|
Update to v094r13 release.
byuu says:
This version polishes up the input dialogue (reset, erase, disable
button when item not focused, split device ID from mapping name), adds
color emulation toggle, and add dummy menu items for remaining features
(to be filled in later.)
Also, it now compiles cleanly on Windows with GTK.
I didn't test with TDM-GCC-32, because for god knows what reason, the
32-bit version ships with headers from Windows 95 OSR2 only. So I built
with TDM-GCC-64 with arch=x86.
And uh, apparently, moving or resizing a window causes a Visual C++
runtime exception in the GTK+ DLLs. This doesn't happen with trance or
renshuu built with TDM-GCC-32. So, yeah, like I said, don't use -m32.
2015-03-07 10:21:47 +00:00
|
|
|
auto unbind() -> void;
|
2015-03-02 09:13:28 +00:00
|
|
|
|
2016-06-26 08:54:12 +00:00
|
|
|
auto isDigital() const -> bool { return type == 0; }
|
|
|
|
auto isAnalog() const -> bool { return type == 1; }
|
|
|
|
auto isRumble() const -> bool { return type == 2; }
|
2015-05-23 05:29:18 +00:00
|
|
|
|
2015-05-24 09:44:28 +00:00
|
|
|
auto assignmentName() -> string;
|
|
|
|
auto deviceName() -> string;
|
2015-05-23 05:29:18 +00:00
|
|
|
|
2015-11-16 08:38:05 +00:00
|
|
|
string path; //configuration file key path
|
|
|
|
string name; //input name (human readable)
|
2016-06-26 08:54:12 +00:00
|
|
|
uint type = 0;
|
2015-03-02 09:13:28 +00:00
|
|
|
string assignment = "None";
|
2015-05-24 09:44:28 +00:00
|
|
|
shared_pointer<HID::Device> device;
|
2015-12-21 09:16:47 +00:00
|
|
|
uint group = 0;
|
|
|
|
uint input = 0;
|
|
|
|
enum class Qualifier : uint { None, Lo, Hi, Rumble } qualifier = Qualifier::None;
|
2015-03-02 09:13:28 +00:00
|
|
|
};
|
|
|
|
|
2015-04-13 11:16:33 +00:00
|
|
|
struct InputHotkey : InputMapping {
|
2015-12-21 09:16:47 +00:00
|
|
|
function<auto () -> void> press;
|
|
|
|
function<auto () -> void> release;
|
2015-04-13 11:16:33 +00:00
|
|
|
|
|
|
|
int16 state = 0;
|
|
|
|
};
|
|
|
|
|
2015-03-02 09:13:28 +00:00
|
|
|
struct InputDevice {
|
|
|
|
string name;
|
2016-06-26 08:54:12 +00:00
|
|
|
vector<InputMapping> mappings;
|
2015-03-02 09:13:28 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct InputPort {
|
|
|
|
string name;
|
|
|
|
vector<InputDevice> devices;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct InputEmulator {
|
2016-06-26 08:54:12 +00:00
|
|
|
Emulator::Interface* interface = nullptr;
|
2015-03-02 09:13:28 +00:00
|
|
|
string name;
|
|
|
|
vector<InputPort> ports;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct InputManager {
|
|
|
|
InputManager();
|
2016-06-26 08:54:12 +00:00
|
|
|
auto bind(Emulator::Interface*) -> void;
|
2015-03-02 09:13:28 +00:00
|
|
|
auto bind() -> void;
|
|
|
|
auto poll() -> void;
|
Update to v097r14 release.
byuu says:
This is a few days old, but oh well.
This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t.
I'm slowly pushing for (u)int(8,16,32,64) to use my custom
Integer<Size>/Natural<Size> classes instead. But it's going to be one
hell of a struggle to get that into higan.
2016-02-16 09:11:58 +00:00
|
|
|
auto onChange(shared_pointer<HID::Device> device, uint group, uint input, int16_t oldValue, int16_t newValue) -> void;
|
2015-03-02 09:13:28 +00:00
|
|
|
auto quit() -> void;
|
|
|
|
|
2015-05-24 09:44:28 +00:00
|
|
|
auto findMouse() -> shared_pointer<HID::Device>;
|
2015-05-23 05:29:18 +00:00
|
|
|
|
2015-04-13 11:16:33 +00:00
|
|
|
//hotkeys.cpp
|
|
|
|
auto appendHotkeys() -> void;
|
|
|
|
auto pollHotkeys() -> void;
|
|
|
|
|
2015-05-24 09:44:28 +00:00
|
|
|
vector<shared_pointer<HID::Device>> devices;
|
2015-03-02 09:13:28 +00:00
|
|
|
vector<InputEmulator> emulators;
|
2015-04-13 11:16:33 +00:00
|
|
|
vector<InputHotkey*> hotkeys;
|
2016-06-26 08:54:12 +00:00
|
|
|
|
|
|
|
InputEmulator* emulator = nullptr; //points to InputEmulator that represents the currently active emulator
|
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
|
|
|
uint64 lastPoll; //time in milliseconds since last call to poll()
|
|
|
|
uint64 latency; //minimum time in milliseconds before poll() can be called again
|
2015-03-02 09:13:28 +00:00
|
|
|
};
|
|
|
|
|
Update to v097r02 release.
byuu says:
Note: balanced/performance profiles still broken, sorry.
Changelog:
- added nall/GNUmakefile unique() function; used on linking phase of
higan
- added nall/unique_pointer
- target-tomoko and {System}::Video updated to use
unique_pointer<ClassName> instead of ClassName* [1]
- locate() updated to search multiple paths [2]
- GB: pass gekkio's if_ie_registers and boot_hwio-G test ROMs
- FC, GB, GBA: merge video/ into the PPU cores
- ruby: fixed ~AudioXAudio2() typo
[1] I expected this to cause new crashes on exit due to changing the
order of destruction of objects (and deleting things that weren't
deleted before), but ... so far, so good. I guess we'll see what crops
up, especially on OS X (which is already crashing for unknown reasons on
exit.)
[2] right now, the search paths are: programpath(), {configpath(),
"higan/"}, {localpath(), "higan/"}; but we can add as many more as we
want, and we can also add platform-specific versions.
2016-01-25 11:27:18 +00:00
|
|
|
extern unique_pointer<InputManager> inputManager;
|