Jump to content
  • Advertisement
Sign in to follow this  
ChugginWindex

OpenGL Quick question about OpenGL context

This topic is 2804 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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! ;)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!