The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
New to SDL -- a few questions
soulite


Joined: 12 Jul 2014
Posts: 4
Hello, I am new to SDL and these forums, and I have a few general and specific questions.

(Normally I wouldn't lump a bunch of unrelated questions into one post, but I guess I will for this first post rather than creating many small topics.)

1. There doesn't seem to be any built-in method of limiting the framerate in SDL 2.0.3, is this correct? With VSYNC, my test games seem to run around 60 FPS, but I needed to add a limiter to handle some cases -- such as the stretching transition when switching to FULLSCREEN_DESKTOP on OSX 10.9, during the transition my game logic seemed to briefly run at an unlimited rate.

2. On OSX 10.9, I receive SDL_QUIT events for clicking a window's close button, but not for pressing Cmd+Q or the app's Quit menu item. I thought these were recently added to SDL, like Alt+F4 generates SDL_QUIT on Windows? (Also: any way to detect the Preferences or About menu items?)

3. On an older Mac (OSX 10.5) SDL works and I can switch from windowed to FULLSCREEN_DESKTOP, but if I try to switch back to windowed, the SDL screen disappears and I need to force-quit my game. Anyone else experienced this? Should I write an example program and post a bug report?

4. I believe SDL can detect and enumerate multiple displays, but is there a way to open a window (usually centered) on a specific one?

5. Why would a gamepad give a different name if you use JoystickName versus GameControllerName? For example mine shows up as a "Logitech Dual Action" joystick but a "Generic DirectInput Controller" GameController.

6. I actually answered one of my own questions this morning. I was going to ask if you can read GameController buttons without a SDL window, but I found out that you can indeed if you init EVENTS, JOYSTICK, and GAMECONTROLLER without VIDEO.


Any insight to these questions? Thanks for reading, sorry if this is a convoluted post!
mr_tawan


Joined: 13 Jan 2014
Posts: 161
Hi

For #1, limitting frame rate, the simplest way is to use SDL_Delay() in the render loop. Put the time between frame in as a parameter, which is 1000/framerate:-
Code:

while(true)
{
    ProcessEvent();
    Render();

   SDL_Delay(1000/FRAME_RATE);
}



I actually use `SDL_GetTicks` to get the current time (in millisecond) and compare to the last time the screen is renderered. This is more precise way to do the frame-rate limitting.

Code:

while(true)
{
    ProcessEvent();
    unsigned int currentTime = SDL_GetTicks();
    if (currentTime - lastRenderTime > betweenFrameDuration)
    {
        Render();
        lastRenderTime = currentTime;
    }
    SDL_Delay(0);
}


Where betweenFrameDuration is `1000 / FRAME_RATE` (which 1000 is 1 second). Beaware that `SDL_Delay(0)` is actually an important part of the code as it gives time to other process/thread to run (otherwise it would be a live-lock, the program become unresponsive to the OS and might get killed by the task/process manager).
New to SDL -- a few questions
Andreas Schiffler
Guest

SDL2_gfx has a little helper for this purpose which tracks wallclock time and attempts to calculate delays along a fixed linear timeline to remove any cumulative jitter or drift.

Usage is very simple:

#include "SDL2_framerate.h"
main() {
FPSmanager fpsm;
int rate = 30; // in Hz
SDL_initFramerate(&fpsm);
SDL_setFramerate(&fpsm, rate)
//...
while (drawing) {
//...
int actualDelay = SDL_framerateDelay(fpsm);
}
}


On 7/13/2014 2:16 AM, mr_tawan wrote:

Quote:
Hi

For #1, limitting frame rate, the simplest way is to use SDL_Delay() in the render loop. Put the time between frame in as a parameter, which is 1000/framerate:-







Code:
while(true)
{
ProcessEvent();
Render();

SDL_Delay(1000/FRAME_RATE);
}




I actually use `SDL_GetTicks` to get the current time (in millisecond) and compare to the last time the screen is renderered. This is more precise way to do the frame-rate limitting.








Code:
while(true)
{
ProcessEvent();
unsigned int currentTime = SDL_GetTicks();
if (currentTime - lastRenderTime > betweenFrameDuration)
{
Render();
lastRenderTime = currentTime;
}
SDL_Delay(0);
}



Where betweenFrameDuration is `1000 / FRAME_RATE` (which 1000 is 1 second). Beaware that `SDL_Delay(0)` is actually an important part of the code as it gives time to other process/thread to run (otherwise it would be a live-lock, the program become unresponsive to the OS and might get killed by the task/process manager).


Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
New to SDL -- a few questions
Jeffrey Carpenter
Guest

soulite,

2. I believe that it is your responsibility to terminate the application [1].

3. I am not sure about OS X v10.5 per se (I'm on OS X v10.9), but this does sound like it could be the resolved bug #2479 [2].

4. Correct you are! Check out SDL_SetWindowPosition & friends [3].

1. https://bugzilla.libsdl.org/show_bug.cgi?id=2479
2. https://wiki.libsdl.org/SDL_EventType#SDL_QUIT
3. https://wiki.libsdl.org/CategoryVideo

Cheers,
Jeffrey Carpenter


On 2014/07/ 12, at 14:52, soulite wrote:

Quote:
Hello, I am new to SDL and these forums, and I have a few general and specific questions.

(Normally I wouldn't lump a bunch of unrelated questions into one post, but I guess I will for this first post rather than creating many small topics.)

1. There doesn't seem to be any built-in method of limiting the framerate in SDL 2.0.3, is this correct? With VSYNC, my test games seem to run around 60 FPS, but I needed to add a limiter to handle some cases -- such as the stretching transition when switching to FULLSCREEN_DESKTOP on OSX 10.9, during the transition my game logic seemed to briefly run at an unlimited rate.

2. On OSX 10.9, I receive SDL_QUIT events for clicking a window's close button, but not for pressing Cmd+Q or the app's Quit menu item. I thought these were recently added to SDL, like Alt+F4 generates SDL_QUIT on Windows? (Also: any way to detect the Preferences or About menu items?)

3. On an older Mac (OSX 10.5) SDL works and I can switch from windowed to FULLSCREEN_DESKTOP, but if I try to switch back to windowed, the SDL screen disappears and I need to force-quit my game. Anyone else experienced this? Should I write an example program and post a bug report?

4. I believe SDL can detect and enumerate multiple displays, but is there a way to open a window (usually centered) on a specific one?

5. Why would a gamepad give a different name if you use JoystickName versus GameControllerName? For example mine shows up as a "Logitech Dual Action" joystick but a "Generic DirectInput Controller" GameController.

6. I actually answered one of my own questions this morning. I was going to ask if you can read GameController buttons without a SDL window, but I found out that you can indeed if you init EVENTS, JOYSTICK, and GAMECONTROLLER without VIDEO.


Any insight to these questions? Thanks for reading, sorry if this is a convoluted post!
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
soulite


Joined: 12 Jul 2014
Posts: 4
Thanks for the tips and info.

1. OK I will add a framerate controller to my SDL games. Easy enough.

2. Jeffrey, strangely that SDL_EventType page specifically says SDL will generate a SDL_QUIT event on pressing Cmd+Q. But I don't believe that is happening for me (I will double-check that, am on Windows right now). Currently I check for a Q keydown with Cmd modifier, but I don't know how to detect "Quit" when chosen from the application's top menu. (Same for the Prefs and About menu items... any way to intercept them?)

3. Good to hear this is a known and fixed bug. Any ETA for a 2.0.4 release?

4. It looks like SDL_WINDOWPOS_CENTERED always opens on the primary display? I guess we need to use GetNumVideoDisplays() and GetDisplayBounds() to calculate the center coordinates of each display. Again, should be easy.
New to SDL -- a few questions
Alex Szpakowski
Guest

The macro SDL_WINDOWPOS_CENTERED_DISPLAY is what you want, I think.


You use it like this:


int pos = SDL_WINDOWPOS_CENTERED_DISPLAY(displayIndex);
SDL_CreateWindow(name, pos, pos, width, height, flags);

On Jul 13, 2014, at 9:27 PM, soulite wrote:
Quote:
4. It looks like SDL_WINDOWPOS_CENTERED always opens on the primary display? I guess we need to use GetNumVideoDisplays() and GetDisplayBounds() to calculate the center coordinates of each display. Again, should be easy.

soulite


Joined: 12 Jul 2014
Posts: 4
Great! I haven't seen that macro used before (although I now see that the SDL_WINDOWPOS_CENTERED constant is actually centering on display #0)

But this leads to a sort of 7th question: I just tested opening centered windows on multiple displays (Windows 7) and it works, but not with FULLSCREEN_DESKTOP mode. If I try to open two FULLSCREEN_DESKTOP windows on two different displays, the first SDL screen does not show! (Simply changing to SDL_WINDOW_SHOWN works fine though.)
New to SDL -- a few questions
Jeffrey Carpenter
Guest

On 2014/07/ 13, at 19:27, soulite wrote:

Quote:
2. Jeffrey, strangely that SDL_EventType page specifically says SDL will generate a SDL_QUIT event on pressing Cmd+Q. But I don't believe that is happening for me (I will double-check that, am on Windows right now). Currently I check for a Q keydown with Cmd modifier, but I don't know how to detect "Quit" when chosen from the application's top menu. (Same for the Prefs and About menu items... any way to intercept them?)

You shouldn't need to check for the Cmd+Q key action, as it is handled internally by SDL for you. You need only to check for the SDL_QUIT event and respond however appropriate (for me, exiting from the main loop is sufficient). On my OS X v10.9.3 box, this alone is enough to terminate the app properly when Quit is selected from the menu, too.

I don't know of any method of intercepting the menu action's for Prefs and About. I spent some time looking over SDL's source (SDL_cocoaevents.m), and the action field for Prefs and About are set to nil, whereas the action field for Quit is set to terminate (SDL defined, which ultimately sends the SDL_QUIT event for us to respond to in our app).

All this tells me that perhaps the ability to intercept these events has not been devised yet? (Pure speculation).

Quote:

3. Good to hear this is a known and fixed bug. Any ETA for a 2.0.4 release?

No idea.

Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
New to SDL -- a few questions
Robotic-Brain
Guest

You can use a custom NSApplicationDelegate and intercept the events that
way.
How to do this is documented in README-macosx.txt

Am 15.07.2014 01:37, schrieb Jeffrey Carpenter:

Quote:
All this tells me that perhaps the ability to intercept these events
has not been devised yet? (Pure speculation).

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
New to SDL -- a few questions
Sik


Joined: 26 Nov 2011
Posts: 905
Actually, in my game I explicitly added code to handle Alt+F4 (I just
trigger SDL_QUIT) because SDL won't intercept it in fullscreen under
Windows (works fine while windowed or under Linux). No idea if that
got fixed by now, but I wouldn't be surprised if there was a similar
issue under OSX.

2014-07-14 20:37 GMT-03:00, Jeffrey Carpenter:
Quote:
On 2014/07/ 13, at 19:27, soulite wrote:

Quote:
2. Jeffrey, strangely that SDL_EventType page specifically says SDL will
generate a SDL_QUIT event on pressing Cmd+Q. But I don't believe that is
happening for me (I will double-check that, am on Windows right now).
Currently I check for a Q keydown with Cmd modifier, but I don't know how
to detect "Quit" when chosen from the application's top menu. (Same for
the Prefs and About menu items... any way to intercept them?)

You shouldn't need to check for the Cmd+Q key action, as it is handled
internally by SDL for you. You need only to check for the SDL_QUIT event and
respond however appropriate (for me, exiting from the main loop is
sufficient). On my OS X v10.9.3 box, this alone is enough to terminate the
app properly when Quit is selected from the menu, too.

I don't know of any method of intercepting the menu action's for Prefs and
About. I spent some time looking over SDL's source (SDL_cocoaevents.m), and
the action field for Prefs and About are set to nil, whereas the action
field for Quit is set to terminate (SDL defined, which ultimately sends the
SDL_QUIT event for us to respond to in our app).

All this tells me that perhaps the ability to intercept these events has not
been devised yet? (Pure speculation).

Quote:

3. Good to hear this is a known and fixed bug. Any ETA for a 2.0.4
release?

No idea.

Quote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
soulite


Joined: 12 Jul 2014
Posts: 4
Thanks for the replies and ideas.

In testing, I definitely was not getting SDL_QUIT events by pressing Cmd+Q or from the program's Quit menu item... BUT I don't think it's SDL's fault, I think the OS quit event is being eaten by something else in my code. So don't worry about unless I come back with more info. (I am fairly new to Cocoa and these event delegates.)

(Also I was wrong before when I asked how to catch the Preferences and About menu events -- I now see that SDL windows don't have those menu entries, so I don't need to worry about them!)

Nice to see a 2.0.4 wrap announcement shortly after I wondered about it here. Thanks and keep up the great work you guys.