You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand SFML's scope and believe the feature fits it
Describe your feature request here
In #2990 and event-related PRs, there was some discussion about providing a sf::Event::visit function. Would it actually be worth it?
Here are two examples of what could be achieved with such a function. Note that both examples are based on #2992, which I believe it's the right way forward for events anyway.
First of all, the user defines this convenience function:
voidpollEvents(sf::Window& window, auto... lambdas)
{
auto visitor = overload(lambdas...);
while (const std::optional event = window.pollEvent())
event.visit(visitor);
}
Now, example 1:
////// CURRENT API while (window.isOpen())
{
while (const std::optional event = window.pollEvent())
{
if (event->is<sf::Event::Closed>())
{
window.close();
break;
}
if (constauto* keyPressed = event->getIf<sf::Event::KeyPressed>();
keyPressed && keyPressed->code == sf::Keyboard::Key::Escape)
{
window.close();
break;
}
}
}
////// WITH VISITATIONwhile (window.isOpen())
{
pollEvents(window,
[&](sf::Event::Closed)
{
window.close();
},
[&](sf::Event::KeyPressed e)
{
if (e.code == sf::Keyboard::Key::Escape)
window.close();
}
);
}
Example 2 (from Tennis):
////// CURRENT APIwhile (constauto event = window.pollEvent())
{
// Window closed or escape key pressed: exitif (event.is<sf::Event::Closed>() || (event.is<sf::Event::KeyPressed>() &&
event.getIf<sf::Event::KeyPressed>()->code == sf::Keyboard::Key::Escape))
{
window.close();
break;
}
// Space key pressed: playif ((event.is<sf::Event::KeyPressed>() && event.getIf<sf::Event::KeyPressed>()->code == sf::Keyboard::Key::Space) ||
event.is<sf::Event::TouchBegan>())
{
if (!isPlaying)
{
// (re)start the game
isPlaying = true;
clock.restart();
// Reset the position of the paddles and ball
leftPaddle.setPosition({10.f + paddleSize.x / 2.f, gameHeight / 2.f});
rightPaddle.setPosition({gameWidth - 10.f - paddleSize.x / 2.f, gameHeight / 2.f});
ball.setPosition({gameWidth / 2.f, gameHeight / 2.f});
// Reset the ball angledo
{
// Make sure the ball initial angle is not too much vertical
ballAngle = sf::degrees(std::uniform_real_distribution<float>(0, 360)(rng));
} while (std::abs(std::cos(ballAngle.asRadians())) < 0.7f);
}
}
// Window size changed, adjust view appropriatelyif (event.is<sf::Event::Resized>())
{
sf::View view;
view.setSize({gameWidth, gameHeight});
view.setCenter({gameWidth / 2.f, gameHeight / 2.f});
window.setView(view);
}
}
////// WITH VISITATIONauto playAction = [&]
{
if (!isPlaying)
{
// (re)start the game
isPlaying = true;
clock.restart();
// Reset the position of the paddles and ball
leftPaddle.setPosition({10.f + paddleSize.x / 2.f, gameHeight / 2.f});
rightPaddle.setPosition({gameWidth - 10.f - paddleSize.x / 2.f, gameHeight / 2.f});
ball.setPosition({gameWidth / 2.f, gameHeight / 2.f});
// Reset the ball angledo
{
// Make sure the ball initial angle is not too much vertical
ballAngle = sf::degrees(std::uniform_real_distribution<float>(0, 360)(rng));
} while (std::abs(std::cos(ballAngle.asRadians())) < 0.7f);
}
};
pollEvents(window,
[&](sf::Event::Closed)
{
window.close();
},
[&](sf::Event::KeyPressed e)
{
if (e.code == sf::Keyboard::Key::Escape)
window.close();
elseif (e.code == sf::Keyboard::Key::Space)
playAction();
},
[&](sf::Event::TouchBegan)
{
playAction();
}
[&](sf::Event::Resized)
{
sf::View view;
view.setSize({gameWidth, gameHeight});
view.setCenter({gameWidth / 2.f, gameHeight / 2.f});
window.setView(view);
}
);
I kinda like it. Thoughts?
Observations:
pollEvents makes a sf::Event::visit much more compelling.
Yes, every lambda needs to capture, but [&] is safe in this context.
Repeated actions need to be extracted such as for playAction. Not a big deal, might actually promote good coding practices.
All the "empty state" or "optional has_value" BS disappears.
Use Cases
N/A
API Example
No response
The text was updated successfully, but these errors were encountered:
Prerequisite Checklist
Describe your feature request here
In #2990 and event-related PRs, there was some discussion about providing a
sf::Event::visit
function. Would it actually be worth it?Here are two examples of what could be achieved with such a function. Note that both examples are based on #2992, which I believe it's the right way forward for events anyway.
First of all, the user defines this convenience function:
Now, example 1:
Example 2 (from Tennis):
I kinda like it. Thoughts?
Observations:
pollEvents
makes asf::Event::visit
much more compelling.[&]
is safe in this context.playAction
. Not a big deal, might actually promote good coding practices.has_value
" BS disappears.Use Cases
N/A
API Example
No response
The text was updated successfully, but these errors were encountered: