Geforce GTX 275 - OpenGL initialisation problem when program is started from the commmand console.

Hello all,

Recently I noticed that in a program I wrote (using OpenGL) the texture
"moves" over the quad it was put upon as if its drunk (the texture sways
from side to side depending on the (horizontal) angle of the camera towards
it. Also, when I moved toward the (rather simple) scene the redrawing
started to stutter, as if the redraw took a lot of time - for me an
indication that the whole thing was running on software, instead of using
hardware accelleration.

I first presumed I must have done something stupid, but at some point I
noticed that it only happened when I started the program from the
commandprompt, but not when double-clicking it (already being in a GUI).

The thing is that the exact same program on another computer has zero
problems being started either way - an indication is driver/videocard
related.

Does anyone here recognise the problem and videocard, and knows if this is a
simple settings problem - and in that case which one ?

The OS is XPsp3 Pro. The videocard is an nvidia Geforce GTX 275.

Regards,
Rudy Wieser

R.Wieser wrote:
Hello all,

Recently I noticed that in a program I wrote (using OpenGL) the texture
"moves" over the quad it was put upon as if its drunk (the texture sways
from side to side depending on the (horizontal) angle of the camera towards
it. Also, when I moved toward the (rather simple) scene the redrawing
started to stutter, as if the redraw took a lot of time - for me an
indication that the whole thing was running on software, instead of using
hardware accelleration.

I first presumed I must have done something stupid, but at some point I
noticed that it only happened when I started the program from the
commandprompt, but not when double-clicking it (already being in a GUI).

The thing is that the exact same program on another computer has zero
problems being started either way - an indication is driver/videocard
related.

Does anyone here recognise the problem and videocard, and knows if this is a
simple settings problem - and in that case which one ?

The OS is XPsp3 Pro. The videocard is an nvidia Geforce GTX 275.

Regards,
Rudy Wieser

I don't know all the details of how this works, but a dual
head video card seems to have two "accelerated channels" max
to use. If one of the accelerated channels loses its driver
(this has happened to me), then only the original context
is accelerated, and you could tell there was something
wrong when a second program wanted to use acceleration.
The second context would stutter.

I think one driver that came with the Windows OS install disc,
suffered from this problem. Installing a later proprietary
driver, fixed it. (I could iconify a game, and open a
second application that needed acceleration, without a problem.)

And I don't know if there are any utilities for detecting this either.
Stuff like GPU-Z provides a lot of info, but it's basically "card-wide"
properties. And there is also an OpenGL utility "glview500.exe"
which has "openglex.exe" as its installed executable. But it
does not illuminate the two display channels either. There's
no evidence that a context is missing because of a driver
problem when using that. I seem to have more than one version
of that floating around, and the installer for glview500 said
"there's already one installed" and perhaps that's an older
version.

C:\Program Files\realtech VR\OpenGL Extensions Viewer 3.0
openglex.exe 663,040 bytes (properties pane is blank!)

Paul

Paul,

I don't know all the details of how this works, but a dual head video card
seems to have two "accelerated channels" max ....

Thanks for the explanation. I was not even aware that there was more than a
single hardware acceleration "pipe" present.


After mulling over what you wrote I realized I forgot to mention something
thats (most likely) important : My "command prompt" window is full-screen
(80x25 char). So when a GUI program is started the OS first has to switch
from text to graphics mode.

In other words, My hunch is that the mode switching is the culprit here (the
OpenGL 3D initialisation done when the display isn't fully in graphics
mode).

and you could tell there was something wrong when a second program wanted
to use acceleration. The second context would stutter.

For a test I started the program three times (present at the same time) :
The first from a fullscreen commandprompt. It has the 'drunken' texture.
The second from a windowed commandprompt. It works OK. The last one by
doubleclicking the program (in the file explorer). It works OK too.

If its a "no more acceleration pipes available" I would have expected the
latter two to have problems too.

I also started them in reverse order. Still only the program started from
the fullscreen commandprompt has the 'drunken' texture.


For another test I made the program display a messagebox before creating the
dialog (causing the OS to switch to GUI mode before initializing the 3D
environment), and surprise, surprise, no more 'drunken' texture or
stuttering.

In other words, all of the above tests seems to confirm my suspicion that
the switching from text to graphics mode causes the problem ...


I still wonder why that the Geforce GTX 275 videocard has a problem with it
(or which settings gouvern it), but a build-in videocard (and accompanying
drivers) of my Optiplex 745 'puter doesn't.

By the way: I also tried to change the hardware acceleration support itself
(rightclick on desktop - properties - settings - advanced -
troubleshoot - slider), but that didn't change anything.


.... crap. I wanted to keep it an small question. Not a waterfall of tests
and hunches. :-\

Regards,
Rudy Wieser

(x-posted/continued from microsoft.public.windowsxp.general)

After mulling over what you wrote I realized I forgot to mention something
thats (most likely) important : My "command prompt" window is full-screen
(80x25 char). So when a GUI program is started the OS first has to
switch from text to graphics mode.

I think I've narrowed the problem down to the ChoosePixelFormat function
(might be a red herring though ...). When I start the program from a full
screen console window the returned result is 0x4, but when I start it from
within the GUI the result is 0x7. (no idea what those numbers mean, as MS
doesn't seem willing to part with that kind of info - not described with the
above function, SetPixelFormat or the involved structure).

I also just spend an hour or two trying to re-initialize the OpenGL DC, but
was twarthed by not being able to choose a new pixel format for it (which I
only noticed/read *after* having spend all that time. :-\ )

I guess the new question is: Other than delaying the calling of the
ChoosePixelFormat function (and with it the whole OpenGL context
initialisation - which causes its own problems), how to I get the
ChoosePixelFormat function to return a result in reference to a GUI DC ?

Regards,
Rudy Wieser

R.Wieser wrote:
(x-posted/continued from microsoft.public.windowsxp.general)

After mulling over what you wrote I realized I forgot to mention something
thats (most likely) important : My "command prompt" window is full-screen
(80x25 char). So when a GUI program is started the OS first has to
switch from text to graphics mode.

I think I've narrowed the problem down to the ChoosePixelFormat function
(might be a red herring though ...). When I start the program from a full
screen console window the returned result is 0x4, but when I start it from
within the GUI the result is 0x7. (no idea what those numbers mean, as MS
doesn't seem willing to part with that kind of info - not described with the
above function, SetPixelFormat or the involved structure).

I also just spend an hour or two trying to re-initialize the OpenGL DC, but
was twarthed by not being able to choose a new pixel format for it (which I
only noticed/read *after* having spend all that time. :-\ )

I guess the new question is: Other than delaying the calling of the
ChoosePixelFormat function (and with it the whole OpenGL context
initialisation - which causes its own problems), how to I get the
ChoosePixelFormat function to return a result in reference to a GUI DC ?

Regards,
Rudy Wieser

But based on your knowledge of the zillion ways to design
"error numbers", you know 0x4 and 0x7 are not errors. And you
also know that Microsoft loves GDI and hates OpenGL.

https://www.khronos.org/opengl/wiki/...OpenGL_Context

A returned value of 0x0 means it could not find a matching
pixel format. You got a pixel format value of 0x4 in one case
and 0x7 in the other case. These values are then passed
to SetPixelFormat.

In the order of things, you open a graphics window first.
That's what this seems to suggest. Even if opened from the Command
Prompt, you probably open one of these, just so you have
an actual window in the picture.

"The Window Itself

When you create your HWND, you need to make sure that
it has the CS_OWNDC set for its style."

"PFD_DRAW_TO_WINDOW ===" [suggests a window needs to be in the picture]

And there are articles on doing it the hard way.
In this example, a fake window is used to build a context,
then the program switches over to the prepared OpenGL context
and releases the fake window.

https://mariuszbartosik.com/opengl-4...t-a-framework/

Also, I tried tossing in "GDI" in a pixelformat search for
Windows in Google, and these might well be the enumerations
you seek. Perhaps if you toss enough of those into Google,
you'll eventually find a gdi.h or something.

https://docs.microsoft.com/en-us/win...rmat-constants

PixelFormat1bppIndexed
PixelFormat4bppIndexed
PixelFormat8bppIndexed
PixelFormat16bppARGB1555
PixelFormat16bppGrayScale
PixelFormat16bppRGB555
PixelFormat16bppRGB565
PixelFormat24bppRGB === 0x7 ???
PixelFormat32bppARGB
PixelFormat32bppPARGB
PixelFormat32bppRGB
PixelFormat48bppRGB
PixelFormat64bppARGB
PixelFormat64bppPARGB

Paul (who is obviously not a programmer)

Paul,

First off, thanks for the help. I appreciate it - even if you're not a
programmer :-p

But based on your knowledge of the zillion ways to design
"error numbers", you know 0x4 and 0x7 are not errors.

In this case, absolutily. Its fed into the SetPixelFormat function, which
is rather unlikely if it would be an error number. Besides, the
ChoosePixelFormat's description mentions it as "the return value is a pixel
format index (one-based) that is the closest match to the given pixel format
descriptor."

And you also know that Microsoft loves GDI and hates OpenGL.

The both of the above are in fact GDI functions. Doesn't mean that they
could not OpenGL at the same time though. :-)

In the order of things, you open a graphics window first.

Currently I'm initializing the OpenGL context in the WM_CREATE event of the
control (which is placed in a dialog). At that moment nothing has been
drawn yet - though the OS should be aware that whatever gets drawn should be
done in the GUI mode. As indicated in the header of the executable.

When you create your HWND, you need to make sure that
it has the CS_OWNDC set for its style."

Just added it, but it doesn't (seem to) make a difference.

"PFD_DRAW_TO_WINDOW ===" [suggests a window needs to be in the picture]

As the end result ? Yes. (as opposed to a(n invisible) memory DC).

And there are articles on doing it the hard way.

Several. I took my cues from a "NeHe productions" tutorial
http://nehe.gamedev.net/tutorial/lessons_01__05/22004/

As for the hard way ? What do you mean ? I'm programming in Assembly,
meaning I have to do /everything/ myself. :-)

