🔒 Locked

Fullscreen vs Window

Started by twentytwo Jun 5, 2006 at 12:26 PM 15 replies 5.1k views

Original Post

Jun 5, 2006 at 12:26 PM

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.

lc_overlord

Jun 5, 2006 at 6:50 PM

It might have something to do with XP giving less priority to the program when it's overlapped.
If xp gives a lower priority it results in lower cpu usage.

Lesson 5 runs so fast that any slowdown would be unnoticable, but you could try using fraps to see the fps

twentytwo

Jun 5, 2006 at 7:14 PM

(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

dtaylorjr

Jun 5, 2006 at 8:26 PM

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

lc_overlord

Jun 5, 2006 at 9:13 PM

Quote:
Original post by twentytwo
(Argh... I forgot OS...)

Both are Windows 2000.

Dosen't matter it's the same underlying system anyway, xp just has more updated code and a fancier ui.

Quote:
Original post by twentytwo
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

well it doesn't really need to slow down that much for it to decrease the work load, it might just be that whenever it samples the workload (witch happens periodicly not constantly) the workload drops intermittedly because the program has other things to do.

Quote:
Original post by twentytwo(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...)

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
this msdn link explains the sleep function a little better.

CrazyCdn

Jun 5, 2006 at 9:33 PM

Don't forget sleep has a variance too, it's not very accurate.

twentytwo

Jun 6, 2006 at 12:25 PM

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

twentytwo

Jun 6, 2006 at 2:00 PM

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

twentytwo

Jun 6, 2006 at 5:57 PM

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

twentytwo

Jun 8, 2006 at 7:01 PM

lol...

SDL ... is ... DirectX.

Simple DirectMedia Layer
-22

P.S.
I was using Managed Direct X 9.0c before this, but the target machine offers very little support for DirectX 9... (and I found that OpenGL offers some interesting advantages when it comes to raster fonts... - which for my current project serves as the majority of my display - I just want 3D...)

n4x0

Jun 11, 2006 at 5:34 PM

Quote:
Original post by twentytwo
lol...

SDL ... is ... DirectX.

Simple DirectMedia Layer
-22

What? Sorry but if I'm not wrong... SDL uses openGL :P

PS: Hey! This is my first post here :P

twentytwo

Jun 12, 2006 at 6:01 PM

Here's a quote from the official site's main page:

"
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.
"

http://www.libsdl.org/index.php

If you go to Documentation on that same site, here's what it says:

"
Win32 -
* Two versions, one safe for all systems based on Win32 APIs, and one with higher performance, based on DirectX APIs.
* Safe version uses GDI for video display. High performance version uses DirectDraw for video display, taking advantage of hardware acceleration if available.
* Safe version uses waveOut APIs for sound. High performace version uses DirectSound for audio playback.
"

http://www.libsdl.org/intro.en/whatplatforms.html

Sounds a bit fishy, but it's true. For Win32, SDL is DirectX. (Since OpenGL is a Graphics Language, it doesn't support sound directly and thus relies on other APIs for various other systems - which makes that first quote sound kind of silly ; as a matter of fact, none of the implimentations really suggest it uses OpenGL at all...)

-22

twentytwo

Jun 12, 2006 at 6:36 PM

Okay, I did a little digging and apparently, SDL just has an OpenGL flag you can set to use OpenGL with SDL, but otherwise, its functionality is in fact DirectX in Win32 (which is why you can't mix SDL surface functions with OpenGL video buffer manipulations - DirectDraw and OpenGL don't mix...).

As for the topic on hand, there i s a chance the problem may have something to do with Microsoft's not liking OpenGL - I'll update the video card's OpenGL ICD / video driver and see if the problem goes away (this may take a day or two).

-22

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.