Oxygen Basic
Programming => Example Code => Graphics => Topic started by: Mike Lobanovsky on April 27, 2014, 01:07:21 PM
-
Hello community,
I would like to ask for your assistance. Attached below please find a "small" thinBasic program that's supposed to show if "image stutter" is seen on your computers when rendering moving 3D objects in OpenGL.
Terminology
1. By "image stutter" I mean very short momentary stop-overs of the 3D ball as it bounces horizontally in the window. There may be as few as just 1 or 2 such stopovers per the entire session; alternatively, heavy stuttering may be observed practically in every mode the program runs in. Once stopped for a fraction of a second, the balls "jumps" a little farther forward than it normally should or it may even bounce back a little if image stutter is heavy.
2. Similar to image stutter, another artifact may be observed especially if vertical synchronization is switched off:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/Tear.png)
This artifact is called "image tear" and it would affect a part of the ball that didn't have a chance to be drawn before the monitor started to draw another frame. This usually happens at very high FPS rates but it shouldn't happen with VSYNC set to 60 or 30 FPS. A visible difference between stutter and tear is that when the ball stutters, its entire image freezes momentarily while image tear would let the torn parts of the ball go on moving more or less smoothly.
Program Control
1. Those who have nVidia video cards and drivers, please open up your nVidia Control Center and make sure that your driver is controlled by this test application otherwise you won't be able to toggle its vertical synchronization settings:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/NVSettings.png)
A similar feature should be selected in ATi Catalyst Control Center if you happen to own an ATi Radeon video card.
2. The program starts with VSYNC set to none. The VSYNC settings are shown in the window title. You'll be able to toggle VSYNC between None, 60FPS and 30FPS by pressing 0, 1, and 2 number keys, respectively.
Objectives
The main objective is to test the program for image stutter in normal and maximized windowed modes under Classic, Basic, and Aero themes. If under XP only, Classic and any other theme should be tried.
Tactics
1. Set your desktop theme to Classic.
2. The program starts at the center of the screen. Here you probably won't see any stutter. Please drag the window to the top right then bottom left corner of the screen and let it stay there while you're watching the ball as it makes two or three successive bounces off the window borders. If the ball stutters at least once in any window position, image stuttering is considered to be present.
3. Press 1 to set VSYNC to 60FPS and repeat as described in Step 2.
4. Press 2 to set VSYNC to 30FPS and repeat as described in Step 2.
5. Maximize your window and see if image stutter occurs under VSYNC=None, then 60FPS, then 30FPS.
6. Set your desktop theme to Basic where available and repeat Steps 2 to 5. Set any theme other than Classic if you're under XP.
7. Set your desktop theme to any Aero theme and repeat Steps 2 to 5 (not applicable to XP).
Prognosis
Please inform us of your results in this thread. Most probably, ball movement will be:
-- absolutely smooth and stutter-less under Windows XP;
-- heavily stuttering in Classic and Basic themes but only occasionally stuttering in an Aero theme under Windows Vista; and
-- heavily stuttering in Classic, occasionally stuttering in Basic, and practically not stuttering in an Aero theme under Windows 7.
Reports for Windows 8 and 8.1 as well as other video cards would also be highly appreciated. Thanks a lot in advance.
Awaiting your soonest results,
P.S. Oh, and please have your browsers closed while running the tests. Modern browsers normally use OpenGL to render their content even if there are no pictures in view. Having OpenGL run several applications at once while benchmarking wouldn't seem very practical.
P.P.S. And oh one more time. If anybody wants the TB script I used, here it goes:
Uses "UI"
Uses "TBGL"
Function TBMain()
Local hWnd As DWord
Local x, k, diffx As Single
Local dir As Long
hWnd = TBGL_CreateWindowEx("-=:: Image Stutter Test ::=- VSYNC=None", 620, 500, 32, %TBGL_WS_CLOSEBOX Or %TBGL_WS_MINIMIZEBOX Or %TBGL_WS_MAXIMIZEBOX Or %TBGL_WS_DONTKEEPASPECTRATIO)
TBGL_ShowWindow
TBGL_ResetKeyState
TBGL_UseLightSource %GL_LIGHT0, %TRUE
TBGL_UseLighting %TRUE
dir = 1
x = 0
diffx = .02
TBGL_UseVSync 0
While TBGL_IsWindow(hWnd)
TBGL_ClearFrame
TBGL_Camera 1.5,2,4,1.5,0,0
TBGL_Color 0,200,200
If x > 3 Then dir = -1
If x < 0 Then dir = 1
k = TBGL_GetFrameRate / 60
x = x + diffx / k * dir
TBGL_PushMatrix
TBGL_Translate x, 0, 0
TBGL_Sphere 0.75
TBGL_PopMatrix
TBGL_DrawFrame
If TBGL_GetWindowKeyState(hWnd, %VK_ESCAPE) Then Exit While
If TBGL_GetAsyncKeyState(%VK_0) Then
TBGL_UseVSync 0
Win_SetTitle(hWnd, "-=:: Image Stutter Test ::=- VSYNC=None")
ElseIf TBGL_GetAsyncKeyState(%VK_1) Then
TBGL_UseVSync 1
Win_SetTitle(hWnd, "-=:: Image Stutter Test ::=- VSYNC=60FPS")
ElseIf TBGL_GetAsyncKeyState(%VK_2) Then
TBGL_UseVSync 2
Win_SetTitle(hWnd, "-=:: Image Stutter Test ::=- VSYNC=30FPS")
End If
Wend
TBGL_DestroyWindow
End Function
.
-
Hi Mike,
thanks for bringing up this issue, not specific to OpenGL but "featured" in Direct3D too.
The VSync is a must for high quality renders.
On Windows 8, the stutter is not observable - testing configuration: Core i5 + GeForce GT640.
I am long time NVidia user (and programmer), and I do not remember having a big problems with stutter on PCs from win98 to 8. But I know SLI configurations suffered from it a lot.
I am living in PAL country, could it make a difference?
Only place where I see the micro stutter recently is in Unity engine, sometimes.
One of the approaches to watch effects of stutter would be to record video using camera pointed at PC screen, ideally at 60 FPS and short exposure time.
Petr
-
Hello Petr,
Thanks a lot for your information...
On Windows 8, the stutter is not observable - testing configuration: Core i5 + GeForce GT640.
... and your report.
The VSync is a must for high quality renders.
A 60Hz VSYNC, either fixed or adaptive, yields the heaviest stutter on my hardware despite all the three monitors being set to a 60Hz refresh. No VSYNC and 30Hz give a much smoother picture.
I do not remember having a big problems with stutter on PCs from win98 to 8.
Neither did I until recently. XP is still perfectly stutter-less on my HW but it's not so any more under my Vista and 7, especially on non-composited Classic desktops.
But I know SLI configurations suffered from it a lot.
This is exactly why I asked for the community's assistance because I seem to be the only nVidia user armed with SLI on all the forums I'm registered at. My geForces are not top-notch any more but they cost me a fortune when I bought them five years ago and they didn't ever let me down in the meantime once I made it my habit to have my drivers upgraded regularly and automatically. I guess it will be a while more till I take a dicision to change them for anything else unless I'm directly forced to, e.g. by this unbearable stutter.
I am living in PAL country, could it make a difference?
So am I, that's why it couldn't. We did away with SECAM here about 20 years ago.
Only place where I see the micro stutter recently is in Unity engine, sometimes.
Yep, I'm observing it in Unity too but only if not masked off by motion blur.
One of the approaches to watch effects of stutter would be to record video using camera pointed at PC screen, ideally at 60 FPS and short exposure time.
I'm seeing this annoying stutter so vividly that I don't need any more video proof. It looks disgusting enough as it is. :)
Regards,
-
Hello Charles,
Can you confirm or deny image stutter (that's what we called "frame drop-outs" before) in this test application under your Vista?
-
(http://files.allbasic.info/Mike/shutter_test.png)
Runs smooth with no ball shutter for me.
Wine 1.7.17 - Ubuntu 12.04 LTS 64 bit - Intel® Ironlake Mobile
-
Thanks for the feedback, John!
However I think the problem is strictly Windows-specific. Linux uses another OpenGL implementation that's called Mesa. Wine would use Mesa and its drivers to emulate Windows OpenGL behavior. The original Windows canvas is double-buffered in this sample but I think that if the desktop you're currently using is Unity, Compiz or Emerald, then your image may even get triple-buffered latently which usually yields much smoother movement.
All this makes your environment not particularly suitable for this test. I'm inclined to regard the stutter I'm seeing as either the incompatibility of my aging video cards with up-to-date nVidia drivers or the deficiency of these drivers on the current Windows platforms in general.
Of course, my SLI (that's nVidia's technique of using several video cards in parallel and it requires a special brand of motherboard) may also be the cause of the trouble as Petr rightfully pointed out. But if Charles confirms that this ball stutters (similar to what we saw in his ControlCraft.o2bas sample), this possibility will be ruled out because Charles has only one nVidia card installed IIRC.
-
I'm running GNOME Classic shell. (no Unity)
It seems Wine just keeps getting sweeter as it matures. 8)
-
Sure it does. But you shouldn't forget that Wine's actual driving force are video games written for Windows. 8)
Seriously, Wine 1.7 is very good. Even on a Mac. :)
-
Sure it does. But you shouldn't forget that Wine's actual driving force are video games written for Windows.
The open source community is large and friendly and is home to many a forgotten friend. I use dosemu under Linux and it provides the best DOS experience I have had. I can't even run many of the DOS games on current Windows without using a DOSBox emulator. In my mind Linux has become an omni host to the lost, forgotten and those still with good sense.
Here is a good example of what I'm trying to say. I found a source version of William Yu's DOS emulation compiler. It was written C so I gave it a try with gcc (64 bit) and it compiled. It only generates DOS executables (that work) but still cool none the less.
jrs@laptop:~/.dosemu/drive_c/becdos$ ./bec EXAMPLE.BAS examu64.exe
BASIC Emulation Compiler v0.21 (c)1998-99 William Yu
Compiling: EXAMPLE.BAS to examu64.exe
Compiling using standard ANSI.LIB
Successful compile!
46 statements, 81 lines Compile time: 0.000000
Variables: 4 strings, 3 integers
1503 bytes code, 0 bytes data
jrs@laptop:~/.dosemu/drive_c/becdos$ cat EXAMPLE.BAS
rem EXAMPLE.BAS by William Yu
rem Demonstrates just some of the supported features of BASEC
DIM MyNAME AS STRING * 30
DIM Message AS STRING * 30
DIM CopyRIGHT AS STRING * 30
DIM PRODUCT AS STRING * 15
DIM Year AS INTEGER
DIM N AS INTEGER
DIM X AS INTEGER
MyNAME = "William Yu"
PRODUCT = "BASEC v0.20"
CopyRIGHT = "Copyright "
Message = "Isn't that cool?!"
' BEC can handle almost any complex equation
N=10^3 '' Available operators (+-*/^=<>, MOD, AND, OR, XOR, NOT)
X=N/5 + 20
Year=(2 * N) / ((4 - -2) + -2) + (N - 100) / X + N + (N - (N / 2)) - 6
'CLS ' This is a DOS function
? PRODUCT;" ";CopyRIGHT;Year;" by ";MyName
?
PRINT "My name is "; MyNAME:PRINT:PRINT "Count to ten: ";
FOR N=1 TO 10
?N;
NEXT N
?" how's that?":?"Notice that (unlike QB), the numbers aren't split up"
PRINT
PRINT "PRINT Message: "; Message
PRINT "Negative number: "; ---(10 MOD 6);" and ";
PRINT -10 + -val(mid$("100 or 200 or 300",8,3))
PRINT
PRINT "Other numbers "; 1456789; " and, "; 987654321;
PRINT 123456789
PRINT
PRINT "Hi, "; MyNAME; " how are you today?"
PRINT
PRINT "Let's try some bitwise operators..."
N = NOT 16
X = 32 OR 16 OR 8 OR 4 OR 2 OR 1
PRINT "NOT 16 = "; N; ", 32 OR 16 OR 8 OR 4 OR 2 OR 1 = "; X
N = 16 AND 16
X = 16 XOR 16
PRINT "16 AND 16 = "; N; ", 16 XOR 16 = "; X;
?
N = 16 XOR 255
PRINT "This is what N equals "; N
X = N = 2
PRINT "Does N equal 2? "; X
X = N > 2
PRINT "Is N greater than 2? "; X
IF N <> (255 XOR 16) THEN
PRINT "N is "; N
?255 xor 16
ELSEIF N = 39 THEN
?"oh no"
ELSEIF N = 39 THEN
?"oh no"
ELSEIF N <> 239 THEN
?"oh yes"
if X > 2 then
?"X is greater than 2"
elseif X < 2 then
?"not!"
?X
end if
else
?"howdy!"
END IF
PRINT "At the end\n\n\n"
END
jrs@laptop:~/.dosemu/drive_c/becdos$ dosemu
(http://files.allbasic.info/Mike/bec.png)
-
I wasn't talking about DOS games. I was talking about contemporary 32-bit Windows games that currently are, and will continue to be, played by millions of people, such as World of Warcraft, Counterstrike, or the Sims, to name but a few. You can find fuller top charts (http://appdb.winehq.org/) at Wine Headquarters.
There's nothing to be ashamed of when talking about video games and their true impact on the computer industry. They have been one of its main driving forces alongside military warfare, avionics, or space exploration. A contemporary multi-monitor Itanium-based gaming station with liquid nitrogen cooling is really something worth seeing. :)
As for DOSbox, yes, it's one of the most often ported emulators in any new amateur or professional operating system. DOS games were generally as primitive as their host, that's why DOSbox as a program is by no means a complicated piece of software by contemporary standards. That doesn't mean that I don't like DOS games. Leisure Suit Larry (https://www.google.by/search?q=leisure+suit+larry+download&ie=utf-8&oe=utf-8&rls=org.mozilla:ru:official&client=firefox-a&channel=sb&gws_rd=cr&ei=YElfU-6qMemw7QaM0oCYBQ) 's adventures have always been among my favorites.
... friendly ...
No.
... the lost, forgotten and a few of those with good sense ...
Yes.
The Linux community is generally an irresposible, hostile and aggressive environment. My senses of perception, as well as my rationale, would classify the three major operating systems as being oriented towards i) Windows, men, ii) Mac OS X, women, and iii) Linux, their seed. :)
-
I've only notice the BASIC community being a hostile bunch. Other open source projects seem to work together and not create a new version of the same thing just so they can say they could do it. Are we over 150 BASIC variations yet?
-
Who told you a BASIC should be an open source project? How many BASIC's are there under Linux?
From my perspective, a coherent programming language is a filigree piece of intellectual craftsmanship where personal devotion and responsibility is of prime importance. Have you ever seen a coherent and responsible crowd?
Every worthwhile BASIC has a definitive authorship. It's another question that many of them went public domain or open source as soon as they were finalized. But they all do have a definitive person behind them but not a faceless crowd.
There was Linus Torvalds behind Linux. Who's behind it now that it's gone loose? Who should I sue if need be? "NO RESPONSIBILITY WHATSOEVER..." ... ;)
-
How many BASIC's are there under Linux?
I only know of two that are worth using. Script BASIC & BaCon
Not much activity in the Windows commercial BASIC market from what I see.
Android seems to have picked up the slack.
-
I only know of two that are worth using. Script BASIC & BaCon
Tell you what, John. That's because there is warm flesh and blood behind them rather than a list of faceless "contributors".
Not much activity in the Windows commercial BASIC market from what I see.
Do not forget about VB6 that's become de facto public domain and is still usable even on the latest Windows 8.1. There are still [o.k., edit] tens of thousands of programmers using it for both educational and business purposes.
Again, there's also VB.NET which is BASIC all right from VB6's standpoint. And VB.NET is almost as usable as C#.
The patient is more alive rather than dead.
-
Hi Mike,
I get noticeable occasional stuttering of the ball animation in mode 1, (VSYNC 60 fps), otherwise smooth, though 30fps is not comfortable to watch at close range.
my Nvidia card is a GT120 (OEM card), and nearly 5 years old.
Intel Quad core 2.2GHz
OS: Vista Home Premium
I also notice occasional ticks and dropouts in audio, particularly when opening and closing various Windows. Is your system similarly affected?
Somnium
Robert Rich
http://www.youtube.com/watch?v=_SY94KemG0E
-
Hi Charles,
Thanks a lot for your report!
In Vista Aero, I confirm:
-- nearly perfect movement for VSYNC=None/0 (1 or 2 stumbles per session)
-- visible stuttering for VSYNC=60FPS/1 (up to half a dozen stumbles per horizontal run)
-- no stuttering for VSYNC=30FPS/2 (not comfortable, never used on a PC)
In Vista Classic, I'm seeing stutter everywhere, even at VSYNC=30FPS. The worst case is VSYNC=60FPS.
Is your Classic as good as your Aero or as bad as my Classic?
I do not confirm any problems with audio even against background music (do you use it actually for any useful purpose? ;) )
I'm running Vista Ultimate Sp2.
P.S. Our video cards seem to be almost equally old. The stutter may be due to minor incompatibilities of these pieces of HW with modern drivers. Aren't we fighting with windmills, Charles? Petr reports no visible stutter at all on his modern nVidia gear.
-
I switched to classic (XP) display mode, but it does not make any apparent difference.
Stuttering was most frequent when the PC was booted out of hibernation. Vista goes crazy for at least five minutes following reboot, so that does not surprise me.
I think its beneficial to incorporate a compensation system for animations anyway, so that the dymamics are not affected by a fall in frame rate. Ubuntu/Wine seems to set it to 30Hz.
This is my current frame rate monitor. It measures the lapsed time from the previous frame, and adjusts stepn, which is used as a multiplier for all variables controlling velocity. It also counts the number of missed (60Hz) frames for diagnostics.
macro TimeFrame
===============
static sys countn
static float FramePeriod,stepn
scope
static quad t1,t2
stepn=1
t1=t2
TimeMark t2
if t1
FramePeriod=TimeDiff t2,t1
if FramePeriod>.02 'quantum 60Hz 0.0166
stepn=round(FramePeriod*60.0) 'moment scale
countn+=stepn-1 'count missed frames
end if
end if
end scope
end macro
PS
I'll stay with classic mode, it is not not as pretty but windows can be cascaded efficiently, with their titles visible.
-
Charles,
Thanks for this additional input.
My time counter is a little simpler than yours:
macro TimeFrame()
=================
static quad t1, t2
static double FramePeriod
t1 = t2
TimeMark t2
FramePeriod = TimeDiff t2, t1
mult = 1 / (0.01666666666667 / FramePeriod)
end macro
and its mult parameter is used to adjust linear and angular velocities to make them totally independent of the FPS rate, e.g.:
.........
' ML
' FPS-corrected step
my += (mm * mult)
' END ML
..........
or
.............
' ML
' FPS-corrected step
ang1 += (angi1 * mult)
' END ML
..............
Coupled with a continuous single-threaded PeekMessage(PM_REMOVE) + render-when-idle loop, it adds approx. 25% or 26% load on my quad core CPU in all the VSYNC modes, which would equal approx. 50% or 55% load on a dual core CPU. That's perfectly normal for a non-harware assisted (no VBO's, no shaders) OpenGL rendering loop. There's no sense in trying to bring it down artificially any lower by using a Windows timer or Sleep() calls that would only interfere with OpenGL's natural flow and timing of events as well as with VSYNC settings. An OpenGL rendering loop is not supposed to run at zero load when there are dynamic objects moving on the screen.
P.S. You'd be surprised at how many people actually like to stay Classic. The more professional you are, the less are you expected to like OS animations and decorations. Not so for me though - I like to be having all the bells and whistles on. :)
-
O'kay gentlemen,
Here are my mods for OxygenBasic's OpenGL ControlCraft example. It runs perfectly smoothly for me under my XP though it may exhibit image stutter on other platforms.
1. Please go to Oxygen's \inc folder and backup your OpenglSceneFrame.inc and WinUtil.inc files there then copy my files of the same names from the attached zip into this folder.
2. Go to the \examples\OpenGl folder and backup its existing ControlPanels.inc and ControlCraft.o2bas files. Copy my files of the same names from my zip into this folder.
3. Do not use these four files for anything other than my example! They may be incompatible with other examples and/or the existing functionality of OxygenBasic!
4. Make sure your driver is adjusted (http://www.oxygenbasic.org/forum/index.php?topic=1065.msg8949#msg8949) to follow your current program's settings or you won't be able to toggle your VSYNC.
5. Run the ControlCraft.o2bas example the regular way. Select the saucer by left-clicking on its hull and use the arrow keys and/or control panel widgets to navigate it in the scene as you normally would.
6. Click your middle mouse button to toggle VSYNC between None, 60FPS, and 30FPS. Your middle mouse button is the one that's under your mouse wheel.
All my changes to the code in all the four files are enclosed in ' ML / ' END ML blocks.
The sample will run with a minimum load on your CPU (though I actually don't like it). If you see image stutter, please try to comment out all of the function calls starting with timeBeginPeriod(1) down to timeEndPeriod(1) inclusive at the bottom of WinUtil.inc file. Alternatively, you may try and change individual Sleep() settings in this block (though I repeat I do not like to see those calls there altogether. I think upgrading our video cards to newer models would be a wiser solution than trying to control OpenGL timing any better than it controls itself. :) )
Anyway, thanks a lot for your advice and assistance.
.
-
Many thanks, Mike.
I have remapped the paths so that your code will run in it's own folder. Now we can compare :)
Your code is a little more hungry than mine at 60fps. taking 5-8% CPU compared to 2-3% as is, or 3-5% with performance displayed inWindowText (ControlCraftFrames.o2bas). It is surprising that setting window text makes a measurable difference. I did not see any dropouts in my test except for 3 at the very start, and when moving or resizing the window. It is highly dependent on how busy the PC is - playing youtubes, Text-To-Speech etc.
Anyway, I will examine your scheme more closely.
.
-
Thank you, Charles.
I did not see any dropouts in my test...
I am glad it runs OK for you under your Vista. I wasn't able to eliminate stutter under mine though.
... except for 3 at the very start ...
I guess these must be due to some transitional processes until the app's window message flow stabilizes itself.
... and when moving or resizing the window.
That's only natural as the message loop is strictly single-threaded and window message handling has absolute priority over OpenGL renders. A Windows timer would run in another thread allowing for OpenGL rendering to occur even when processing other messages such as WM_RESIZE. But this scheme doesn't use any Windows timers. Instead, its WM_SIZE enforces canvas repaint by a direct call to Render().
It is highly dependent on how busy the PC is - playing youtubes, Text-To-Speech etc.
Yes, it is. The best tactics to run a video game would be to have all other apps shut down and the game process priority, somewhat elevated. When the focus moves to another window but you still want OpenGL action to go on in the background, you would usually pass render control to a timer similar to your own scheme. And finally, a call to Render() would be suppressed in MainWindow() altogether and moved to a WM_PAINT handling routine in a 3D editor environment where constant rendering of the scene is unnecessary.
Anyway, I will examine your scheme more closely.
Looking forward to your further comments. :)
-
Hi Mike, a couple of questions:
Does XP default to 60 fps VSYNC?
Does XP opengl require any sleep time, or is this a normal part of VSYNC'ing?
Using PeekMessage, I'm now getting good results without using ARB calls, sleeps or timers (CPU load 3%) :)
-
Good afternoon, Charles,
Does XP default to 60 fps VSYNC?
All Windows platforms default to 60FPS/1. I don't know the real idea behind 30FPS/2 on a PC; perhaps it was originally meant for laptops with on-board video chips. Now that higher-end modern notebooks may, and actually do, have discrete miniature video cards, they also default to 60FPS but 30FPS still holds true for lower-end business-style notebooks with on-board chips.
VSYNC=1 and VSYNC=2 are actually deprecated settings. The bad effect of fixed-rate VSYNC'ing is that once the scene becomes so heavily populated with static scenery and moving objects that the current OpenGL rendering technique (immediate mode, display lists, vertex buffer objects, or vertex shaders plus the associated fixed or programmable pipe line or pixel shaders) cannot cope with the entire frame within the 1/60 sec. period, VSYNC drops down from 60FPS to 30FPS abruptly. When such drops are momentary due to camera movement, image stutter is inevitable.
My XANEngine was dynamically watching the FPS rate and switched off VSYNC below 60FPS immediately, allowing for my custom calibrated timing procedures written in asm to take over in order to ensure smooth rendering until the camera retuned into a 61FPS area where 60FPS VSYNC would be switched on again.
Slight image tear potentially seen while the scene runs un-VSYNC'ed is a much lesser evil than image stutter caused by abrupt toggling between 60 and 30 FPS.
Modern adaptive VSYNC'ing implements this strategy within a contemporary OpenGL driver directly. The magic number is -1 which you use to set your VSYNC to 60FPS as usual. As soon as the FPS rate drops below 60, OpenGL switches VSYNC off entirely and your application is expected to run un-VSYNC'ed. When the camera comes back to areas that are easier to render, a 60FPS VSYNC is switched on again automatically.
Does XP opengl require any sleep time, or is this a normal part of VSYNC'ing?
No, Sleep() calls with their associated timeBegin/EndPeriod() are there only to satisfy your aspiration for zero CPU load. They are not either necessary or welcome for OpenGL's own timing or VSYNC'ing.
Matter is, immediate mode and draw lists are deprecated features in the OpenGL standard. There have been several attempts to declare them legacy techniques and exclude their support from the standard altogether. Yet it didn't actually happen for the reasons of backwards compatibility and educational/promotional importance. These techniques are however not being optimised in, or further developed for, the modern GPU's any more.
If you switch your rendering to vertex buffer arrays and fixed or programmable pipeline (texture units), you will see your CPU usage drop close to zero at 60FPS VSYNC at no extra programming costs. Once created and uploaded to the GPU, vertex buffer arrays can also be erased from conventional memory. Static vertex data will not be sent from the CPU to the GPU along the data bus any more and there will be only minimum activity on the CPU side of data bus to switch OpenGL's client-side states related to VBO and texture selection.
This is how the CPU and data bus loads would compare in my profiler in real-time deployment of XANEngine to render a fully textured static scene with approx. 250K non-culled polygons in view (CPU - long blue bar, data bus - long cyan bar):
(http://i1240.photobucket.com/albums/gg490/FbslGeek/CPUampBusLoad.png)
The leftmost snapshot employs an RDTSC-based timer with finely calibrated mixture of Sleep(1) and Sleep(0) calls in place of VSYNC=60. In all the three cases, a fixed pipeline of 4 texture units is used to render diffuse+bump+gloss+lightmap textures in one pass and a post-processing pass is added to cover the entire canvas with a tinted quad to simulate the light volume the camera is currently in. A x4 antialiased x4 anisotropic canvas is used with 5 max. mipmap levels of texturing.
Finally, in a multi-threaded vertex and pixel shader application 99 per cent of rendering activity will be shifted to your GPU. Your CPU cores will go Cool'n'Quiet while your GPU fans will be roaring like a Boeing and you will start to meditate in all seriousness about the benefits of liquid nitrogen cooling. At that very moment you shall finally learn the attributes of a true gamer's nirvana. :)
Using PeekMessage, I'm now getting good results without using ARB calls, sleeps or timers (CPU load 3%) :)
Excellent! :D
-
Thanks for your immensely detailed reply, Mike.
My interest is in using Opengl as a regular part of Oxygen's API, which needs to be efficient and feasible on a wide range of hardware. Once, I bought a top-of-the-range PC. It was not a good experience unfortunately. It never worked properly, even after many engineer call-outs and returns. On one occasion, the cooling fan failed on the Radeon card, which filled the room with the unfragrant aroma of baked electronics in a matter of minutes. But the beast made a good radiator for the winter months, and it eventually became spare parts, when the eletricity bill indicated it would be cheaper to buy another box :)
I'm updating all my Opengl examples. Winutil and OpenglScene run the show for most of the GUI samples.
-
Thanks for your updates, Charles.
My workstation is also a very cosy place to spend winter nights at. The fans are blowing warmth onto my legs as the box stands beneath the desktop, and the temperature in the study is definitely three or four degrees higher than elsewhere in my apartment. :)
Looking forward to an updated O2 example pack!