New to SDL -- a few questions |
mr_tawan
|
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:-
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). |
|||||||||||||||
|
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:
|
|||||||||||||||
|
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:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
soulite
|
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:
|
|||||||||||||
|
soulite
|
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:
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).
No idea.
_______________________________________________ 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:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
New to SDL -- a few questions |
Sik
|
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:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
soulite
|
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. |
|||||||||||
|