OpenGL Erroneous Context Version

Started by
13 comments, last by Brother Bob 10 years, 11 months ago

Unfortunately, I can't really make a minimal sample; an identical program's source works in one project, but the same code fails when recompiled in a different project. It's very bizarre.

Run a diff on the project files to find exactly what lines are different, then change one after another until it works.

If you make a minimal example, depending on your environment, that should be just one .cpp file (identical) and one project file (different).

Advertisement

Just create the context, there's no need for the hidden window there. If you want to create windows at will, then do that, and keep the context as a separate object and bind the two at some point (for example when rendering you attach the desired context to the desired window).

Ummm . . . both wglCreateContext and wglCreateContextAttribsARB take a device context as an argument; I assumed that can only come from a valid window?

That doesn't mean the context is tied to that window in any way (it is tied to its pixel format though, so you could say there is some connection, but that only limits which contexts can be tied to which windows). In order to create a rendering context, you need a window, yes. But you can move that context around as you like, with and without a window. You don't need the context to have a hidden window, you only need a window to create it.

It is perfectly fine to separate the concepts of windows and rendering contexts. The window holds a window, and the rendering context holds a rendering context; no need for hidden windows anywhere for this reason. Just tie a rendering context to a window before rendering.

Run a diff on the project files to find exactly what lines are different, then change one after another until it works.
If you make a minimal example, depending on your environment, that should be just one .cpp file (identical) and one project file (different).

The .sln, .vcxproj, .vcxproj.filters, .vcxproj.user files are the same, except for (some) hash values and the project names. I'll see if I can perturb it into/out of existence another way.

The program that fails uses a library that uses a library that uses the library where the windowing code is defined.

In order to create a rendering context, you need a window, yes. But you can move that context around as you like, with and without a window. You don't need the context to have a hidden window, you only need a window to create it.

Yes. To clarify, the hidden window exists only to create the context. This hidden window is local to my context class. User windows can be created and destroyed completely independently of the context--in fact, this is exactly the point of this design.

[size="1"]And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.
[size="2"]

I'll see if I can perturb it into/out of existence another way.

Amazingly, the differences continue to shrink. I can literally copy working project files to the same directory, rename them, add them to the solution, and the original project works while the copied one breaks.

I strongly suspect the hash values are magically the problem. Can anyone guess why they'd cause a weird error like this?

[size="1"]And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.
[size="2"]

In order to create a rendering context, you need a window, yes. But you can move that context around as you like, with and without a window. You don't need the context to have a hidden window, you only need a window to create it.

Yes. To clarify, the hidden window exists only to create the context. This hidden window is local to my context class. User windows can be created and destroyed completely independently of the context--in fact, this is exactly the point of this design.

Ok, then I apparently misunderstood you. I though the hidden window followed the context, but if you create it temporarily just for creating the context, and then destroy it immediately and forget about it as soon as the context is created, then that's a bit better. But I would use one of your primary windows instead, since that force you to actually have a real window as opposed to just a temporary throw-away window in order to have a rendering context. It also ensures that the pixel format of the rendering context is compatible with the window(s) it is supposed to be used with.

This topic is closed to new replies.

Advertisement