Archived

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

Lonely

DX 8 API wrapper

Recommended Posts

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

Share this post


Link to post
Share on other sites
If you''re planning to make any sortof advanced 3D game with this wrapper, included vertex shaders and pixel shaders as main parts of your architecture from the very start. By the time the game is done if you start right now, it''ll be acceptable at least, although not necessarily advisable, to release a game that requires them. It''ll make life easier if you work them in there as integral parts of your pipeline from the start.

-------------------------------
NeXe: NeHe DirectX-style.

Follow the orange rabbit.

Share this post


Link to post
Share on other sites
... also, keep a standard for how things will work and keep with it. Make sure all of the objects function in a similar fashion, or everything will head to hell pretty quickly. I speak from personal experience on all of this, by the way.

Share this post


Link to post
Share on other sites
... Since nobody else seems to be responding, I''ll keep it up with some more info. You''ll want the main bulk of the work to go into the front end so that the internal code can be updated without making you need to rewrite anything that uses it. One way to go about this is to put the wrapper in a different library (Dynamic or static, I have an article I wrote that should be on gamedev.net soon that talks about using classes with dynamically linkedl libraries), and then do all the actual engine code in there and just link it. That pretty much forces you to separate how you use it and how it''s implemented, and provides an easy way to update at the same time.

-------------------------------
NeXe: NeHe DirectX-style.

Follow the orange rabbit.

Share this post


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

Share this post


Link to post
Share on other sites
A reason to do a wrapper and then an engine on top of it is like I said above. The engine will always function the same way even if the internal code of the wrapper changes if all it does is call those wrapper functions.

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites