Archived

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

kulik

API or non-API independent

Recommended Posts

I want to write game engine. I am thinking if API independency is necessary. It could be very messy. And probably slower because of proc pointers. What would you suggest? I have a lot of experience with OpenGL, less with DirectX.

Share this post


Link to post
Share on other sites
You have to ask yourself a few questions - who do you expect to be using this engine? Is it for you to learn things from or will it be a commerical product?

If the first is true, you don''t have to care about API independence. If it''s the latter, then you probably do.

My Manta-X engine is API independent, but at present there''s only a D3D renderer written - there may not ever be a OGL renderer completed. The reason for me doing this is simple, API independence forces you to boil down your public interface to the bare neccessity. This is good practice in OOP design, where the public interface is what is seen by the world - without it I probably would have gotten lazy and ill-defined the interface (much like a few of my internal classes...). It also gives me a well defined and self-contained object that I can use to plug Direct-X rendering into any application with a few (simpler) calls.

Putting it simply, it''s a good way to think, even if you don''t use write separate renderers.

Share this post


Link to post
Share on other sites
do you want to develope for multiple platforms ?
if yes, then go api independant or only openGL
if you only are developing for windows then use either openGL or directX but doing both really isnt gonna do much for you.

so I would just stick to what you know (either openGL or DirectX). However, making API independant code is a good learning experience. I did it once, decided it really wasnt worth all the extra effort and dropped it.

"A soldier is a part of the 1% of the population that keeps the other 99% free" - Lt. Colonel Todd, 1/38th Infantry, Ft. Benning, GA

Share this post


Link to post
Share on other sites
think you''ve answered your own question.
i started doing something like this once, but couldn''t be bothered in the end.
if you now opengl then stick with that, unless you really, really want to learn directx.

is it that you want the game engine to be able to render through either opengl or directx interchangably?

Share this post


Link to post
Share on other sites
It will be game engine. But OGL work good on nVidia cards, slower on ATIs. I want to have it cross-platform. Do you think I have to use drivers or polymorphic/derived classes?? Driver = DLL or SO

Share this post


Link to post
Share on other sites
In a realistic setting (i.e. not benchmarking) I have never noticed a difference between the speeds of opengl and directx - my favourite example being IL-2 Sturmovivk which i think runs better in ogl than directx (and that''s on an ati card).
if, by cross-platform you mean windows/linux/mac os, then i''d go with ogl and forget directx.
i did a game that runs on windows and linux once, the only differnce between the two projects was the app entry point and message handling - all the guts were identical ''cos i used ogl for graphics and openal for sound. Winner''s Dinners!!

Share this post


Link to post
Share on other sites
quote:
Original post by kulik
It will be game engine. But OGL work good on nVidia cards, slower on ATIs.


I doubt the difference is so big as to be a deciding factor. Any slowness will come from your code.

quote:
I want to have it cross-platform.


If you want cross platform go with OpenGL.

quote:
Do you think I have to use drivers or polymorphic/derived classes??


Those two aren''t even comparable. It''s like fishing about architecture.

quote:
Driver = DLL or SO


Er... you''ll be linking with libraries. And you can do what you want with the rest of your code.

Share this post


Link to post
Share on other sites
THX. Do you think its better to load a driver (DLL - WIN32, SO - LINUX) or have all renderers in core library. I thought about some kind of class that would load procs from driver during run-time.
Wouldnt it be slower cause of proc pointers??

Share this post


Link to post
Share on other sites
Any game of any significance will spend ~10% of the time doing API-specific calls, and less than 1% of the code will be API specific.

A DLL-based approach isn''t strictly speaking necessary, since there really are only 2 API''s to consider. You could just have 2 base renderer classes, and decide which one to use during run time.

Share this post


Link to post
Share on other sites

OGL and D3D are both pretty low-level APIs. I would implement something a higher-level API anyhow. Given that you''re doing that, it''s probably not that hard to design it so that it can output to both D3D and OGL.


Share this post


Link to post
Share on other sites
After a while, I just decided to abstract the API from the engine, but not write another implementation (e.g. OpenGL). So now I have an abstracted API, which can be interchanged whenever I want to upgrade my engine''s renderer, but I don''t have to bother with doing the same work over and over again. Honestly in this day and age writing multiple renderer implementations is becoming pointless and a waste of time. If you want it to be cross platform, then save yourself time and just write it in OpenGL, it works on Win32 and *nix.

MindEngine Development | E-Commerce Business Architecture

Share this post


Link to post
Share on other sites
Something to think about is the fact that even games which use cross platform engines are beginning to becoming API dependant regardless. The example I'm speaking of being UT2004. This is from the UT2004 readme file:

quote:

The OpenGL renderer is not officially supported on Windows but could be a good choice on certain hardware / driver combinations as it might trigger fewer bugs in drivers. Unless you are experiencing serious visual flaws there is no reason to change to the OpenGL renderer though. Unlike Unreal Tournament, Unreal Tournament 2004 was designed around D3D and offers the best performance and visual quality with the D3D renderer.

Also please keep in mind that the OpenGL renderer has higher system requirements than the D3D renderer. The OpenGL renderer is known to not work correctly with pre-7.76 ATI drivers.



[edited by - haro on May 28, 2004 4:14:46 PM]

Share this post


Link to post
Share on other sites
Yes. I will do it API independent. But my problem is whether it should be 2 renderer classes or separate DLLs or SOs. Its more flexible to have it in separate files, you can add drivers after you released core. Just my thought. OGRE has also Renderers as plugins in DLL and they are loaded during run-time.

Share this post


Link to post
Share on other sites
Its a non issue really as to whether you use dll''s or not. It is trivial to move the code between a dll and the executable, simply a matter of changing a couple of lines of code and linking the correct files.

James

Share this post


Link to post
Share on other sites
I mentioned run-time DLL linking not start-time.
IE:

lib=LoadLibrary(path);
GetProcAddress(lib,"something");
GetProcAddress(lib,"something2");

Its not so easy as you say :-D You must rewrite layer between core and plugin.

Can I import classes?? Like

class EXPORT CExample
{
public:
void Something();
}


and then


GetProcAddress(lib, "CExample::Something");


Is it possible on Win32 platform? And what about UNIX and Mac Os?

Share this post


Link to post
Share on other sites
quote:
Original post by kulik
Can I import classes?


Nope. But you can import a function that creates a class.

typedef void (*CreateProc)(void);
HANDLE lib = LoadLibrary("...");
CreateProc proc = GetProcAddress(lib, "CreateThingie");
Thingie* thingie = proc();
thingie->doThings();

"Without deviation, progress itself is impossible." -- Frank Zappa

Share this post


Link to post
Share on other sites