Hey all.
I’m new around here and to SDL in general, and I have a question about
what SDL_Quit() does with timers that were set with SDL_AddTimer().
Namely, I was working on some OpenGL stuff and so I set up a timer to go
off every 30 milliseconds and it would draw the current frame. Then, when
I would quit, SDL_Quit() would run since it was setup to with the atexit()
command, and the program would often hang and I’d get a Seg Fault (I’m
developing in Linux if that matters). I was able to fix it simply by
calling SDL_RemoveTimer() just before exiting to remove the frame timer
that I had setup. It seemed almost as if SDL_Quit() would either
terminate the program without stopping the timer or the thread that was
running it, or something else beyond my grasp.
Like I said, I’m new to SDL, so any insight would be great.
Thanks,
Ryan
Hey all.
I’m new around here and to SDL in general, and I have a question about
what SDL_Quit() does with timers that were set with SDL_AddTimer().
Namely, I was working on some OpenGL stuff and so I set up a timer to go
off every 30 milliseconds and it would draw the current frame. Then, when
I would quit, SDL_Quit() would run since it was setup to with the atexit()
command, and the program would often hang and I’d get a Seg Fault (I’m
developing in Linux if that matters). I was able to fix it simply by
calling SDL_RemoveTimer() just before exiting to remove the frame timer
that I had setup. It seemed almost as if SDL_Quit() would either
terminate the program without stopping the timer or the thread that was
running it, or something else beyond my grasp.
That’s very possible. I haven’t looked to see what the timer thread does
when SDL_Quit() is called.
You probably shouldn’t draw a from from a timer callback though. Some
systems simply don’t allow it, and the resolution of the timer is only
10 ms, which is less than you might get by some other methods.
Check the archives for discussion about graphic updates and threads.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
You probably shouldn’t draw a from from a timer callback though. Some
systems simply don’t allow it, and the resolution of the timer is only
10 ms, which is less than you might get by some other methods.
Well, what are the other methods. If you have an emulator and want to make
e.g. 200Hz timer. You must blit the screen at 50Hz frequency.
What is the SDL like (multiplatform) solution for this problems?
Check the archives for discussion about graphic updates and threads.
Which one?
regards
STanOn Wed, 8 Aug 2001, Sam Lantinga wrote:
Standa Opichal wrote:
Well, what are the other methods. If you have an emulator and want to make
e.g. 200Hz timer. You must blit the screen at 50Hz frequency.
What is the SDL like (multiplatform) solution for this problems?
You should not need to use the timer for anything in an emulator, except
possibly for meta-stuff like the user interface. Exactly how to do it
depends on your emulation model, your timing contraints, and your
emulation target.
For instance, you can use an cpu cycle-based event queue, where you
insert interrupts from various sources. Each cycle (or every N cycles,
for some value of N) you check the event queue. To synchronise your
emulator with real time in some way, you could call SDL_GetTicks()
periodically and wait a few cycles if you are ahead, or decide to skip a
frame update if you are behind. There are many different ways of doing it.
There are many emulators with source code available, so I suggest you
start reading — it can be very educational. And even if they
emulate different machines, they often have to solve the same problems.
(200Hz, you are not writing an ST emulator by any chance? 
Standa Opichal wrote:
Well, what are the other methods. If you have an emulator and want to make
e.g. 200Hz timer. You must blit the screen at 50Hz frequency.
What is the SDL like (multiplatform) solution for this problems?
What I did in my emulator was to use the number of emulated clock cycles
to determine when the video refresh should occur and do the refresh in
the emulator’s thread after the appropriate number of clock cycles has
ellapsed. As long as your emulator adjusts itself to maintain the
correct clock speed of the emulated system, you get a fairly reliable
way to do your screen updates. It isn’t the main thread of the
application, but it is the only thread doing updates to the SDL window.
I don’t know how portable this is but it seems to be working on
Windows and Linux - YMMV.
Marc