OpenGL and DirectX together?

I would like to have my program execute both OpenGL and DirectX calls together. Is this possible? Does anyone have any experience doing this? If so, do you have any helpful hints?

It’s not possible to use OpenGL & Direct3D at the same time.
It is possible to use OGL & DirectSound, DirectInput, DirectEtc.

If you want to switch between OGL & D3D at runtime you could have a look at the following article: http://www.gamedev.net/reference/programming/features/rendererdll/

the link is dead and the issue is very relevant to me. Anyone have more info? I am working on a plugin app that uses openGL but might have a host app that uses Direct3D

My suggest: USE DIRECT3D 9.0 ONLY and all will be fine.

if you create 2 separate windows, one with OpenGL and one with DirectX, there is no reason why it should not work. just do it.
if you want to use directX to switch to fullscreen and opengl to draw your stuff - go on, no problem.
if you want to setup your blending in opengl and draw your primitives with directX…in that case you need serious help: http://www.opengl.org/about/overview.html http://www.opengl.org/resources/faq/getting_started.html

I’m not trying to mix with Direct3D I control my own gl contexts and windows. It’s just that I may be doing this in a 3d party exe and thread that uses DirectX or even Direct3D. As a plugin I don’t control what the exe does.

I’ve been seeing wierd behavior where calls to gl just crash when we’re run within certain applications that use DirectX. So I was wondering if it is possible to do something in DirectX / 3D that would make use of gl in the same exe impossible

Sorry for my post.
Dear programmers (who using both OpenGL and Direct3D)! What API You like more: OpenGL or Direct3D, what is more powerful (You think)?

Originally posted by vmh5:
[b]I’m not trying to mix with Direct3D I control my own gl contexts and windows. It’s just that I may be doing this in a 3d party exe and thread that uses DirectX or even Direct3D. As a plugin I don’t control what the exe does.

I’ve been seeing wierd behavior where calls to gl just crash when we’re run within certain applications that use DirectX. So I was wondering if it is possible to do something in DirectX / 3D that would make use of gl in the same exe impossible[/b]
If you have access to the host window handle, you may get away with filtering the message queue, killing WM_DRAW messages for starters. SetWindowLong can change the window procedure, and there are other ways documented in the platform SDK.

That’s no safe way of stopping all drawing but it may be enough. I’ve only started experimenting with this right now, so I can’t offer more details.

Originally posted by AdrianD:
if you want to use directX to switch to fullscreen and opengl to draw your stuff - go on, no problem.

I doubt that’s really the case. I’ve read a number of discussions about how you simply can’t rely on this working.

Thanks I’ll keep that mind. The problems I’m seeing are already manifest at initializing gl. Simple stuff like wglCreateContext & wglGetProcAddress will crash. In some cases this was driver related but in other cases it happens with particular hosts independent of card / driver / system.

According to the spec, creating one context in one HWND/DC for Direct3D, and another context in another HWND/DC for OpenGL, should work.

Now, if you get a crash or mysterious behavior in this situation, I’d predict one of two responses from vendor support:

Predicted response from one of the “big three”: Oh. I agree that shouldn’t crash. Could you send a reproduction case? We’ll put that somewhere in the pile of things that shouldn’t happen, and we’ll get to it at some point.

Predicted response from most “value brand” hardware vendors: <crickets>

I’ve found that if you stray from the Quake path in OpenGL, you’ll be unhappy on the value brands. They seem to have vaguely better Direct3D support, probably because Microsoft publishes an “easier” path to get “most of the benefit” in their driver model for Direct3D.

Originally posted by jwatte:
According to the spec, creating one context in one HWND/DC for Direct3D, and another context in another HWND/DC for OpenGL, should work.
I’d be glad if it did. The fun starts as soon as the two windows overlap. And when I say “fun”, I mean it

ATI, NVIDIA and PowerVR drivers all go nuts over this, in different ways, and have done so consistently with all generations of cards and drivers I’ve seen.
They don’t seem to be able to stomach concurrent buffer swaps on overlapping windows. At least not if the windows live in the same process.