Hi,
can you tell me how to have more than 100 fps in my program? I can’t do it, and I don’t know why. When I have only one triangle and my loop is something like this:
for (; 
{
render();
fps();
swapbuffers();
}
and this program makes only 100 fps. But without swapbuffers it makes a lot more.
I need more than 100 fps to program that doesn’t render to screen but to bitmap.
Thanks a lot.
Hi !
Most of the time it is pretty useless to have >100 FPS, but anyway, if you render to a bitmap on Windows for example I would guess that you are not using and hardware at all, I don’t think you get any hardware acceleration when you use bitmap/DIB rendering.
You have to use pbuffers or any other HW accelerated method.
There is not much need to call SwapBuffers when rendering to a bitmap, this only makes sence when you use doublebuffering.
Mikael
[This message has been edited by mikael_aronsson (edited 08-21-2003).]
You need more than 100fps???
Erm… why?
60fps is the number you should ideally be striving for. This is the magical fps number as the human eye can’t really notice the difference beyond this point.
[This message has been edited by ReAKtor (edited 08-21-2003).]
How can i see if i have HW acceleration?? I never looked into that, only did what they did in tutorials lol 
if you do have exactly 100 fps and this only when you draw with doublebuffering, it much sounds like the program waites for vsync before swapping the buffer. At least if you have 100 hz screen refresh rate.
Hi again !
Yes, the 100 FPS with double buffering is probably because of VSYNC (mots cards allow you to turn it off), but once again, why would you need double buffering when you want to render to a bitmap ?
Yes, it’s VSYNC - thanks 
How to disable it by my program?
I needen this information because… i saw a program that had more that 100 FPS on my computer and i wanted to do the same. I just wanted to know how to do this
Thanks for help!
Take a look at wglSwapIntervalEXT : http://www.3dlabs.com/support/developer/WGLmanpages/wglswapintervalext.htm
It allows you to control the VSync.
[This message has been edited by PanzerSchreck (edited 08-22-2003).]
ReAKtor : I have to disagree… 60 motionblurred fps is certainly enough, but since most opengl applications still dont use motinblut techniques you only get a snapshot, so to fool the brain that its smooth you need a much higher fps… its no meaning to go beyond the frequency of the scrren becourse that information wont get to the viewer, but the optimal frame delay to get lifelike images should be the average time between photons becouse that is how much info the brain gets, and thats whats makes it motion blurred, since the brain only processes the images in a lower speed ( i dont know how high the average spees is, but probably below 60Hz since we dont benefit from higher frequencies, atleast not motion blurred ones). So Motion blur the images, or try to get a framerate as high as the monitor can show, that will be the most ‘realistic’ looking animations.
( this had not much to do with the subject, but i just wanted to state that we DO see difference in fps over 60Hz on still images)
I concur with Mazy here. High fps are good for another reason:
You generally process and react to user input once per frame in games or all other kinds of interactive simulations. Single buffered rendering creates a delay of one frame between user action and program reaction. Single buffering isn’t even useful for rendering though. Double buffering increases the delay to two frames.
The only constant in this equation is “frame time”, so for snappy response (the opposite of mouselag) you want to get really high fps. 60 at a minimum (~30ms input latency).
there’s just one thing i want to add to zeckensack’s post. The eye catch’s less than 30 frames per second. That’s why a movie has between 25 and 30 fps. The advantage of higher framerates has already been explained by zeckensack.
see you,
Azrael.
Wow highly questionable stuff posted, this certainly has nothing to do with motion blur. Your monitor can only display at the frame rate. There is no integration of fields that are never displayed. Exceeding that only means parts of your display will tear between frames because you swap during video scan and different pixels display different frames with of course different latency on those pixels.
The only justification for this might be improved (if unpredictable)latency for some pixels on the lower parts of your display.
There are better strategies to improve latency without this stupidity. For example graphics systems buffer a swap & frames worth of data to improve pipelining, you can defeat this in your software. If y do there are soem clever things you can do w.r.t. event handling to control latency without hosing your graphics throughput.
i did state that “its no meaning to go beyond the frequency of the screen becourse that information wont get to the viewer”
but up to that freqency you will benefit from it ( or just strt doing some nice motionblur on the images instead)
Mazy, I should have read more closely. You are correct and we agree, my apologies.