|
11-18-2009, 06:35 PM
| #1 |
| dat is, vast staat  Join Date: Jul 2008 Location: SE Queens
Posts: 6,612
| events, frame rates, and the pipeline I've always been slightly puzzled by gamers obsession with frame rates. Like film is I think <30 fps, so why bother with more? Yes that's a genuine question, cause I presume there is a genuine reason, I'm not calling anyone a fool. This afternoon I was wondering if it relates to events, and "the pipeline". Lemme describe my programming issue to explain why I'm thinking that. For a 3D FPS breakout, you are the paddle, so the paddle moves in x and y but not z, which makes the mouse perfect. But today I was experimenting with openGL in both SDL and glut and I noticed something: the data I got from mouse events was instantaneous -- I used it to modify global variables and printf them, those changes appear instantaneously -- but the response in the graphics display noticeably lags, I would say at least 1/2 second. This does not make sense to me, since I am getting 25-45 fps*. I presumed that there is no temporal offset, but that is not necessarily so -- that is, you could get 100 fps, but at a 1 second delay. It is a "pipeline", so I suppose there must be some delay from the time data is fed into one end (when the "render frame/scene" function is called) to when the graphics lib, etc, have done their job and the frame actually appears on the scene, because it is obvious from the console debugging data (printf) that the frame currently executing is at least 10-15 frames ahead of what appears in the application window. Is that right? Is that normal? Is that a consequence of a crappy video card and software acceleration? Or am I out to lunch here? Suddenly, it might make sense to want 60 fps, if the delay is a number of frames, and especially if that number was also reduced. If the offset were 5 frames at 60 fps, that's 1/12th of a second, more or less instant. But with what I am looking at right now the action is gonna be really lame. *presumably this will start to diminish when the graphics gets heavier, but by then I will probably be motivated to buy a card
__________________ C programming resources: GNU C Function and Macro Index -- glibc reference manual The C Book -- nice online learner guide Current ISO draft standard CCAN -- new CPAN like open source library repository GDB tutorial #1 -- gnu debugger tutorials -- GDB tutorial #2 cpwiki -- our wiki on sourceforge |
| MK27 is offline |  |
|
11-18-2009, 10:17 PM
| #2 |
| Super Moderator  Join Date: Aug 2001
Posts: 8,423
| It's all about samples. There are more samples between time T and time T2 at 60 FPS than at 30 FPS. More samples will yield smoother presentation, more responsive devices, etc, etc. 60 FPS is 1 frame per 16.66666667 ms or 1000 / 60. 30 FPS is 1 frame per 33.33333333 ms or 1000 / 30. 20 FPS is 1 frame per 50 ms or 1000 / 20. At 60 FPS the entire system is being updated every 16.666666667 ms. Most physics systems will be clamped here but nothing says the video has to be. If vsync is turned off...or if triple buffering is on and the triple buffer is unused at render time...you can achieve far more than 60 FPS. So 60 FPS is actually saying we have split 1 second into 60 separate time slices. Obviously the more distinct sample points you have between 0.0f and 1.0f the better. That is the whole thrust behind the FPS argument. It's not just the video running at this speed, it is the entire system or the entire game. If one aspect takes more time than usual every other system takes a hit - that is every system that is not in a thread. Imagine in online play you are running at 5 FPS and you are trying to shoot one of your buddies in a deathmatch. At 5 FPS it is going to be extremely hard, nigh impossible, to actually hit your friend. There are only 5 distinct samples of gameplay in 1 second which means it won't even be interactive enough to use. So if your friend is running from point A to point B and the journey takes 1 second, you only get 5 distinct time slices of his movement from A to B. If you are at 60 FPS you will get 60 distinct time slices or 60 unique 'snapshots' in time of his movement from A to B. You are 12 times as likely to hit him when he is moving from A to B at 60 FPS than at 5 FPS. Likewise your mouse will be sampled 12 times as much in 1 second at 60 FPS than at 5 FPS. Last edited by Bubba; 11-18-2009 at 10:24 PM. |
| Bubba is offline | |
|
11-20-2009, 02:04 PM
| #3 | |
| dat is, vast staat Join Date: Jul 2008 Location: SE Queens
Posts: 6,612
| Quote:
Code: glColor4f(0.0f,0.0f,0.0f,1.0f);
if (!(reps%500)) {
printf("NOW\n");
glColor4f(1.0f,0.0f,0.0f,1.0f);
}
printf("*"); fflush(stdout);
reps++;
That does not happen. There is a very clear delay. Every frame an asterisk is printed. I sit with one finger on ctrl and one over the c key. As soon as I see the object flash red, I kill the process: NOW ****************************************^C In other words, at my current frame rate, there is a delay of almost a full second between when the code is executed and when the frame is actually rendered on screen. The issue may be that I need to use a timer. I just went back to look at the OGL stuff I did before and low and behold, there is no such problem there. But in those, I used a one millisecond timer. I read in another forum that this was a bad idea and that you will get a faster frame rate by just allowing the drawing rountine to repeat as often as possible, and since I now want a game, I figured should stick as close as possible to conventional wisdom. Hopefully putting the timer back in will solve the problem.
__________________ C programming resources: GNU C Function and Macro Index -- glibc reference manual The C Book -- nice online learner guide Current ISO draft standard CCAN -- new CPAN like open source library repository GDB tutorial #1 -- gnu debugger tutorials -- GDB tutorial #2 cpwiki -- our wiki on sourceforge | |
| MK27 is offline | |
|
11-20-2009, 08:30 PM
| #4 | |
| Registered User Join Date: Mar 2007
Posts: 408
| Quote:
Also have to take in to account your fingers are not as fast as a computer 
__________________ My Blog | |
| scwizzo is offline | |
|
11-21-2009, 03:09 AM
| #5 | |
| Super Moderator Join Date: Aug 2001
Posts: 8,423
| Quote:
Setting breakpoints and timing the delay would be a better approach. I'm not sure why you are using printf() at all in an OGL app since any console output or OutputDebugString() will slow the system down. | |
| Bubba is offline | |
|
11-21-2009, 07:34 AM
| #6 | ||
| dat is, vast staat Join Date: Jul 2008 Location: SE Queens
Posts: 6,612
| Quote:
The reason I did this to start with was to debug why the mouse movement was lagging. It is of the sort where if I move the pointer (which is part of X, not OGL), it responds instantly. However, the response in the OGL window is very much delayed -- it is still smooth, this is NOT a low framerate problem. For example, if I quickly move the mouse a few inches and let go, the response in the OGL window does not even begin until my hand is off the mouse. So, no matter what you do with it, the movement visibly continues after your hand leaves the mouse. Thus, I added printf lines to show the raw mouse data the app had received. But even tho that line was after the line applying the transformation, it VERY CLEARLY appears on the console before the graphical response does, which means the code is being executed at that point, then there is ~ 1 second delay, then it appears in the OGL window. As for human response time, I agree I would expect a bit of a lag, but not anything like that much. As I said, it is visually apparent, I just wrote that little bit of code to make the issue clear. If human response time were that poor, no one would bother playing video games, catching balls, etc. If the delay were so short as to be less than my response time, I wouldn't care. I also agree use of stdout will slow things down if you are just doing computation in the background, but in this setting it does not affect the frame rate AT ALL. The console output appears instantaneously, it is the graphical output which lags. Quote:
And, incidentally, 1) the same hesitation is evident in the debugger anyway, 2) many debuggers do run in the console, and you are a fool if you believe the GUI version is somehow faster, etc, so this whole thought you had here is oxymoronic. Anyone else? I would say this may be simply because I don't have a GPU, my routine is at the beginning of the pipeline, and the software emulation runs as a threaded processes, permitting those routines to be executed in advance of the low level work done by the library and video module. However, as mentioned before, I have earlier stuff I've done where this delay does not happen -- I move the mouse, the scene move simultaneously. At this point, the only differences in the style of the code is that the old stuff has lighting and texture, whereas this does not yet. I'm totally flummoxed.
__________________ C programming resources: GNU C Function and Macro Index -- glibc reference manual The C Book -- nice online learner guide Current ISO draft standard CCAN -- new CPAN like open source library repository GDB tutorial #1 -- gnu debugger tutorials -- GDB tutorial #2 cpwiki -- our wiki on sourceforge Last edited by MK27; 11-21-2009 at 08:24 AM. | ||
| MK27 is offline | |
|
11-21-2009, 10:49 PM
| #7 | |||
| Super Moderator Join Date: Aug 2001
Posts: 8,423
| Quote:
Quote:
Based on this fact: Quote:
If the code to render the frame executes 1 full second before it is shown on the screen this implies a serious framerate issue. I'm not sure why you say otherwise since framerate would definitely be affected here. IE: Code: ...
while (m_gameRunning)
{
Engine->Update();
Engine->Render();
}
...
I cannot think of any case where a 1 second delay after every render call would not clamp you to 1 FPS. I recommend that you allow your main update/render loop to run as fast as possible with no delays. If you are vsynced I recommend you turn triple buffering on. If you are concerned about taking CPU cycles then thread things like sound and input. This will bring the overall usage down...but personally I would not worry about maxing out the CPU. Things to check (for Direct3D at least but they may apply to OGL)
Last edited by Bubba; 11-21-2009 at 11:05 PM. | |||
| Bubba is offline | |
|
11-22-2009, 12:30 PM
| #8 | ||
| dat is, vast staat Join Date: Jul 2008 Location: SE Queens
Posts: 6,612
| Quote:
Anyway, someone at the openGL forum says that it is possible that "your GL implementation stores too many GL commands before actual rendering takes place". Why this would effect one piece of code with near identical methodology to another piece of code, I do not know. Using glFlush() did not work. However, adding glFinish()*-- a command of which I was unaware -- right before glutSwapBuffers() did the trick. 3D game programming here I come  When I add the normals in for this, I will try taking that out: I'm guessing something in the GL implementation flushes output during normalization, but not otherwise. It could also be that a heavier scene slows everything down enough that it catches up to itself.And, low and behold, the frame rate went up to a smooth 85 (the scenery heavy one is less than half that, coincidentally matching the problem code; I presume at a certain point I will need to get a card for hardware acceleration). *which the manual for glFinish(): Quote:
__________________ C programming resources: GNU C Function and Macro Index -- glibc reference manual The C Book -- nice online learner guide Current ISO draft standard CCAN -- new CPAN like open source library repository GDB tutorial #1 -- gnu debugger tutorials -- GDB tutorial #2 cpwiki -- our wiki on sourceforge Last edited by MK27; 11-22-2009 at 12:34 PM. | ||
| MK27 is offline | |
|
11-22-2009, 09:30 PM
| #9 |
| Super Moderator Join Date: Aug 2001
Posts: 8,423
| Well it's good to hear you solved it. I'm definitely not an OpenGL guy so the only gotchas I know are related to Direct3D and trust me it has just as many as OGL does. The only way you learn about them is by going through what you did with this one. Often the documentation does not warn you about these types of issues so it really comes down to figuring it out on your own which royally sucks. |
| Bubba is offline | |
 |
| Thread Tools | |
| Display Modes | |
|
Linear Mode