Also, I tried tossing in "GDI" in a pixelformat search for
Windows in Google, and these might well be the enumerations you seek.

I cannot verify that. I googled for "#define PixelFormat24bppRGB", and
got several like this:

PixelFormat24bppRGB = 8 | (24 8) | PixelFormatGDI

http://caca.zoy.org/browser/libpipi/...PixelFormats.h

, which are always large, bit(/byte)-mapped numbers (and not just a small,
one-based index).

(Don't you just hate it when MS throw a list with names at you, but
"forgets" to mention the values that they represent ?)

Perhaps if you toss enough of those into Google,
you'll eventually find a gdi.h or something.

:-) See above. I searched some more, but nothing that I get an "Ah HA! So
/thats/ it " feeling with.


Currently I am, in regard to the setting-up of the OpenGL context (and
specifically the ChoosePixelFormat function), at the end of my rope. I have
no idea why it would return different results depending on from which
environment (CLI / GUI) it is started, and thus no idea how to fix it.
And even less why it works for one machine, but not for another (probably
videocard driver related, but thats just a guess)

But after a lot of pondering about a dependable, but at the same time simple
way to get the initialisation of the OpenGL context delayed I got a
brainfart: Though its hackish, it seems to work nicely: Before creating
the "OpenGL dialog" I first create a modal dialog which closes as soon as it
fully created, forcing my program to switch to GUI mode(1). That way the
"OpenGL dialog" itself is never started in CLI mode.

(1) I did first search for a "switch to GUI mode" method/function, but was
unsuccessfull in it. :-\

Regards,
Rudy Wieser