If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 |
Ads |
#2
|
|||
|
|||
Geforce GTX 275 - OpenGL initialisation problem when programis started from the commmand console.
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 |
#3
|
|||
|
|||
Geforce GTX 275 - OpenGL initialisation problem when program is started from the commmand console.
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 |
#4
|
|||
|
|||
Geforce GTX 275 - OpenGL initialisation problem when program is started from the commmand console. Update
(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 |
#5
|
|||
|
|||
Geforce GTX 275 - OpenGL initialisation problem when programis started from the commmand console. Update
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) |
#6
|
|||
|
|||
Geforce GTX 275 - OpenGL initialisation problem when program is started from the commmand console. Update
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 |
Thread Tools | |
Display Modes | |
|
|