Quick question about OpenGL context

Started by
7 comments, last by ChugginWindex 13 years, 2 months ago
I'm just wondering about how safe/easy it is to create graphics code that uses OpenGL in a DLL and then link that into other EXEs. I tried Googling/searching the forums already and I didn't really get a definitive answer. I'm not trying to do anything fancy like share contexts between two EXEs simultaneously or anything like that, so I'd be fine with a solution that started a new context for each exe that linked to the dll or whatever. Mainly I just want to be able to create a basic renderer in a DLL with some extras like font drawing and such that I can use in different applications easily.

Am I going to run into any problems if I do it this way? I read somewhere that I'd at least have to do my window creation in the exe...well I expected as much. So really I'm asking if my design is going to explode if I, say, create an OpenGL window in an exe, and then make calls to OpenGL from a DLL that is linked into it. Also, if that all works fine, will I run into any problems if I try linking to separate programs to the same DLL at runtime? Like if I had an editor I wrote that used the same graphics DLL or something.
Advertisement
Quake II did it back in 1997; it works.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Well if it works for Quake it'll work for me! Thanks.

But if anyone has any other input on this topic, I'd like to hear it. I'm going ahead with starting this based on the info I have now, but if there's more to it I'd like to learn more.
You should have no problems at all. I've done it before (creating the DLL in and for use in VB6). It's also what I'm currently in the process of doing with my new renderer.
So like what I want to do is have my DLL keep track of a variable that determines if a window is currently set up for OpenGL. If I declare this variable internally in the DLL, and then provide an exported function EnableGraphics() to the EXE, when the EXE calls that function it will tell the DLL it's safe to start making OpenGL calls. However, say I have an EXE for a Game, and one for a Map Editor, and they both link in the same graphics DLL. In this scenario, what happens when I try to call EnableGraphics from both the EXE and the Map Editor? They both map the DLL's memory separately don't they? So if the game calls EnableGraphics(), the map editor's DLL should still claim that graphics haven't been enabled or vice versa, correct?
When a DLL is linked it has done so within the EXE's own address and memory space. So if you have your Game and the Map Editor running, you'll have two instances of the DLL 'running'. Not one, so they won't be shared across the applications.
Keep in mind, however, that even when a dll is actually mapped in the same address space as the loading process, it nonetheless has its own heap! So everything allocated (like, with 'malloc' or 'new') by the exe must be freed by the exe, and everything allocated by the dll must be freed by the dll.

This has caused me quite a lot of hadaches! ;)

+1 for that sgt_barnes, I wasn't aware of that, can imagine that would've given me quite a few headaches as well.
Yeah, I've had my troubles with that as well and learned my lesson a while back. I've actually done a bit of work with DLLs and EXEs, but I'm starting a new project from scratch and had my concerns about what actually happens when two EXEs load the same DLL. Thanks for the info.

This topic is closed to new replies.

Advertisement