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.)
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.
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?)
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?
I believe SDL can detect and enumerate multiple displays, but is there a way to open a window (usually centered) on a specific one?
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.
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!
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.
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).
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:
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.
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).
Cheers,
Jeffrey Carpenter
<@Jeffrey_Carpenter>On 2014/07/ 12, at 14:52, soulite wrote:
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.)
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.
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?)
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?
I believe SDL can detect and enumerate multiple displays, but is there a way to open a window (usually centered) on a specific one?
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.
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!
OK I will add a framerate controller to my SDL games. Easy enough.
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?)
Good to hear this is a known and fixed bug. Any ETA for a 2.0.4 release?
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.
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:
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.
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.)
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).
Good to hear this is a known and fixed bug. Any ETA for a 2.0.4 release?
You can use a custom NSApplicationDelegate and intercept the events that
way.
How to do this is documented in README-macosx.txtAm 15.07.2014 01:37, schrieb Jeffrey Carpenter:
All this tells me that perhaps the ability to intercept these events
has not been devised yet? (Pure speculation).
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 :> On 2014/07/ 13, at 19:27, soulite wrote:
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).
Good to hear this is a known and fixed bug. Any ETA for a 2.0.4
release?
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.