A long time ago I wrote a very silly game which nevertheless got a bit
of a cult following in my friend circle. As a result, I rewrote it in C
using SDL several years ago. Recently I was asked if I could provide a
MacOS X version; since I don’t have a Mac handy I cross-compiled it on
Linux using the darwinx toolchain for Fedora:
Since then I have gotten the feedback that “everything works, except the
keyboard is very unresponsive; it often takes four or five attempts to
get the player icon to change direction.”
I am wondering if this is a known problem, or if there is something I am
doing plain wrong. The game works as intended on Windows or Linux.
I built your game on MacOSX and indeed it is unresponsive.
The thing on MacOSX is that your SDL program must call either
SDL_WaitEvent() or SDL_PollEvent() often to play nice with
MacOSX’s native event loops and what not.
Somehow your game spends a lot of time between calls
to SDL_WaitEvent() updating the screen (I think). If I comment
out lprint() calls inside the move_ghouls() function – lines 614, 615
within play.c file – then keyboard input becomes responsive.
Atis
Message: 3Date: Tue, 06 Mar 2012 11:26:34 -0800
From: hpa@zytor.com (H. Peter Anvin)
To: sdl at lists.libsdl.org
Subject: [SDL] MacOS X + SDL 1.2.15 = unresponsive keyboard?
Message-ID: <4F5664EA.60800 at zytor.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
A long time ago I wrote a very silly game which nevertheless got a bit
of a cult following in my friend circle. As a result, I rewrote it in C
using SDL several years ago. Recently I was asked if I could provide a
MacOS X version; since I don’t have a Mac handy I cross-compiled it on
Linux using the darwinx toolchain for Fedora:
Since then I have gotten the feedback that “everything works, except the
keyboard is very unresponsive; it often takes four or five attempts to
get the player icon to change direction.”
I am wondering if this is a known problem, or if there is something I am
doing plain wrong. The game works as intended on Windows or Linux.
Interesting… thanks for the tidbit. I will have to see if I can
figure out why it is burning so much time; I might have taken some
unnecessary shortcuts in the screen update handling.
-hpaOn 03/06/2012 02:49 PM, Atis wrote:
Hi,
I built your game on MacOSX and indeed it is unresponsive.
The thing on MacOSX is that your SDL program must call either
SDL_WaitEvent() or SDL_PollEvent() often to play nice with
MacOSX’s native event loops and what not.
Somehow your game spends a lot of time between calls
to SDL_WaitEvent() updating the screen (I think). If I comment
out lprint() calls inside the move_ghouls() function – lines 614, 615
within play.c file – then keyboard input becomes responsive.
I took a peek at the code you linked and could not draw solid conclusions from it without looking around more, but use of SDL_WaitEvent is something I’m not familiar with.
All the games I’ve written use SDL_PollEvent in a while loop, then update the graphics, then sleep for a certain amount of time (how much depending on the desired framerate and how much time has
passed since the previous frame).
Perhaps SDL_WaitEvent is being used incorrectly? I can’t say, but that is my suspicion.On 03/06/2012 02:49 PM, Atis wrote:
Hi,
I built your game on MacOSX and indeed it is unresponsive.
The thing on MacOSX is that your SDL program must call either
SDL_WaitEvent() or SDL_PollEvent() often to play nice with
MacOSX’s native event loops and what not.
Somehow your game spends a lot of time between calls
to SDL_WaitEvent() updating the screen (I think). If I comment
out lprint() calls inside the move_ghouls() function – lines 614, 615
within play.c file – then keyboard input becomes responsive.
Atis
Message: 3
Date: Tue, 06 Mar 2012 11:26:34 -0800
From: “H. Peter Anvin”
To: sdl at lists.libsdl.org
Subject: [SDL] MacOS X + SDL 1.2.15 = unresponsive keyboard?
Message-ID: <4F5664EA.60800 at zytor.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
A long time ago I wrote a very silly game which nevertheless got a bit
of a cult following in my friend circle. As a result, I rewrote it in C
using SDL several years ago. Recently I was asked if I could provide a
MacOS X version; since I don’t have a Mac handy I cross-compiled it on
Linux using the darwinx toolchain for Fedora:
Since then I have gotten the feedback that “everything works, except the
keyboard is very unresponsive; it often takes four or five attempts to
get the player icon to change direction.”
I am wondering if this is a known problem, or if there is something I am
doing plain wrong. The game works as intended on Windows or Linux.
–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
I took a peek at the code you linked and could not draw solid conclusions from it without looking around more, but use of SDL_WaitEvent is something I’m not familiar with.
All the games I’ve written use SDL_PollEvent in a while loop, then update the graphics, then sleep for a certain amount of time (how much depending on the desired framerate and how much time has
passed since the previous frame).
Perhaps SDL_WaitEvent is being used incorrectly? I can’t say, but that is my suspicion.
I changed the screen handling so instead of calling SDL_UpdateRect() on
individual pieces it keeps a dirty map, and does a single call to
SDL_UpdateRects() right before going into a delay or event wait loop.
This seems to have fixed MacOS X. The above piece was a critical piece
of information.
Thanks!
-hpaOn 03/06/2012 02:49 PM, Atis wrote:
Hi,
I built your game on MacOSX and indeed it is unresponsive.
The thing on MacOSX is that your SDL program must call either
SDL_WaitEvent() or SDL_PollEvent() often to play nice with
MacOSX’s native event loops and what not.
Somehow your game spends a lot of time between calls
to SDL_WaitEvent() updating the screen (I think). If I comment
out lprint() calls inside the move_ghouls() function – lines 614, 615
within play.c file – then keyboard input becomes responsive.