bsnes/ruby/input/joypad/udev.cpp

280 lines
8.9 KiB
C++
Raw Normal View History

Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
#ifndef RUBY_INPUT_JOYPAD_UDEV
#define RUBY_INPUT_JOYPAD_UDEV
struct InputJoypadUdev {
Input& input;
InputJoypadUdev(Input& input) : input(input) {}
udev* context = nullptr;
udev_monitor* monitor = nullptr;
udev_enumerate* enumerator = nullptr;
udev_list_entry* devices = nullptr;
udev_list_entry* item = nullptr;
struct JoypadInput {
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
int code = 0;
uint id = 0;
int16_t value = 0;
input_absinfo info;
JoypadInput() {}
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
JoypadInput(int code) : code(code) {}
JoypadInput(int code, uint id) : code(code), id(id) {}
bool operator< (const JoypadInput& source) const { return code < source.code; }
bool operator==(const JoypadInput& source) const { return code == source.code; }
};
struct Joypad {
shared_pointer<HID::Joypad> hid{new HID::Joypad};
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
int fd = -1;
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
dev_t device = 0;
string deviceName;
string deviceNode;
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
uint8_t evbit[(EV_MAX + 7) / 8] = {0};
uint8_t keybit[(KEY_MAX + 7) / 8] = {0};
uint8_t absbit[(ABS_MAX + 7) / 8] = {0};
uint8_t ffbit[(FF_MAX + 7) / 8] = {0};
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
uint effects = 0;
string name;
string manufacturer;
string product;
string serial;
string vendorID;
string productID;
set<JoypadInput> axes;
set<JoypadInput> hats;
set<JoypadInput> buttons;
bool rumble = false;
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
uint effectID = 0;
};
vector<Joypad> joypads;
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
auto assign(shared_pointer<HID::Joypad> hid, uint groupID, uint inputID, int16_t value) -> void {
auto& group = hid->group(groupID);
if(group.input(inputID).value() == value) return;
input.doChange(hid, groupID, inputID, group.input(inputID).value(), value);
group.input(inputID).setValue(value);
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
}
auto poll(vector<shared_pointer<HID::Device>>& devices) -> void {
while(hotplugDevicesAvailable()) hotplugDevice();
for(auto& jp : joypads) {
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
input_event events[32];
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
int length = 0;
while((length = read(jp.fd, events, sizeof(events))) > 0) {
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
length /= sizeof(input_event);
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
for(uint i : range(length)) {
int code = events[i].code;
int type = events[i].type;
int value = events[i].value;
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
if(type == EV_ABS) {
if(auto input = jp.axes.find({code})) {
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
int range = input().info.maximum - input().info.minimum;
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
value = (value - input().info.minimum) * 65535ll / range - 32767;
assign(jp.hid, HID::Joypad::GroupID::Axis, input().id, sclamp<16>(value));
} else if(auto input = jp.hats.find({code})) {
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
int range = input().info.maximum - input().info.minimum;
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
value = (value - input().info.minimum) * 65535ll / range - 32767;
assign(jp.hid, HID::Joypad::GroupID::Hat, input().id, sclamp<16>(value));
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
}
} else if(type == EV_KEY) {
if(code >= BTN_MISC) {
if(auto input = jp.buttons.find({code})) {
assign(jp.hid, HID::Joypad::GroupID::Button, input().id, (bool)value);
}
}
}
}
}
devices.append(jp.hid);
}
}
auto rumble(uint64_t id, bool enable) -> bool {
for(auto& jp : joypads) {
if(jp.hid->id() != id) continue;
if(!jp.hid->rumble()) continue;
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
input_event play;
memset(&play, 0, sizeof(input_event));
play.type = EV_FF;
play.code = jp.effectID;
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
play.value = enable;
auto unused = write(jp.fd, &play, sizeof(input_event));
return true;
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
}
return false;
}
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
auto initialize() -> bool {
context = udev_new();
if(context == nullptr) return false;
monitor = udev_monitor_new_from_netlink(context, "udev");
if(monitor) {
udev_monitor_filter_add_match_subsystem_devtype(monitor, "input", nullptr);
udev_monitor_enable_receiving(monitor);
}
enumerator = udev_enumerate_new(context);
if(enumerator) {
udev_enumerate_add_match_property(enumerator, "ID_INPUT_JOYSTICK", "1");
udev_enumerate_scan_devices(enumerator);
devices = udev_enumerate_get_list_entry(enumerator);
for(udev_list_entry* item = devices; item != nullptr; item = udev_list_entry_get_next(item)) {
string name = udev_list_entry_get_name(item);
udev_device* device = udev_device_new_from_syspath(context, name);
string deviceNode = udev_device_get_devnode(device);
if(deviceNode) createJoypad(device, deviceNode);
udev_device_unref(device);
}
}
return true;
}
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
auto terminate() -> void {
if(enumerator) { udev_enumerate_unref(enumerator); enumerator = nullptr; }
}
private:
auto hotplugDevicesAvailable() -> bool {
pollfd fd = {0};
fd.fd = udev_monitor_get_fd(monitor);
fd.events = POLLIN;
return (::poll(&fd, 1, 0) == 1) && (fd.revents & POLLIN);
}
auto hotplugDevice() -> void {
udev_device* device = udev_monitor_receive_device(monitor);
if(device == nullptr) return;
string value = udev_device_get_property_value(device, "ID_INPUT_JOYSTICK");
string action = udev_device_get_action(device);
string deviceNode = udev_device_get_devnode(device);
if(value == "1") {
if(action == "add") {
createJoypad(device, deviceNode);
}
if(action == "remove") {
removeJoypad(device, deviceNode);
}
}
}
auto createJoypad(udev_device* device, const string& deviceNode) -> void {
Joypad jp;
jp.deviceNode = deviceNode;
struct stat st;
if(stat(deviceNode, &st) < 0) return;
jp.device = st.st_rdev;
jp.fd = open(deviceNode, O_RDWR | O_NONBLOCK);
if(jp.fd < 0) return;
uint8_t evbit[(EV_MAX + 7) / 8] = {0};
uint8_t keybit[(KEY_MAX + 7) / 8] = {0};
uint8_t absbit[(ABS_MAX + 7) / 8] = {0};
ioctl(jp.fd, EVIOCGBIT(0, sizeof(jp.evbit)), jp.evbit);
ioctl(jp.fd, EVIOCGBIT(EV_KEY, sizeof(jp.keybit)), jp.keybit);
ioctl(jp.fd, EVIOCGBIT(EV_ABS, sizeof(jp.absbit)), jp.absbit);
ioctl(jp.fd, EVIOCGBIT(EV_FF, sizeof(jp.ffbit)), jp.ffbit);
ioctl(jp.fd, EVIOCGEFFECTS, &jp.effects);
#define testBit(buffer, bit) (buffer[(bit) >> 3] & 1 << ((bit) & 7))
if(testBit(jp.evbit, EV_KEY)) {
if(udev_device* parent = udev_device_get_parent_with_subsystem_devtype(device, "input", nullptr)) {
jp.name = udev_device_get_sysattr_value(parent, "name");
jp.vendorID = udev_device_get_sysattr_value(parent, "id/vendor");
jp.productID = udev_device_get_sysattr_value(parent, "id/product");
if(udev_device* root = udev_device_get_parent_with_subsystem_devtype(parent, "usb", "usb_device")) {
if(jp.vendorID == udev_device_get_sysattr_value(root, "idVendor")
&& jp.productID == udev_device_get_sysattr_value(root, "idProduct")
) {
jp.deviceName = udev_device_get_devpath(root);
jp.manufacturer = udev_device_get_sysattr_value(root, "manufacturer");
jp.product = udev_device_get_sysattr_value(root, "product");
jp.serial = udev_device_get_sysattr_value(root, "serial");
}
}
}
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
uint axes = 0;
uint hats = 0;
uint buttons = 0;
for(int i = 0; i < ABS_MISC; i++) {
if(testBit(jp.absbit, i)) {
if(i >= ABS_HAT0X && i <= ABS_HAT3Y) {
if(auto hat = jp.hats.insert({i, hats++})) {
ioctl(jp.fd, EVIOCGABS(i), &hat().info);
}
} else {
if(auto axis = jp.axes.insert({i, axes++})) {
ioctl(jp.fd, EVIOCGABS(i), &axis().info);
}
}
}
}
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
for(int i = BTN_JOYSTICK; i < KEY_MAX; i++) {
if(testBit(jp.keybit, i)) {
jp.buttons.insert({i, buttons++});
}
}
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
for(int i = BTN_MISC; i < BTN_JOYSTICK; i++) {
if(testBit(jp.keybit, i)) {
jp.buttons.insert({i, buttons++});
}
}
jp.rumble = jp.effects >= 2 && testBit(jp.ffbit, FF_RUMBLE);
if(jp.rumble) {
ff_effect effect;
memset(&effect, 0, sizeof(ff_effect));
effect.type = FF_RUMBLE;
effect.id = -1;
effect.u.rumble.strong_magnitude = 65535;
effect.u.rumble.weak_magnitude = 65535;
ioctl(jp.fd, EVIOCSFF, &effect);
jp.effectID = effect.id;
}
createJoypadHID(jp);
joypads.append(jp);
}
#undef testBit
}
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
auto createJoypadHID(Joypad& jp) -> void {
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
uint64_t pathID = Hash::CRC32(jp.deviceName.data(), jp.deviceName.size()).value();
jp.hid->setID(pathID << 32 | jp.vendorID.hex() << 16 | jp.productID.hex() << 0);
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
for(uint n : range(jp.axes.size())) jp.hid->axes().append(n);
for(uint n : range(jp.hats.size())) jp.hid->hats().append(n);
for(uint n : range(jp.buttons.size())) jp.hid->buttons().append(n);
jp.hid->setRumble(jp.rumble);
}
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
auto removeJoypad(udev_device* device, const string& deviceNode) -> void {
Update to v103r22 release. byuu says: Changelog: - ruby: ported all remaining drivers to new API¹ - ruby/wasapi: fix for dropping one sample per period [SuperMikeMan] - gb: emulated most of the TAMA RTC; but RTC state is still volatile² ¹: the new ports are: - audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao} - input/{udev, quartz, carbon} It's pretty much guaranteed many of them will have compilation errors. Please paste the error logs and I'll try to fix them up. It may take a WIP or two to get there. It's also possible things broke from the updates. If so, I could use help comparing the old file to the new file, looking for mistakes, since I can't test on these platforms apart from audio/directsound. Please report working drivers in this list, so we can mark them off the list. I'll need both macOS and Linux testers. audio/directsound.cpp:112:    if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false; ²: once I get this working, I'll add load/save support for the RTC values. For now, the RTC data will be lost when you close the emulator. Right now, you can set the date/time in real-time mode, and when you start the game, the time will be correct, and the time will tick forward. Note that it runs off emulated time instead of actual real time, so if you fast-forward to 300%, one minute will be 20 seconds. The really big limitation right now is that when you exit the game, and restart it, and resume a new game, the hour spot gets corrupted, and this seems to instantly kill your pet. Fun. This is crazy because the commands the game sends to the TAMA interface are identical between starting a new game and getting in-game versus loading a game. It's likely going to require disassembling the game's code and seeing what in the hell it's doing, but I am extremely bad at LR35092 assembly. Hopefully endrift can help here :|
2017-07-28 11:42:24 +00:00
for(uint n : range(joypads.size())) {
if(joypads[n].deviceNode == deviceNode) {
close(joypads[n].fd);
joypads.remove(n);
return;
}
}
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
}
};
Update to v093r12 release. byuu says: I've completely redone the ethos InputManager and ruby to work on HID::Device objects instead of one giant scancode pool. Currently only the udev driver supports the changes to ruby, so only Linux users will be able to compile and run this WIP build. The nice thing about the new system is that it's now possible to uniquely identify controllers, so if you swap out gamepads, you won't end up with it working but with all the mappings all screwed up. Since higan lets you map multiple physical inputs to one emulated input, you can now configure your keyboard and multiple gamepads to the same emulated input, and then just use whatever controller you want. Because USB gamepad makers failed to provide unique serial#s with each controller, we have to limit the mapping to specific USB ports. Otherwise, we couldn't distinguish two otherwise identical gamepads. So basically your computer USB ports act like real game console input port numbers. Which is kind of neat, I guess. And the really nice thing about the new system is that we now have the capability to support hotplugging input devices. I haven't yet added this to any drivers, but I'm definitely going to add it to udev for v094 official. Finally, with the device ID (vendor ID + product ID) exposed, we gain one last really cool feature that we may be able to develop more in the future. Say we created a joypad.bml file to include with higan. In it, we'd store the Xbox 360 controller, and pre-defined button mappings for each emulated system. So if higan detects you have an Xbox 360 controller, you can just plug it in and use it. Even better, we can clearly specify the difference between triggers and analog axes, and name each individual input. So you'd see "Xbox 360 Gamepad #1: Left Trigger" instead of higan v093's "JP0::Axis2.Hi" Note: for right now, ethos' input manager isn't filtering the device IDs to look pretty. So you're going to see a 64-bit hex value for a device ID right now instead of something like Joypad#N for now.
2013-12-23 11:43:51 +00:00
#endif