Archived

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

loonatic

Abstract Graphics Interface

Recommended Posts

I''m doin'' a little 2D Engine in C++. It should be very flexible so i''m using Abstract Interfaces and stuff all the time. Currently I''m thinking of a Graphics interface. As the Graphics will be in DirectX and Windows first but I maybe want to port to other API''s and Systems. Here''s my first try:
class IGraphics : public Singleton<IGraphics>
{
private:
	int		m_iResX, m_iResY;

public:
	IGraphics() { };
	virtual ~IGraphics() { };

	virtual bool Init( int resX, int resY, bool fullscreen)=0;
	virtual void Shutdown()=0;
	virtual bool BeginRendering( )=0;
	virtual bool FinishRendering()=0;
}
I''ve got the following Problem: DirectX need the Handle to the App Window for Initialization. As Linux for example doesn''t know about Handles I cannot put it as a parameter in the Interface. Do you have any idea? I thought of maybe adding a void* addData Parameter to the Init function that could hold the handle when using windows. Is this a good idea? I''m a noob to all this interfaces stuff and it gives me headaches over headaches so i hope you can help me

Share this post


Link to post
Share on other sites
Things like initialization are always going to be a bit platform specific. Put the init in the derived class, not as virtual in the base class. Not everything has to be 100% platform independant... it''s just about impossible, and trying will make your code a huge mess.

Your Win32/DX startup code will create the correct object, init it correctly. During Init, or effects setup code you''ll probably want them coded for the specific platform. For example, on PS2 you don''t want shaders, but on PC/XBox you do. Material and effects setup are highly platform specific.

It''s the game code, and the majority of engine code that doesn''t need to know exactly what the underlying platform and API is, and can use a pointer to the base class.

A lot of overall general code will actually go in the base class, like an animation system, and bone hierarchy code, etc. They do the same work, regardless of platform.

Some things that have general overall concepts, but work differently, and will go in the derived class as but with virtual functions in the base. These are things like vertex and index manipulation, changing rendering modes, rendering to a texture, loading and applying textures, timers, etc.

Then, some other things are very specific to an implementation. These have no virtual function in the base class. These are things like init, shaders, etc.

Share this post


Link to post
Share on other sites


typedef enum PLATFORM
{
PLATFORM_WIN32 = 1,
PLATFORM_LINUX = 2,
PLATFORM_MAC = 3
};

// win32 handle id's

#define HANDLE_WIN32_HWND 0
#define HANDLE_WIN32_HINSTANCE 1
#define HANDLE_WIN32_HDC 2

// linux handle id's

#define HANDLE_LINUX_VAR1 0
#define HANDLE_LINUX_VAR2 1
#define HANDLE_LINUX_VAR3 2

// mac handle id's

#define HANDLE_MAC_VAR1 0
#define HANDLE_MAC_VAR2 1
#define HANDLE_MAC_VAR3 2

class IPlatform : public Singleton<IPlatform>
{
public:
IPlatform(PLATFORM p);
virtual ~IPlatform();

PLATFORM GetPlatform();
virtual void *GetHandle(int id);

private:
PLATFORM mPlatform;
};


[edited by - Rocket05 on March 21, 2004 2:48:08 PM]

Share this post


Link to post
Share on other sites
Cool, thx alot!

Namethatnobodyelsetook, i now agree 100%. There will be a part in the engine that is not API/Platform independent (will need some #ifdef WINDOWS stuff or so). This will also stop my headaches thinking of a way to do *everything* platform independent
Allright the only thing i need to do now is keep the quantity of platform dependent code as minimal as possible :D

Share this post


Link to post
Share on other sites