I''m currently working on a D3D Engine, and have decided the best starting point should be the DX wrapper... and am wondering what the best process would be? I''ve worked through TWGPG and made a DDraw wrapper, but It was all on a guided tour sorta thing, and I dont have alot of 3D experiance... so I dont know all of the API specific sorta functions that I''ll need to write... so here are my primary questions: 1.) Is there anything I should make sure to include? 2.) What previous methods have you used to design/make your wrappers? 3.) are there any well documented wrappers availible for download? 4.) what sorts of things should I keep in mind when designing the wrapper? thanks in advance for any help... -Lonely

May i suggest something,

If you do a D3D Engine ?

Why bother with a Wrapper... That mean a lot of extra call each time you want to get to Dx8.

So, why not simply plug Dx8 directly into your engine. You just eliminated 50% of function to any Dx8 api related functions.

What they say... ya, KISS (Keep It Short & Sweet).


look at that

class CYour3DEngine
{
public:
Startup ();
Shutdown ();
Render (Viewport, Camera);
Update (float fDeltaTime);

private:
LPDIRECT3D8 m_lpDx8;
LPDIRECT3DDEVICE m_lpDx8Device;

CWorld *m_pYourWorld
};


That''s all... Short & Sweet... No extra call... No extra classes...

When you draw your mesh, pass the Device as arguments : CMesh->Draw (m_lpDx8Device);

Hope that will help you

And remind K.I.S.S At Anytime you think too BIG !!

It''s a good idea to try to put the bulk of your engine in a DLL - this makes it easy to provide bugfixes once you ship, and will help keep compiles shorter during the development cycle. I''m planning on doing this (I''m still early in the design stages) since I want to try to keep bugfix downloads as small as possible.. I''m tired of 10MB patches!

Ugh, back into the UML modeller...

quote:Original post by Scarab

I''m tired of 10MB patches!

Ugh, back into the UML modeller...

It''s usually game data (models, bitmaps, levels, etc) that make up most of that 10MB. My .exe is only about 250k and it includes everything for my game (which has progress quite a ways, and includes a lot of stuff). Sticking things into dlls won''t reduce patch sizes, since you''ll still have to update your resources.

Also, it won''t really decrease your compile time, since any well written code will make sure only those files that changed are re compiled (e.g. don''t have a #include "everything.h" - only include those files you need).

Still, it''s not a bad idea, especially for the core functionality of the game (networking, sound, rendering) because you can then create more than one (for example) rendering .dll which support a multitude of APIs (one for DirectX one for OpenGL).

After using the "separate it all into dlls" method, I found it was a bit of a waste of time for a one-man team. I''m not going to support more than one API for any one subsystem, so why go to the trouble of removing it all to dlls? It doesn''t decrease the reusability of my code, since I have everything in static libraries anyway. In fact, a lot of the utilities I made to support my game link to a number of these static libraries as well.

I suppose what I''m trying to say is that writing core subsections as separate dlls is good if you''re like Epic, and have plenty of man-power to write the extra stuff (it also helps since people can be working on multiple dlls at once), but if you''re a one-man team, then I think it''s time that could be spent else-where. (It also increases your load-times )

War Worlds - A 3D Real-Time Strategy game in development.

quote:Original post by b2funny

May i suggest something,

If you do a D3D Engine ?

Why bother with a Wrapper... That mean a lot of extra call each time you want to get to Dx8.

So, why not simply plug Dx8 directly into your engine. You just eliminated 50% of function to any Dx8 api related functions.

What they say... ya, KISS (Keep It Short & Sweet).


look at that

class CYour3DEngine
{
public:
Startup ();
Shutdown ();
Render (Viewport, Camera);
Update (float fDeltaTime);

private:
LPDIRECT3D8 m_lpDx8;
LPDIRECT3DDEVICE m_lpDx8Device;

CWorld *m_pYourWorld
};


That''s all... Short & Sweet... No extra call... No extra classes...

When you draw your mesh, pass the Device as arguments : CMesh->Draw (m_lpDx8Device);

Hope that will help you

And remind K.I.S.S At Anytime you think too BIG !!

I totally disagree with you!
First dx8 is messy, it so much nicer to work with a wrapper.
You can put additional code for example correct locking of dynamic buffers and such things in the wrapper and most important of all, your engine wont get dependant on a single api. You might want to support dx9, opengl or whatever...
Second, think a bit, compared to the COM function call + all error checking inside the function + the actual work and so on do you really then one extra function call will make that much ?
I you want speed, minimize calls to dx8 and only send large datasets to d3d. I for example use very few calls to d3d.

Ok thanks for all the wonderfull replies...

Still wanting some general design info about the wrapper...

b2funny - by not writing a wrapper, the engine will not be "Short & Sweet", I''ll have to rewrite portions of code everywhere, standards won''t be kept, and the engine code will be API specific (no chance for a port) As I understand it a wrapper is a very usefull thing... not a waste of time

SeanHowe - Vertex & Pixel shaders sound great, and I''ll definately include them... is there anything else? Also, what exactly do you mean by a standard with everything? Like the same sort of functions in each, or what? And yet again, you seem to have done at least something along these lines before... what sort of design process did you use?

Does anybody have any info about writing code to a DLL? I''ll probably have to learn from the MSDN CD''s but It''d be helpfull to have some external info as well.

What sorta layout should I use for the Wrapper?

Should everything have it''s own class?

Should there be an overall class to manage everything?

Should I just use functions and forget the Object Oriented approach?

And the question I think I most want answered:

Are there any online articles, or well documented DX wrappers that you guys know of?

Thanks again,

-Lonely