I’ve got a kind of stupid problem: when, in the menu of my game, I click
on New Game, the events are handled by the menu and the game starts,
but when I release the clicked button, the events are handled by the
game control function, and the mouse buttons are used to move the model
around the OpenGL modelview, this way:
if(event.type == SDL_MOUSEBUTTONDOWN){
if(event.button.button == SDL_BUTTON_LEFT)
translating++;
else if(event.button.button == SDL_BUTTON_RIGHT)
translating–;
}
else if(event.type == SDL_MOUSEBUTTONUP){
if(event.button.button == SDL_BUTTON_LEFT)
translating–;
else if(event.button.button == SDL_BUTTON_RIGHT)
translating++;
}
When ‘translating’ is 0, the model do not move, when it is > 0, the
model gets closer to the camera and when it is < 0, the model gets more
distant from the camera.
The left button release event turns ‘translating’ to -1 and the model
starts moving forever.
I do not want to change the ‘–’ and ‘++’ system I am using, it is good
when the user try to move the model with multiple events.
Is there any idea on how can I solve this problem?–
Lucas Clemente Vella
@Lucas_Clemente_Vella
Hi,
I see a few ways to fix your problem:
-
Validate the choices in the menu using release events instead of press
events. This way, the game will not receive the release button event.
-
Ignore the first release button event you receive in the game. This should
be ok, because a release event does not usually occur without a press event
first.
-
Read all events from the queue to drop them before starting the game.
Otherwise, If the player start clicking everywhere while the game is loading
because he is impatient, it would probably do undesired things once the game
start.
I think 3 is the best choice, even if there is no loading time between the
menu and the game.
Regards,
Raphael AssenatOn October 13, 2004 08:35 am, Lucas Clemente Vella wrote:
I’ve got a kind of stupid problem: when, in the menu of my game, I click
on New Game, the events are handled by the menu and the game starts,
but when I release the clicked button, the events are handled by the
game control function, and the mouse buttons are used to move the model
around the OpenGL modelview, this way:
if(event.type == SDL_MOUSEBUTTONDOWN){
if(event.button.button == SDL_BUTTON_LEFT)
translating++;
else if(event.button.button == SDL_BUTTON_RIGHT)
translating–;
}
else if(event.type == SDL_MOUSEBUTTONUP){
if(event.button.button == SDL_BUTTON_LEFT)
translating–;
else if(event.button.button == SDL_BUTTON_RIGHT)
translating++;
}
When ‘translating’ is 0, the model do not move, when it is > 0, the
model gets closer to the camera and when it is < 0, the model gets more
distant from the camera.
The left button release event turns ‘translating’ to -1 and the model
starts moving forever.
I do not want to change the ‘–’ and ‘++’ system I am using, it is good
when the user try to move the model with multiple events.
Is there any idea on how can I solve this problem?
Thank you, I had not thought about the 3.
Rapha?l Ass?nat wrote:> Hi,
I see a few ways to fix your problem:
-
Validate the choices in the menu using release events instead of press
events. This way, the game will not receive the release button event.
-
Ignore the first release button event you receive in the game. This should
be ok, because a release event does not usually occur without a press event
first.
-
Read all events from the queue to drop them before starting the game.
Otherwise, If the player start clicking everywhere while the game is loading
because he is impatient, it would probably do undesired things once the game
start.
I think 3 is the best choice, even if there is no loading time between the
menu and the game.
Regards,
Raphael Assenat
–
Lucas Clemente Vella
@Lucas_Clemente_Vella
Hi,
Rapha?l Ass?nat wrote:
- Read all events from the queue to drop them before starting the game.
Otherwise, If the player start clicking everywhere while the game is loading
because he is impatient, it would probably do undesired things once the game
start.
I think 3 is the best choice, even if there is no loading time between the
menu and the game.
I see a problem with 3, because the game may start while the button is
still pressed, so the release event occurs after the flush. Flushing the
queue won’t help then.
Sebastian
You’re right, flushing the queue would not work then.
Ignoring the first release event (2) would work better than only flushing the
queue(3), but doing both (3 followed by 2) is even better in my opinion,
because it will prevent undesired operations of occuring, should many events
be queued before the game starts.
Regards,
Raphael AssenatOn October 13, 2004 11:08 am, Sebastian Beschke wrote:
Hi,
Rapha?l Ass?nat wrote:
- Read all events from the queue to drop them before starting the game.
Otherwise, If the player start clicking everywhere while the game is
loading because he is impatient, it would probably do undesired things
once the game start.
I think 3 is the best choice, even if there is no loading time between
the menu and the game.
I see a problem with 3, because the game may start while the button is
still pressed, so the release event occurs after the flush. Flushing the
queue won’t help then.
Rapha?l Ass?nat <raph at 8d.com> wrote:
- Read all events from the queue to drop them before starting the
game. Otherwise, If the player start clicking everywhere while the
game is loading because he is impatient, it would probably do
undesired things once the game start.
I think 3 is the best choice, even if there is no loading time
between the menu and the game.
I see a problem with 3, because the game may start while the button
is still pressed, so the release event occurs after the flush.
Flushing the queue won’t help then.
You’re right, flushing the queue would not work then.
Ignoring the first release event (2) would work better than only
flushing the queue(3), but doing both (3 followed by 2) is even better
in my opinion, because it will prevent undesired operations of
occuring, should many events be queued before the game starts.
maybe 2 follows 3 would be even better. every GUI tookit i know react on
button release events. so when the user clicks the button and then
changes his mind he may pull the mouspointer from the button and release
it outside of the click area to “cancel” the click.
clemens
That’s what I meant with (1).
GUI toolkits usually react on release events for buttons, but sometimes
widgets react to buttondown events(in kde/qt, items in the menubar and tabs
react on buttondown).
Reacting on release is good because the user may change it’s mind, but
sometimes this make the gui feel less responsive because the action occurs
later. I once had to code a tabpane, and made the tabs react to release
events first, and it felt less responsive than if they reacted when pressed.
Regards,
Raphael AssenatOn October 13, 2004 02:13 pm, Clemens Kirchgatterer wrote:
Rapha?l Ass?nat <@Raphael_Assenat> wrote:
- Read all events from the queue to drop them before starting the
game. Otherwise, If the player start clicking everywhere while the
game is loading because he is impatient, it would probably do
undesired things once the game start.
I think 3 is the best choice, even if there is no loading time
between the menu and the game.
I see a problem with 3, because the game may start while the button
is still pressed, so the release event occurs after the flush.
Flushing the queue won’t help then.
You’re right, flushing the queue would not work then.
Ignoring the first release event (2) would work better than only
flushing the queue(3), but doing both (3 followed by 2) is even better
in my opinion, because it will prevent undesired operations of
occuring, should many events be queued before the game starts.
maybe 2 follows 3 would be even better. every GUI tookit i know react on
button release events. so when the user clicks the button and then
changes his mind he may pull the mouspointer from the button and release
it outside of the click area to “cancel” the click.
Flush the queue, and replace the stateful “counting” with runtime computation,
which is more robust since it won’t become confused as easily:
int GetTranslating()
{
int state = SDL_GetMouseState(NULL, NULL)
int i = 0;
if ( state & SDL_BUTTON_LMASK )
++i;
if ( state & SDL_BUTTON_RMASK )
–i;
return i;
}
In general, it helps to reduce the amount of state: deriving state from
other state, instead of tracking it separately, reduces the ways you can
become desynchronized.On Wed, Oct 13, 2004 at 05:08:49PM +0200, Sebastian Beschke wrote:
- Read all events from the queue to drop them before starting the game.
Otherwise, If the player start clicking everywhere while the game is
loading because he is impatient, it would probably do undesired things
once the game start.
I think 3 is the best choice, even if there is no loading time between the
menu and the game.
I see a problem with 3, because the game may start while the button is
still pressed, so the release event occurs after the flush. Flushing the
queue won’t help then.
–
Glenn Maynard