feedc0de/dolphin
1
0
Fork 0
forked from dolphin-emu/dolphin
Code Pull Requests Activity
Files
99f537d499f07b1301e14ddbe454f15635a3396f
dolphin/Source/Core/InputCommon/ControllerEmu/ControlGroup/ModifySettingsButton.cpp

78 lines
2.1 KiB
C++
Raw Normal View History

ControllerEmu: Separate ControlGroup from ControllerEmu ControllerEmu, the class, is essentially acting like a namespace for ControlGroup. This makes it impossible to forward declare any of the internals. It also globs a bunch of classes together which is kind of a pain to manage. This splits ControlGroup and the classes it contains into their own source files and situates them all within a namespace, which gets them out of global scope. Since this allows forward declarations for the once-internal classes, it now requires significantly less files to be rebuilt if anything is changed in the ControllerEmu portion of code. It does not split out the settings classes yet, however, as it would be preferable to make a settings base class that all settings derive from, but this would be a functional change -- this commit only intends to move around existing code. Extracting the settings class will be done in another commit.
2017-02-08 22:15:43 -05:00
// Copyright 2017 Dolphin Emulator Project
// Licensed under GPLv2+
// Refer to the license.txt file included.
#include "InputCommon/ControllerEmu/ControlGroup/ModifySettingsButton.h"
#include <cstddef>
#include <memory>
#include <string>
#include <utility>
#include "Common/Common.h"
#include "InputCommon/ControlReference/ControlReference.h"
#include "InputCommon/ControllerEmu/Control/Control.h"
#include "InputCommon/ControllerEmu/Control/Input.h"
InputCommon: move Setting classes out of ControlGroup
2017-02-26 12:00:24 -08:00
#include "InputCommon/ControllerEmu/Setting/NumericSetting.h"
ControllerEmu: Separate ControlGroup from ControllerEmu ControllerEmu, the class, is essentially acting like a namespace for ControlGroup. This makes it impossible to forward declare any of the internals. It also globs a bunch of classes together which is kind of a pain to manage. This splits ControlGroup and the classes it contains into their own source files and situates them all within a namespace, which gets them out of global scope. Since this allows forward declarations for the once-internal classes, it now requires significantly less files to be rebuilt if anything is changed in the ControllerEmu portion of code. It does not split out the settings classes yet, however, as it would be preferable to make a settings base class that all settings derive from, but this would be a functional change -- this commit only intends to move around existing code. Extracting the settings class will be done in another commit.
2017-02-08 22:15:43 -05:00
#include "VideoCommon/OnScreenDisplay.h"
namespace ControllerEmu
{
ModifySettingsButton::ModifySettingsButton(std::string button_name)
: Buttons(std::move(button_name))
{
}
void ModifySettingsButton::AddInput(std::string button_name, bool toggle)
{
ControllerEmu: Use enum instead of bool for translatability
2018-04-10 17:22:30 +02:00
controls.emplace_back(std::make_unique<Input>(Translate, std::move(button_name)));
ControllerEmu: Separate ControlGroup from ControllerEmu ControllerEmu, the class, is essentially acting like a namespace for ControlGroup. This makes it impossible to forward declare any of the internals. It also globs a bunch of classes together which is kind of a pain to manage. This splits ControlGroup and the classes it contains into their own source files and situates them all within a namespace, which gets them out of global scope. Since this allows forward declarations for the once-internal classes, it now requires significantly less files to be rebuilt if anything is changed in the ControllerEmu portion of code. It does not split out the settings classes yet, however, as it would be preferable to make a settings base class that all settings derive from, but this would be a functional change -- this commit only intends to move around existing code. Extracting the settings class will be done in another commit.
2017-02-08 22:15:43 -05:00
threshold_exceeded.emplace_back(false);
associated_settings.emplace_back(false);
associated_settings_toggle.emplace_back(toggle);
}
void ModifySettingsButton::GetState()
{
for (size_t i = 0; i < controls.size(); ++i)
{
ControlState state = controls[i]->control_ref->State();
if (!associated_settings_toggle[i])
{
// not toggled
ControllerEmu: Killed the Buttons group threshold setting.
2018-12-31 07:31:11 -06:00
associated_settings[i] = state > ACTIVATION_THRESHOLD;
ControllerEmu: Separate ControlGroup from ControllerEmu ControllerEmu, the class, is essentially acting like a namespace for ControlGroup. This makes it impossible to forward declare any of the internals. It also globs a bunch of classes together which is kind of a pain to manage. This splits ControlGroup and the classes it contains into their own source files and situates them all within a namespace, which gets them out of global scope. Since this allows forward declarations for the once-internal classes, it now requires significantly less files to be rebuilt if anything is changed in the ControllerEmu portion of code. It does not split out the settings classes yet, however, as it would be preferable to make a settings base class that all settings derive from, but this would be a functional change -- this commit only intends to move around existing code. Extracting the settings class will be done in another commit.
2017-02-08 22:15:43 -05:00
}
else
{
// toggle (loading savestates does not en-/disable toggle)
// after we passed the threshold, we en-/disable. but after that, we don't change it
// anymore
ControllerEmu: Killed the Buttons group threshold setting.
2018-12-31 07:31:11 -06:00
if (!threshold_exceeded[i] && state > ACTIVATION_THRESHOLD)
ControllerEmu: Separate ControlGroup from ControllerEmu ControllerEmu, the class, is essentially acting like a namespace for ControlGroup. This makes it impossible to forward declare any of the internals. It also globs a bunch of classes together which is kind of a pain to manage. This splits ControlGroup and the classes it contains into their own source files and situates them all within a namespace, which gets them out of global scope. Since this allows forward declarations for the once-internal classes, it now requires significantly less files to be rebuilt if anything is changed in the ControllerEmu portion of code. It does not split out the settings classes yet, however, as it would be preferable to make a settings base class that all settings derive from, but this would be a functional change -- this commit only intends to move around existing code. Extracting the settings class will be done in another commit.
2017-02-08 22:15:43 -05:00
{
associated_settings[i] = !associated_settings[i];
if (associated_settings[i])
Don't translate button names Since these button names are printed on all real controllers, we should show them in the same way as they are printed on the controllers, regardless of the user's language. It seems like this was intended all along (except for "Start"), but the _ markers in TASInputDlg.cpp (accidentally?) led to the button names in the controller configs also becoming translatable. I'm making exceptions for "L" and "R" because translators may want to mark them in some way (for instance "L-Digital") to clarify the difference from "L-Analog" and "R-Analog". I'm also making an exception for START/PAUSE because it's referred to as スタート in Japanese games. I'm changing "Home" and "Start" to uppercase for consistency with how Nintendo refers to those buttons, and because someone who isn't familiar with the Latin script might not know the connection between the lowercase and uppercase letters (most users likely do know the connection, but we shouldn't assume it), and because leaving "Start" as "Start" makes it "collide" with unrelated strings, such as the string for the button that starts a netplay session. To rename "Start" and "Home" without breaking INI compatibility, I added a ui_name variable like in f5c82ad.
2017-04-30 14:53:33 +02:00
OSD::AddMessage(controls[i]->ui_name + ": on");
ControllerEmu: Separate ControlGroup from ControllerEmu ControllerEmu, the class, is essentially acting like a namespace for ControlGroup. This makes it impossible to forward declare any of the internals. It also globs a bunch of classes together which is kind of a pain to manage. This splits ControlGroup and the classes it contains into their own source files and situates them all within a namespace, which gets them out of global scope. Since this allows forward declarations for the once-internal classes, it now requires significantly less files to be rebuilt if anything is changed in the ControllerEmu portion of code. It does not split out the settings classes yet, however, as it would be preferable to make a settings base class that all settings derive from, but this would be a functional change -- this commit only intends to move around existing code. Extracting the settings class will be done in another commit.
2017-02-08 22:15:43 -05:00
else
Don't translate button names Since these button names are printed on all real controllers, we should show them in the same way as they are printed on the controllers, regardless of the user's language. It seems like this was intended all along (except for "Start"), but the _ markers in TASInputDlg.cpp (accidentally?) led to the button names in the controller configs also becoming translatable. I'm making exceptions for "L" and "R" because translators may want to mark them in some way (for instance "L-Digital") to clarify the difference from "L-Analog" and "R-Analog". I'm also making an exception for START/PAUSE because it's referred to as スタート in Japanese games. I'm changing "Home" and "Start" to uppercase for consistency with how Nintendo refers to those buttons, and because someone who isn't familiar with the Latin script might not know the connection between the lowercase and uppercase letters (most users likely do know the connection, but we shouldn't assume it), and because leaving "Start" as "Start" makes it "collide" with unrelated strings, such as the string for the button that starts a netplay session. To rename "Start" and "Home" without breaking INI compatibility, I added a ui_name variable like in f5c82ad.
2017-04-30 14:53:33 +02:00
OSD::AddMessage(controls[i]->ui_name + ": off");
ControllerEmu: Separate ControlGroup from ControllerEmu ControllerEmu, the class, is essentially acting like a namespace for ControlGroup. This makes it impossible to forward declare any of the internals. It also globs a bunch of classes together which is kind of a pain to manage. This splits ControlGroup and the classes it contains into their own source files and situates them all within a namespace, which gets them out of global scope. Since this allows forward declarations for the once-internal classes, it now requires significantly less files to be rebuilt if anything is changed in the ControllerEmu portion of code. It does not split out the settings classes yet, however, as it would be preferable to make a settings base class that all settings derive from, but this would be a functional change -- this commit only intends to move around existing code. Extracting the settings class will be done in another commit.
2017-02-08 22:15:43 -05:00
threshold_exceeded[i] = true;
}
ControllerEmu: Killed the Buttons group threshold setting.
2018-12-31 07:31:11 -06:00
if (state < ACTIVATION_THRESHOLD)
ControllerEmu: Separate ControlGroup from ControllerEmu ControllerEmu, the class, is essentially acting like a namespace for ControlGroup. This makes it impossible to forward declare any of the internals. It also globs a bunch of classes together which is kind of a pain to manage. This splits ControlGroup and the classes it contains into their own source files and situates them all within a namespace, which gets them out of global scope. Since this allows forward declarations for the once-internal classes, it now requires significantly less files to be rebuilt if anything is changed in the ControllerEmu portion of code. It does not split out the settings classes yet, however, as it would be preferable to make a settings base class that all settings derive from, but this would be a functional change -- this commit only intends to move around existing code. Extracting the settings class will be done in another commit.
2017-02-08 22:15:43 -05:00
threshold_exceeded[i] = false;
}
}
}
const std::vector<bool>& ModifySettingsButton::isSettingToggled() const
{
return associated_settings_toggle;
}
const std::vector<bool>& ModifySettingsButton::getSettingsModifier() const
{
return associated_settings;
}
} // namespace ControllerEmu
Copy Permalink