Advertisement

Inheriting from a dynamically linked library?

Started by June 13, 2001 03:42 PM
1 comment, last by wazoo69 23 years, 8 months ago
Hi everyone... What I''m trying to do, I *think* can be done, I''m just not sure how.. Here''s a little background to my problem... I''m developing a small 2d game engine for Directx8 and OpenGL renderings. I''ll write out a sample of my class design..
  
class IRenderer {
public:
  virtual HRESULT initScene() = 0;
  virtual HRESULT destroyScene() = 0;
};

class D3DRenderer : public IRenderer {

public:
   HRESULT initScene();
   HRESULT destroyScene();
};

class OGLRenderer : public IRenderer {

public:
  HRESULT initScene();
  HRESULT destroyScene();

};

  
Okay so you get the basic idea. (of course all the classes have their constructors,etc, but I was trying to get rid of all the clutter...) So The OGLRenderer and D3DRenderer classes are separated into 2 DLL''s which are linked in during runtime.. What I''m HOPING to do, is give the user of my engine the ability to DERIVE a new class from OGLRenderer, yet keep the ability to use IRenderer functionality...did that make any sense? What I want to do is to be able to derive from either the D3DRenderer or OGLRenderer class, which will let me override the initScene and destroyScene functions for my application purposes, yet allowing me to switch over to either of the OpenGL or Direct3D renderers... Did that make any sense?? If nobody understands what I''m trying to question, I''ll make another stab at describing what I''m trying to do.. thanks, Wazoo
Learn about game programming!Games Programming in C++: Start to Finish
You can use contaiment.
  class IRenderer {public:    virtual HRESULT initScene() = 0;   virtual HRESULT destroyScene() = 0;};class OGLRenderer : public IRenderer {public:  HRESULT initScene();  HRESULT destroyScene();};// The derived Interface in another dllclass IRenderer2{public:    virtual HRESULT initScene() = 0;   virtual HRESULT destroyScene() = 0;   virtual HRESULT SomeAdvanceThing() = 0;};class OGLRenderer2: IRenderer2{     OGLRenderer2() { m_IRenderer= /*make a valid pointeur*/;}     virtual HRESULT initScene() { return IRenderer->initScene(); }     virtual HRESULT destroyScene() { return IRenderer->destroyScene(); }     virtual HRESULT SomeAdvanceThing() { /*Your code*/}     IRenderer*  IRenderer;}  


You want probably something better, but I haven''t better. Remark than if your advancethings have nothing to do w/ OpenGl nor DX, you haven''t to write twice the same things.

Hope it help.





Why English rules?? C pas très malin tout ça!
_______________
Jester, studient programmerThe Jester Home in French
Advertisement
Actually I did some rethinkin'' on the idea, and it''s a BAD one..(mine, not jester''s suggestion)...

Ideally I''d like to be able to plug in new DLL''s for new graphics API''s as they become developed...ie. say a Glide implementation..

If I allow people to derive from classes in the DLL, then the engine would no longer work in EVERY graphics API''s...

I guess I have to work my design a little better...I just want something a bit similar to the UT engine...so that when I create/edit new projects, I can just extend the classes within the engine WITHOUT touching graphics API specific data..(ie. separate my graphics calls from application calls)..

hmmm back to the drawing board!

If anyone has any other design suggestions that might be relevant, please feel free to post!

thanks,
wazoo

Learn about game programming!Games Programming in C++: Start to Finish

This topic is closed to new replies.

Advertisement