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

[R.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

[Paul]

Post by R.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

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/Creating_an_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-x-initialization-in-windows-without-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/windows/desktop/gdiplus/-gdiplus-constant-image-pixel-format-constants

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

Paul (who is obviously not a programmer)

[R.Wieser]

Paul,

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

Post by Paul
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."

Post by Paul
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. :-)

Post by Paul
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.

Post by Paul
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.

Post by Paul
"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).

Post by Paul
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. :-)

Post by Paul
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/trunk/win32/gdiplus/include/GdiplusPixelFormats.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 ?)

Post by Paul
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