Hi all,
I converted the Mouse demo, from the SDL demo page, to JEDI-SDL and
noticed that the Mouse response is a little slugish.
I noticed it uses SDL_PollEvent, is this the bottle neck?
To get a more lively response from the Mouse, should one use PumpEvents
or is this something I should live with?
What do the professionals use to get a more responsive Mouse.
Thanks,
Dominique Louis
http://www.DelphiGamer.com := for all your Delphi/Kylix game development
needs;
Hi all,
I converted the Mouse demo, from the SDL demo page, to JEDI-SDL and
noticed that the Mouse response is a little slugish.
I noticed it uses SDL_PollEvent, is this the bottle neck?To get a more lively response from the Mouse, should one use PumpEvents
or is this something I should live with?
I really do not think the most time is spent in getting mouse events. I
assume your source code looks like that:
Repeat
Get events
Do many things (update screen, call the game engine…)
Until the user wants to quit
The mouse will feel unresponsive if the time needed to execute the loop
once is too high. Get events might be the case, but it is way much more
likely that “Do many things” is what takes time.
What do the professionals use to get a more responsive Mouse.
They write faster code ? ;)On Sat, 8 Sep 2001, Dominique Louis wrote:
–
Johann Deneux
Top10 Racing Simulation: http://savannah.gnu.org/projects/top10/
Force feedback for linux: http://www.esil.univ-mrs.fr/~jdeneux/projects/ff
Hi Johann,
Thanks for your wuick response. Below is the loop I am using, would
you be able to point out where exactly the bottleneck may be. As I do
not have extensive SDL experience I cannot see what may be causing the
problem.
Though the code is Object Pascal I am sure you will be able to follow it
( assuming you are a C/C++ programmer )…
while not done do
begin
SDL_GetMouseState(x, y);
while (SDL_PollEvent(@event) = 1) do
begin
case event.type_ of
SDL_QUITEV:
begin
done := true;
end;
SDL_MOUSEBUTTONDOWN:
begin
if (x > SCREEN_WIDTH - button1.w) and (x < SCREEN_WIDTH)
and (y > SCREEN_HEIGHT - button1.h) and (y < SCREEN_HEIGHT) then
done := true;
if (x > 0) and (x < button2.w) then
begin
if (y > 0) and (y < button2.h) then
begin
if translucent then
SDL_SetAlpha(cursor, SDL_SRCALPHA, 255)
else
SDL_SetAlpha(cursor, SDL_SRCALPHA, 127);
translucent := not translucent;
end;
end;
// Update just the part of the display that we've changed
SDL_UpdateRect(screen_, x, y, 1, 1);
end;
end;
end; //(SDL_PollEvent(@event) = 1)
keys := PKeyStateArr(SDL_GetKeyState(nil));
if keys[SDLK_ESCAPE] = SDL_PRESSED then
done := True;
get_bg(cursor_save, x, y);
RS_Blit(cursor, x, y);
SDL_UpdateRect(screen_, 0, 0, 0, 0);
RS_Blit(cursor_save, x, y);
end;
Thanks,
Dominique
http://www.DelphiGamer.com := for all your Delphi/Kylix game development
needs;
Johann Deneux wrote:> On Sat, 8 Sep 2001, Dominique Louis wrote:
Hi all,
I converted the Mouse demo, from the SDL demo page, to JEDI-SDL and
noticed that the Mouse response is a little slugish.
I noticed it uses SDL_PollEvent, is this the bottle neck?To get a more lively response from the Mouse, should one use PumpEvents
or is this something I should live with?I really do not think the most time is spent in getting mouse events. I
assume your source code looks like that:Repeat
Get events
Do many things (update screen, call the game engine…)
Until the user wants to quitThe mouse will feel unresponsive if the time needed to execute the loop
once is too high. Get events might be the case, but it is way much more
likely that “Do many things” is what takes time.What do the professionals use to get a more responsive Mouse.
They write faster code ?
Salut Dominique,
i guess when you are getting mouse position by GetMouseState
you should get buttons state from it too, otherwise you may get the position
active, but event is in queue.
you shouldn’t update when there’s no need to update.
Watch your code. It will speed up for sure. :@)
mao
[…]
while not done do
begin
SDL_GetMouseState(x, y);
This is a potential bug, I think; make sure not to mix old and new
position and button data this way, or you’ll get bugs of the kind “But
that’s not where I clicked!” on slow systems. 
while (SDL_PollEvent(@event) = 1) do begin case event.type_ of
[…]
SDL_MOUSEBUTTONDOWN: begin
[…]
// Update just the part of the display that we've changed SDL_UpdateRect(screen_, x, y, 1, 1); end;
Don’t! You should generally not touch the screen (or do anything else
that might be time consuming) until you’ve processed all events in the
queue, to avoid lag.
end; end; //(SDL_PollEvent(@event) = 1) keys := PKeyStateArr(SDL_GetKeyState(nil)); if keys[SDLK_ESCAPE] = SDL_PRESSED then done := True;
Not a big issue, but this is not a particularly nice way of doing it.
Pressing the escape key to exit an application would normally be expected
to be an “event style” input, as opposed to a “state style” input.
In many cases you won’t know the difference, but you will know the
difference if the program stalls long enough that you manage to press
and release the button between two successive passages through this
code. (In short; key presses seem to be ignored.)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Sunday 09 September 2001 23:31, Dominique Louis wrote:
Hi David,
Thanks for the tips, It certainly is more responsive now :)!
I have moved the check for the ESCAPE key, into the SDL_KEYDOWN event as
suggested. Also, all the screenupdates now take place outside the
PumpEvents loop.
Just what I needed.
Thanks again,
Dominique Louis
http://www.DelphiGamer.com := for all your Delphi/Kylix game development
needs;
David Olofson wrote:> On Sunday 09 September 2001 23:31, Dominique Louis wrote:
[…]
while not done do
begin
SDL_GetMouseState(x, y);This is a potential bug, I think; make sure not to mix old and new
position and button data this way, or you’ll get bugs of the kind “But
that’s not where I clicked!” on slow systems.while (SDL_PollEvent(@event) = 1) do begin case event.type_ of[…]
SDL_MOUSEBUTTONDOWN: begin[…]
// Update just the part of the display that we've changed SDL_UpdateRect(screen_, x, y, 1, 1); end;Don’t! You should generally not touch the screen (or do anything else
that might be time consuming) until you’ve processed all events in the
queue, to avoid lag.end; end; //(SDL_PollEvent(@event) = 1) keys := PKeyStateArr(SDL_GetKeyState(nil)); if keys[SDLK_ESCAPE] = SDL_PRESSED then done := True;Not a big issue, but this is not a particularly nice way of doing it.
Pressing the escape key to exit an application would normally be expected
to be an “event style” input, as opposed to a “state style” input.In many cases you won’t know the difference, but you will know the
difference if the program stalls long enough that you manage to press
and release the button between two successive passages through this
code. (In short; key presses seem to be ignored.)//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
