Hey, I got this weird problem... I recently completed a course on game development which had us work with NeHe's tutorials (I was able to finish the first 21), and this was my first introduction to OpenGL, as opposed to DirectX. Well, over the last few days I was working in VB.NET, with the Tao Framework, and stumbled upon a really strange problem. At first I figured it was either .NET or Tao, but the problem shows up in NeHe's lessons (C++) as well. It's not a program-crash kind of problem, but it still urks me simply because I can't fix it or even explain WHY it happens... So here's how it goes: (I use Lesson 5 to demonstrate this, simply because it's the simplest one with semi-complex animation - also, I add a Sleep(32) command at the end of the while loop in order to get readable CPU usage curves on the Task Manager) First off, I have two computers: one development and one target. The dev is 2.3GHz 128MB-GeForce2 Dual-Core and the target is a 1GHz 32MB-Intel Single-Core. The target is the only machine weak enough to demonstrate this on as the dev barely registers it at all. I start off by starting the Task Manager and waiting until the CPU usage curves stabilize. I then run the program (lesson 5 with Sleep) in Fullscreen mode. After 30 seconds, I Window the screen (F1) and check the CPU usage. On the target, it's 0%. I then let the program run in Windowed mode and watch as it stabilizes at 20%. This is the first thing that strikes me as a bit odd. However, one can say that MAYBE my Video Card offers more optimization in Fullscreen than in Window mode (some optimizations may only be available in full screen) or MAYBE the fullscreen gets Exclusive access thus not competing with the other programs. However, that's just a newbie guess and isn't really the problem... Here's where it gets a bit Weird. As the program runs in Windowed mode, I then take Task Manager and overlap the window so that the Task Manager partially covers the Lesson5 window. The CPU usage stays at 20% UNTIL a certain portion of the window gets covered (half the window in C++ and any portion crossing the horizontal midpoint in .NET !?), at which it quickly drops down to 0% and then randomly jumps up and down between 0 and 20% in a non-stable cyclical motion, while STILL updating the screen... (there's not even any slowdown...) The one thing I hate is a quirk I can't work around. If you guys have any ideas, I'd love to hear them... -22 P.S. You said something about re-writing the lessons at some point, and it would be good if this kind of thing was addressed, since the first tutorial introduces the Fullscreen and Window mode-switch for Windows.

(Argh... I forgot OS...)

Both are Windows 2000.

Now, I'm not necessarily disagreeing with you, since that CAN explain the overlap oddity; though maybe not the fact that it doesn't SLOW DOWN when it does get overlapped. Also, spending all its time Sleeping gives it practically NO priority already (remember, all this program DOES is draw a rotating pyramid and cube with some blended colors and last sleep for 32 milliseconds - the drawing CANNOT take more than 32 milliseconds, so for the majority of time, it's Sleeping...), as more demanding programs typically are given more of the cpu. In actuality, the only way less priority would matter is if the program had something to execute during that sleeptime, like being bombarded with excess Windows Messages; however, I wouldn't think THAT to be the case... It would have to be spinning its wheels somewhere, but the only busy loop in the program should have been halted by adding the Sleep... (in fact, one would argue that overlap would INCREASE the RePaint messages and thus CAUSE more work as opposed to the opposite...)

Of course, this doesn't explain how Fullscreen gives 0% and yet Windowed gives 20% when both are doing the same thing (practically sleeping)... unless its a combination of the above, which again tells me nothing...

As such, it doesn't really give me a way to avoid it... or a way to be certain that those are reasons why its happening, so...

hmmnnn....
-22

If I were you, I would only support full screen. Besides who wants to play a game in a window.

Look, I'm not trying to be rude here, but...

I'm very familiar with multithreading applications, and I AM aware that Sleep is both inaccurate and a minimum at best. The purpose of Sleep in this function, I repeat, is ONLY to prevent the main LOOP from maxing the CPU to 100% (which on that machine, it does), thus preventing a busy wait and allowing the Task Manager to give a fairly accurate curve for the CPU usage (or as accurate as I currently need it to be...). I know Threading looks like a good culprit here, and it IS the obvious one... however, it's wrong. It's a good guess and I admit I didn't think of it myself, but it is most definitely not the right one...


Same Problem, Lesson 3... (with Sleep)

Flat Polygon Shading, Fastest perspective Hinting

Active: 20% .... Inactive: 20%

Remember that NeHE lessons don't draw ANYTHING when active is set to false and only loop (in this case Sleep). But, they DO process Windows Messages...


Same Problem, Lesson 1... (with Sleep)

Active: 20% .... Inactive: 20%

This is NOT due to the program's workload. The Window is OBVIOUSLY causing this, and the culprit is most likely the CreateGLWindow() function (the Class used to instantiate the window), or if I had to make a guess, the Window styles used to set which events the program is responding to.

NEVER in my brief history of writing Win32 Applications (.NET or otherwise) have I EVER been unable to get my program to Idle at 0%. The only difference between now and then is OpenGL and the format of the Window used to display it (or the fact that the code is written by someone other than myself...). Since OpenGL reacts the same in Fullscreen AND in Windowed Mode, I can be fairly positive that OpenGL is not pumping the clock at 20%. Usually when this occurs, the problem is the window settings...

It's definitely something that needs to be looked into...

More as it develops...
-22

Quote:

Quote: the drawing CANNOT take more than 32 milliseconds, so for the majority of time, it's Sleeping...

No,In fact it does take at least 32 seconds + the rendering time + the extra sleep time after the 32 milliseconds are up when other things are executed...

Sorry, I just wrote that badly. It's very unlikely that the rendering would exceed 32 milliseconds and the Sleep would simply delay for 32+ milliseconds. When I wrote that, I was trying to say that the Sleep time should always exceed the rendering time and thus the program would MOSTLY be sleeping and not actually doing much work (other than handling windows messages). In other words, it has no real reason to be consuming 20% of the CPU's cycles while spending all its time sleeping...

***

Well, I tried changing all the Windows styles and that didn't work... so it looks like maybe it might just BE OpenGL... (for some reason, the Windowed mode is just cranking without any real reason to do so...)

I'm really not sure what to do here...

If I figure anything out, I'll post back.
-22

Well, it looks like I've narrowed it down, at least somewhat.

I went back to lesson 3 (with Sleep) and removed the Double Buffering from the pfd descriptor. When I ran the code, the dev machine flickered like a horrible mess. I then walked over to the target machine and ran the code and was happy to see 0%; only problem was that nothing was appearing on screen (it was an empty non-updating window frame). Checking the code, I knocked myself upside the head and then replaced the SwapBuffers command with glFlush. I ran it again on the dev and noticed a bit less flicker this time. Happy, I walked over and ran it on the target: it ran beautifully, in fact very beautifully - no flicker at all and only at... 20%.

Okay... now I'm in a whole new world of weird...

So here's what I'm thinking: the problem doesn't lie in the OpenGL runtime or even in the Window itself but rather when OpenGL WRITES to the Window. Irregardless of the effort involved, if it fails to write, 0, and if it succeeds, 20. Here's the burn: I can't fix that. (In other words, it's a problem with the GDI components, like the pfd - and I have no idea how to fix that without going GLUT - which is not acceptible for what I'm working on)

As for single-buffering being equivalent to double-buffering, I have absolutely no idea how that makes sense...

-22

lol this may be a noobish comment:P Try it using SDL, never trust microsoft