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

287 lines
9.1 KiB
C++
Raw Normal View History

#include "../tomoko.hpp"
#include "hotkeys.cpp"
unique_pointer<InputManager> inputManager;
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
//build mappings list from assignment string
auto InputMapping::bind() -> void {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
mappings.reset();
auto list = assignment.split(logic() == Logic::AND ? "&" : "|");
for(auto& item : list) {
auto token = item.split("/");
if(token.size() < 3) continue; //skip invalid mappings
uint64 id = token[0].natural();
uint group = token[1].natural();
uint input = token[2].natural();
string qualifier = token(3, "None");
Mapping mapping;
for(auto& device : inputManager->devices) {
if(id != device->id()) continue;
mapping.device = device;
mapping.group = group;
mapping.input = input;
mapping.qualifier = Qualifier::None;
if(qualifier == "Lo") mapping.qualifier = Qualifier::Lo;
if(qualifier == "Hi") mapping.qualifier = Qualifier::Hi;
if(qualifier == "Rumble") mapping.qualifier = Qualifier::Rumble;
break;
}
if(!mapping.device) continue;
mappings.append(mapping);
}
settings[path].setValue(assignment);
}
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
//append new mapping to mappings list
auto InputMapping::bind(string mapping) -> void {
auto list = assignment.split(logic() == Logic::AND ? "&" : "|");
if(list.find(mapping)) return; //already in the mappings list
if(!assignment || assignment == "None") {
//create new mapping
assignment = mapping;
} else {
//add additional mapping
assignment.append(logic() == Logic::AND ? "&" : "|");
assignment.append(mapping);
}
bind();
}
auto InputMapping::bind(shared_pointer<HID::Device> device, uint group, uint input, int16 oldValue, int16 newValue) -> bool {
if(device->isNull() || (device->isKeyboard() && device->group(group).input(input).name() == "Escape")) {
return unbind(), true;
}
string encoding = {"0x", hex(device->id()), "/", group, "/", input};
if(isDigital()) {
if((device->isKeyboard() && group == HID::Keyboard::GroupID::Button)
|| (device->isMouse() && group == HID::Mouse::GroupID::Button)
|| (device->isJoypad() && group == HID::Joypad::GroupID::Button)) {
if(newValue) {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
return bind(encoding), true;
}
}
if((device->isJoypad() && group == HID::Joypad::GroupID::Axis)
|| (device->isJoypad() && group == HID::Joypad::GroupID::Hat)
|| (device->isJoypad() && group == HID::Joypad::GroupID::Trigger)) {
if(newValue < -16384 && group != HID::Joypad::GroupID::Trigger) { //triggers are always hi
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
return bind({encoding, "/Lo"}), true;
}
if(newValue > +16384) {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
return bind({encoding, "/Hi"}), true;
}
}
}
if(isAnalog()) {
if((device->isMouse() && group == HID::Mouse::GroupID::Axis)
|| (device->isJoypad() && group == HID::Joypad::GroupID::Axis)
|| (device->isJoypad() && group == HID::Joypad::GroupID::Hat)) {
if(newValue < -16384 || newValue > +16384) {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
return bind(encoding), true;
}
}
}
if(isRumble()) {
if(device->isJoypad() && group == HID::Joypad::GroupID::Button) {
if(newValue) {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
return bind({encoding, "/Rumble"}), true;
}
}
}
return false;
}
auto InputMapping::poll() -> int16 {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
if(!mappings) return 0;
if(isDigital()) {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
bool result = logic() == Logic::AND ? 1 : 0;
for(auto& mapping : mappings) {
auto value = mapping.device->group(mapping.group).input(mapping.input).value();
bool output = logic() == Logic::AND ? 0 : 1;
if(mapping.device->isKeyboard() && mapping.group == HID::Keyboard::GroupID::Button) output = value != 0;
if(mapping.device->isMouse() && mapping.group == HID::Mouse::GroupID::Button) output = value != 0;
if(mapping.device->isJoypad() && mapping.group == HID::Joypad::GroupID::Button) output = value != 0;
if((mapping.device->isJoypad() && mapping.group == HID::Joypad::GroupID::Axis)
|| (mapping.device->isJoypad() && mapping.group == HID::Joypad::GroupID::Hat)
|| (mapping.device->isJoypad() && mapping.group == HID::Joypad::GroupID::Trigger)) {
if(mapping.qualifier == Qualifier::Lo) output = value < -16384;
if(mapping.qualifier == Qualifier::Hi) output = value > +16384;
}
if(logic() == Logic::AND) result &= output;
if(logic() == Logic::OR ) result |= output;
}
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
return result;
}
if(isAnalog()) {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
int16 result = 0;
for(auto& mapping : mappings) {
auto value = mapping.device->group(mapping.group).input(mapping.input).value();
//logic does not apply to analog inputs ... always combinatorial
if(mapping.device->isMouse() && mapping.group == HID::Mouse::GroupID::Axis) result += value;
if(mapping.device->isJoypad() && mapping.group == HID::Joypad::GroupID::Axis) result += value >> 8;
if(mapping.device->isJoypad() && mapping.group == HID::Joypad::GroupID::Hat) result += value < 0 ? -1 : value > 0 ? +1 : 0;
}
return result;
}
return 0;
}
auto InputMapping::rumble(bool enable) -> void {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
if(!mappings) return;
for(auto& mapping : mappings) {
::input->rumble(mapping.device->id(), enable);
}
}
auto InputMapping::unbind() -> void {
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
mappings.reset();
assignment = "None";
settings[path].setValue(assignment);
}
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
//create a human-readable string from mappings list for display in the user interface
auto InputMapping::displayName() -> string {
if(!mappings) return "None";
string path;
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
for(auto& mapping : mappings) {
path.append(mapping.device->name());
if(mapping.device->name() != "Keyboard" && mapping.device->name() != "Mouse") {
//show device IDs to distinguish between multiple joypads
path.append("(", hex(mapping.device->id()), ")");
}
if(mapping.device->name() != "Keyboard") {
//keyboards only have one group; no need to append group name
path.append(".", mapping.device->group(mapping.group).name());
}
path.append(".", mapping.device->group(mapping.group).input(mapping.input).name());
if(mapping.qualifier == Qualifier::Lo) path.append(".Lo");
if(mapping.qualifier == Qualifier::Hi) path.append(".Hi");
if(mapping.qualifier == Qualifier::Rumble) path.append(".Rumble");
path.append(logic() == Logic::AND ? " and " : " or ");
}
Update to v102r21 release. byuu says: Changelog: - GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn] - R65816: added support for yielding/resuming from WAI/STP¹ - SFC: removed status.dmaCounter functionality (also fixes possible TAS desync issue) - tomoko: added support for combinatorial inputs [hex\_usr\]² - nall: fixed missing return value from Arithmetic::operator-- [Hendricks266] Now would be the time to start looking for major regressions with the new GBA PPU renderer, I suppose ... ¹: this doesn't matter for the master thread (SNES CPU), but is important for slave threads (SNES SA1). If you try to save a state and the SA1 is inside of a WAI instruction, it will get stuck there forever. This was causing attempts to create a save state in Super Bomberman - Panic Bomber W to deadlock the emulator and crash it. This is now finally fixed. Note that I still need to implement similar functionality into the Mega Drive 68K and Z80 cores. They still have the possibility of deadlocking. The SNES implementation was more a dry-run test for this new functionality. This possible crashing bug in the Mega Drive core is the major blocking bug for a new official release. ²: many, many thanks to hex\_usr for coming up with a really nice design. I mostly implemented it the exact same way, but with a few tiny differences that don't really matter (display " and ", " or " instead of " & ", " | " in the input settings windows; append → bind; assignmentName changed to displayName.) The actual functionality is identical to the old higan v094 and earlier builds. Emulated digital inputs let you combine multiple possible keys to trigger the buttons. This is OR logic, so you can map to eg keyboard.up OR gamepad.up for instance. Emulated analog inputs always sum together. Emulated rumble outputs will cause all mapped devices to rumble, which is probably not at all useful but whatever. Hotkeys use AND logic, so you have to press every key mapped to trigger them. Useful for eg Ctrl+F to trigger fullscreen. Obviously, there are cases where OR logic would be nice for hotkeys, too. Eg if you want both F11 and your gamepad's guide button to trigger the fullscreen toggle. Unfortunately, this isn't supported, and likely won't ever be in tomoko. Something I might consider is a throw switch in the configuration file to swap between AND or OR logic for hotkeys, but I'm not going to allow construction of mappings like "(Keyboard.Ctrl and Keyboard.F) or Gamepad.Guide", as that's just too complicated to code, and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
return path.trimRight(logic() == Logic::AND ? " and " : " or ", 1L);
}
//
InputManager::InputManager() {
inputManager = this;
frequency = max(1u, settings["Input/Frequency"].natural());
for(auto& emulator : program->emulators) {
Update to v099r10 release. byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access.
2016-06-26 08:54:12 +00:00
auto& inputEmulator = emulators(emulators.size());
inputEmulator.interface = emulator;
inputEmulator.name = emulator->information.name;
Update to v098r11 release. byuu says: Changelog: - fixed nall/path.hpp compilation issue - fixed ruby/audio/xaudio header declaration compilation issue (again) - cleaned up xaudio2.hpp file to match my coding syntax (12.5% of the file was whitespace overkill) - added null terminator entry to nall/windows/utf8.hpp argc[] array - nall/windows/guid.hpp uses the Windows API for generating the GUID - this should stop all the bug reports where two nall users were generating GUIDs at the exact same second - fixed hiro/cocoa compilation issue with uint# types - fixed major higan/sfc Super Game Boy audio latency issue - fixed higan/sfc CPU core bug with pei, [dp], [dp]+y instructions - major cleanups to higan/processor/r65816 core - merged emulation/native-mode opcodes - use camel-case naming on memory.hpp functions - simplify address masking code for memory.hpp functions - simplify a few opcodes themselves (avoid redundant copies, etc) - rename regs.* to r.* to match modern convention of other CPU cores - removed device.order<> concept from Emulator::Interface - cores will now do the translation to make the job of the UI easier - fixed plurality naming of arrays in Emulator::Interface - example: emulator.ports[p].devices[d].inputs[i] - example: vector<Medium> media - probably more surprises Major show-stoppers to the next official release: - we need to work on GB core improvements: LY=153/0 case, multiple STAT IRQs case, GBC audio output regs, etc. - we need to re-add software cursors for light guns (Super Scope, Justifier) - after the above, we need to fix the turbo button for the Super Scope I really have no idea how I want to implement the light guns. Ideally, we'd want it in higan/video, so we can support the NES Zapper with the same code. But this isn't going to be easy, because only the SNES knows when its output is interlaced, and its resolutions can vary as {256,512}x{224,240,448,480} which requires pixel doubling that was hard-coded to the SNES-specific behavior, but isn't appropriate to be exposed in higan/video.
2016-05-25 11:13:02 +00:00
for(auto& port : emulator->ports) {
auto& inputPort = inputEmulator.ports(port.id);
inputPort.name = port.name;
Update to v098r11 release. byuu says: Changelog: - fixed nall/path.hpp compilation issue - fixed ruby/audio/xaudio header declaration compilation issue (again) - cleaned up xaudio2.hpp file to match my coding syntax (12.5% of the file was whitespace overkill) - added null terminator entry to nall/windows/utf8.hpp argc[] array - nall/windows/guid.hpp uses the Windows API for generating the GUID - this should stop all the bug reports where two nall users were generating GUIDs at the exact same second - fixed hiro/cocoa compilation issue with uint# types - fixed major higan/sfc Super Game Boy audio latency issue - fixed higan/sfc CPU core bug with pei, [dp], [dp]+y instructions - major cleanups to higan/processor/r65816 core - merged emulation/native-mode opcodes - use camel-case naming on memory.hpp functions - simplify address masking code for memory.hpp functions - simplify a few opcodes themselves (avoid redundant copies, etc) - rename regs.* to r.* to match modern convention of other CPU cores - removed device.order<> concept from Emulator::Interface - cores will now do the translation to make the job of the UI easier - fixed plurality naming of arrays in Emulator::Interface - example: emulator.ports[p].devices[d].inputs[i] - example: vector<Medium> media - probably more surprises Major show-stoppers to the next official release: - we need to work on GB core improvements: LY=153/0 case, multiple STAT IRQs case, GBC audio output regs, etc. - we need to re-add software cursors for light guns (Super Scope, Justifier) - after the above, we need to fix the turbo button for the Super Scope I really have no idea how I want to implement the light guns. Ideally, we'd want it in higan/video, so we can support the NES Zapper with the same code. But this isn't going to be easy, because only the SNES knows when its output is interlaced, and its resolutions can vary as {256,512}x{224,240,448,480} which requires pixel doubling that was hard-coded to the SNES-specific behavior, but isn't appropriate to be exposed in higan/video.
2016-05-25 11:13:02 +00:00
for(auto& device : port.devices) {
auto& inputDevice = inputPort.devices(device.id);
inputDevice.name = device.name;
Update to v098r11 release. byuu says: Changelog: - fixed nall/path.hpp compilation issue - fixed ruby/audio/xaudio header declaration compilation issue (again) - cleaned up xaudio2.hpp file to match my coding syntax (12.5% of the file was whitespace overkill) - added null terminator entry to nall/windows/utf8.hpp argc[] array - nall/windows/guid.hpp uses the Windows API for generating the GUID - this should stop all the bug reports where two nall users were generating GUIDs at the exact same second - fixed hiro/cocoa compilation issue with uint# types - fixed major higan/sfc Super Game Boy audio latency issue - fixed higan/sfc CPU core bug with pei, [dp], [dp]+y instructions - major cleanups to higan/processor/r65816 core - merged emulation/native-mode opcodes - use camel-case naming on memory.hpp functions - simplify address masking code for memory.hpp functions - simplify a few opcodes themselves (avoid redundant copies, etc) - rename regs.* to r.* to match modern convention of other CPU cores - removed device.order<> concept from Emulator::Interface - cores will now do the translation to make the job of the UI easier - fixed plurality naming of arrays in Emulator::Interface - example: emulator.ports[p].devices[d].inputs[i] - example: vector<Medium> media - probably more surprises Major show-stoppers to the next official release: - we need to work on GB core improvements: LY=153/0 case, multiple STAT IRQs case, GBC audio output regs, etc. - we need to re-add software cursors for light guns (Super Scope, Justifier) - after the above, we need to fix the turbo button for the Super Scope I really have no idea how I want to implement the light guns. Ideally, we'd want it in higan/video, so we can support the NES Zapper with the same code. But this isn't going to be easy, because only the SNES knows when its output is interlaced, and its resolutions can vary as {256,512}x{224,240,448,480} which requires pixel doubling that was hard-coded to the SNES-specific behavior, but isn't appropriate to be exposed in higan/video.
2016-05-25 11:13:02 +00:00
for(auto& input : device.inputs) {
Update to v099r10 release. byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access.
2016-06-26 08:54:12 +00:00
auto& inputMapping = inputDevice.mappings(inputDevice.mappings.size());
inputMapping.name = input.name;
inputMapping.type = input.type;
Update to v099r10 release. byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access.
2016-06-26 08:54:12 +00:00
inputMapping.path = string{inputEmulator.name, "/", inputPort.name, "/", inputDevice.name, "/", inputMapping.name}.replace(" ", "");
inputMapping.assignment = settings(inputMapping.path).text();
inputMapping.bind();
}
}
}
}
appendHotkeys();
}
Update to v099r10 release. byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access.
2016-06-26 08:54:12 +00:00
//Emulator::Interface::inputPoll() needs to call into InputManager::InputEmulator
//this function is calling during Program::loadMedium() to link the two together
auto InputManager::bind(Emulator::Interface* interface) -> void {
this->emulator = nullptr;
for(auto& emulator : emulators) {
if(emulator.interface == interface) {
this->emulator = &emulator;
}
}
assert(this->emulator != nullptr);
}
auto InputManager::bind() -> void {
for(auto& emulator : emulators) {
for(auto& port : emulator.ports) {
for(auto& device : port.devices) {
for(auto& mapping : device.mappings) {
Update to v099r10 release. byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access.
2016-06-26 08:54:12 +00:00
mapping.bind();
}
}
}
}
for(auto& hotkey : hotkeys) {
hotkey->bind();
}
}
auto InputManager::poll() -> 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
//polling actual hardware is very time-consuming: skip call if poll was called too recently
auto thisPoll = chrono::millisecond();
if(thisPoll - lastPoll < frequency) return;
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
lastPoll = thisPoll;
auto devices = input->poll();
bool changed = devices.size() != this->devices.size();
Update to v099r10 release. byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access.
2016-06-26 08:54:12 +00:00
if(!changed) {
for(auto n : range(devices)) {
changed = devices[n] != this->devices[n];
if(changed) break;
}
}
Update to v099r10 release. byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access.
2016-06-26 08:54:12 +00:00
if(changed) {
this->devices = devices;
bind();
}
}
auto InputManager::onChange(shared_pointer<HID::Device> device, uint group, uint input, int16_t oldValue, int16_t newValue) -> void {
if(settingsManager->focused()) {
settingsManager->input.inputEvent(device, group, input, oldValue, newValue);
settingsManager->hotkeys.inputEvent(device, group, input, oldValue, newValue);
}
}
auto InputManager::quit() -> void {
emulators.reset();
hotkeys.reset();
}
auto InputManager::findMouse() -> shared_pointer<HID::Device> {
for(auto& device : devices) {
if(device->isMouse()) return device;
}
return {};
}