counting frames in SDL

Started by
7 comments, last by jab630 17 years, 8 months ago
I am programming the graphics for a neuroscience professor whose lab exposes subjects to very simple 2D graphics and tracks eye movements. A few months ago I posted here asking for recommendations on libraries to do simple 2D graphics in C++. Following the advice in the replies, I used SDL and SDL_gfx, and they turned out to be just what I needed (thanks again, kloffy, cignox1, et al.) For the latest experiment, we are using a very fast monitor (200 Hz) to simulate a saccade (a very fast eye movement) with a photodiode to record screen refreshes, so we need to control the exact number of monitor refreshes a particular sprite is displayed before moving it and redrawing the screen. Is there some way that SDL interfaces with the monitor hardware so that you can control this? P.S. I know I could use SDL_GetTicks() to control the number of milliseconds between redraws, but that doesn't help... I need to wait a certain number of monitor refreshes (which changes depending on the monitor being used), not milliseconds (which doesn't change). Thanks in advance!
Advertisement
I think the simple answer is no. SDL can wait for the next refresh (using SDL_Flip) but it can't count them as such. If you are able to complete all your processing in 1/200th of a second then you can effectively count them that way, if your monitor hardware is supported adequately by the driver system (eg. DirectX). Alternatively you may be able to use a high performance timer to time when to draw things. But I don't think you're going to have much luck getting SDL to reliably draw an entire frame in 5ms. You may require something more low-level like OpenGL to have a better chance at the required performance.
Thanks for the reply. Even if I were to use OpenGL (which would require me to re-engineer my whole graphics library), would I be able to push 200 frames per second? I'd need to be able to repaint the entire screen every 5 ms, and the times I'm getting from SDL are closer to 25 ms.
OGL can draw a sprite going 200FPS without breaking a sweat.
Dev Journal - Ride the Spiralhttp://spiralride.blogspot.com/
Greetings!

SDL is using OpenGL so do not worry. Of course it can draw much faster than 200 FPS. How to figure that out? Check some information on QueryPerformanenceFrequency and QueryPerformanenceTimer.

Sorry, but I do not recall any specific demo lately, but it sure the best way to do it. Maybe nehe (http://nehe.gamedev.net) has some demos which are using QueryPerformanenceTimers? I'm sure you'll quickly figure out how it is done.

It works for more than 2000 FPS on a Radeon 9800 PRO with Athlon 3200XP, even 12000 FPS with GeForce 6800GT and P4 3,2GHZ HT, so it will work for you too! It is accurate, give it a try!
Quote:SDL is using OpenGL so do not worry. Of course it can draw much faster than 200 FPS. How to figure that out? Check some information on QueryPerformanenceFrequency and QueryPerformanenceTimer.


Actually, in windows, SDL can be looked at a wrapper for directdraw (sorta' - it uses Directdraw surfaces as SDL_Surfaces ). It might be interesting to see if you can call some windows-specific ddraw functions that will tell you about the monitor's refresh rate.

Also, I do not understand why you have ruled out using a millisecond delay. If you want a 200mhz response time, you can simply wait 5ms (1000ms / 5 = 200 refreshes). What am I not understanding?

[Edited by - ender7771 on July 30, 2006 9:32:03 PM]
Quote:Original post by ender7771
Also, I do not understand why you have ruled out using a millisecond delay. If you want a 200mhz response time, you can simply wait 5ms (1000ms / 5 = 200 refreshes). What am I not understanding?


Because if you're even a microsecond late when rendering, then you miss your monitor refresh and suddenly you're down to 100Hz instead of 200Hz.

The original poster might be able to simply succeed with using OpenGL for rendering; providing the rendering operations happen within the 5ms and vsync is enabled (and everything along the chain supports that display mode) then it should be fine.

jab360 - If using OpenGL is going to be a hassle, look into one of the several wrapper libraries available. If you need more info on this, tell us what sort of graphics you need to render.

Yes Jab360, vsynch will ensure that every frame matchs your moniter refresh perfectly, so that each refresh a full frame is drawn, so you must just set your refresh rate of your moniter to 200hz and ensure you can render in under 5ms. To check this, because vsynch waits for each refresh, you can simply measure your fps, if it is constantly 200fps then you are fine, but be sure to test this under full data load as it can suddenly drop to 100fps if you go over 5ms in vsynch (i believe vsynch is enabled by default in SDL)

If you do not wish to over-write your engine then you must find a way to make your code faster (simpler pixel and depth formats) or attempt to buffer your data so that it's almost realtime.
thanks everyone for your helpful replies, and sorry for the late response. i ended up trying it out on a machine with a faster graphics card and it looks like it will be fast enough. they won't get started with the experiment until the fall, but until then, i think we're set. thanks again!

This topic is closed to new replies.

Advertisement