API or non-API independent
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.
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
MindEngine Development | E-Commerce Business Architecture
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:
[edited by - haro on May 28, 2004 4:14:46 PM]
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]
Author
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.
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
James
Author
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
and then
Is it possible on Win32 platform? And what about UNIX and Mac Os?
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?
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement