Conversation
karnkaul
force-pushed
the
controller_refactor
branch
from
0ad6d93 to
b50fc93
Compare
swagween
left a comment
swagween
left a comment
There was a problem hiding this comment.
Left some questions for my own curiosity
| m_player_controller.bind_throttle("move_x", {.lo = bave::Key::eA, .hi = bave::Key::eD}); | ||
| m_player_controller.bind_throttle("move_y", {.lo = bave::Key::eDown, .hi = bave::Key::eUp}); | ||
| m_player_controller.bind_throttle("move_y", {.lo = bave::Key::eS, .hi = bave::Key::eW}); | ||
| m_player_controller.bind_key("jump", bave::Key::eSpace); |
There was a problem hiding this comment.
If we wanted to change these in-game (say, settings menu > key binds), how would we go about that? would we have to "unbind" the throttles and keys?
There was a problem hiding this comment.
Correct, we would need a way to remove existing bindings as this class is developed.
| if (throttle.hi == bave::Key::eUnknown) { return; } | ||
| auto it = m_mappings.find(id); | ||
| if (it == m_mappings.end()) { | ||
| auto [i, _] = m_mappings.insert_or_assign(std::string{id}, std::vector<Mapping>{}); |
There was a problem hiding this comment.
could you explain the syntax here? what is [i, _] ?
There was a problem hiding this comment.
That's a structured binding. You can use it to "destructure" an aggregate type or a std::tuple:
struct Foo {
int x{};
char y{};
};
auto f = Foo{42, 'x'};
auto [i, c] = f;
// i == 42, c == 'x'The underscore is just convention for "I don't care about this member", from the language/compiler's point of view it's just an identifier (name of a variable).
| it->second.push_back(throttle); | ||
| } | ||
|
|
||
| void PlayerController::bind_key(std::string_view id, bave::Key key) { |
There was a problem hiding this comment.
so, Throttle is specifically for keys that control a range? if we were making a game with no movement and only jumping, we could theoretically bypass the throttle binding altogether?
There was a problem hiding this comment.
Yeah, couldn't think of a better name. 😅
And yup, if a game only needs single binary input states (0 or 1), there's no real need to associate a pair of keys to a binding.
|
|
||
| auto ret = 0.0f; | ||
| for (auto const& mapping : mappings) { | ||
| // later a visitor will be required here, to handle Throttle vs GamepadAxis vs GamepadButton. |
There was a problem hiding this comment.
what do you mean by "visitor"? is it a design pattern of some kind?
There was a problem hiding this comment.
Yeah it's a general design pattern, but also the first argument of std::visit for std::variant.
There was a problem hiding this comment.
https://en.cppreference.com/w/cpp/utility/variant/visit
Applies the visitor
vis(a Callable that can be called with any combination of types from variants) to the variantsvars.
|
|
||
| auto const& mappings = search->second; | ||
| auto const get_throttle_state = [&](Throttle const throttle) { | ||
| auto const is_pressed = [this](bave::Key const key) { return m_app->get_key_state().is_pressed(key); }; |
There was a problem hiding this comment.
I am not too familiar with lambda functions so this part is a bit confusing to me, but I guess the overall idea is to ignore key presses that aren't in our mapping, and for keys that are we just set the throttle based on whether or not they're pressed?
There was a problem hiding this comment.
Yeah pretty much. Lambdas are very useful! I'd suggest getting familiar, the basics are actually quite straightforward.
| Player::Player(bave::App& app, glm::vec2 const world_space) : m_app(app), m_world_space(world_space) { | ||
| m_sprite.set_size(size_v); | ||
|
|
||
| m_player_controller.bind_throttle("move_x", {.lo = bave::Key::eLeft, .hi = bave::Key::eRight}); |
There was a problem hiding this comment.
what will happen if both "Left" and "Right" are pressed simultaneously?
There was a problem hiding this comment.
"Left" will contribute -1.0f to the throttle, "Right" will contribute +1.0f, and they'll cancel each other out.
As you can imagine, this is a subjective/design level decision, rather than being "more technically correct" over any other approach.
2 participants
No description provided.