Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Back to designing that API-independent graphics library...

This topic is 6243 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

Still going. Now I''ve got a nice design pattern set up. I''m using the Bridge pattern that''s so popular for this sort of thing.
  class Video
      enum Imp {DIRECTX7,DIRECTX8,OPENGL};
      bool Init(HWND hwnd,uint width,uint height,
          uint colordepth,Imp imp);
      void Uninit();
      VideoImp* imp_;

class VideoImp
      virtual ~VideoImp();
      virtual bool Init(HWND hwnd,uint width,uint height,
          uint colordepth) = 0;
      virtual void Uninit() = 0;

class VideoImpDirectX8 : public VideoImp
      virtual ~VideoImpDirectX8();
      // and so on for other inherited functions

Please ignore any issues like order of declaration, etc.; this is off the top of my head. The user accesses the graphics library via the Video object. Video::Init() instantiates a subclass of VideoImp based on its argument, imp. Video::Uninit() deletes that instance. Any other Video functions map to VideoImp functions. So far, this design has worked--at present, I can fire up and shut down several APIs. And now for the two-fold problem regarding a Bridge-based Bitmap class (using Bitmap, BitmapImp, BitmapDirectX8, etc.): 1) I cannot decide whether drawing a Bitmap should be VideoImp::Draw(const Bitmap& b), Bitmap::Draw(const Video& vid), or Bitmap::Draw(const Bitmap& b). If I remember correctly, DirectX 7 normally uses a surface to draw a Bitmap onto itself, including the primary flipping chain. DirectX 8 renders bitmaps (without transformation) as sprites using the Direct3DX sprite interface. This is secondary to the next problem, as any of these interfaces are susceptible to it. 2) Video obscures its implementation. Bitmap obscures its implementation. But, the actual API drawing operations require API-specific details about both the Bitmap and the Video object (or at least both Bitmaps). So, for example, either BitmapImpDirectX8 has to know about VideoImpDirectX8''s sprite object, or VideoImpDirectX8 has to know about BitmapImpDirectX8''s texture object (fyi, the sprite interface uses textures). If the implementations don''t agree, the Bitmap would naturally need to be recreated to agree with Video. Am I making any sense? I''m trying to get a Bitmap design so that Bitmaps can be: - loaded and drawn to the primary flipping chain or (even better) to another Bitmap - recreated if the user decides to change APIs during runtime - simple enough to declare and use (preferably just "Bitmap b; b.Load(filename);") I feel like implementation hiding is working against itself! I know this is possible, but I haven''t been able to figure it out. Some of the more veteran programmers on this board have talked about this stuff before in previous threads, but I couldn''t find anything on this issue. Thanks for your patience. --- blahpers

Share this post

Link to post
Share on other sites

  • 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!