I was looking over the source code of the Ngine project a few days ago, and I realized the importance of keeping all API specific stuff (OpenGL, DirectX, etc...) in separate rendering DLL''s and loading them dynamically. I would like to implement this in my own project, but I don''t want to copy the Ngine source code. Anyone know of any good tutorials on this topic? I looked over the Quake II source code as well, but Carmack has everything so tightly integrated (in pure C, ugh!...) that I would much rather take the time to count the hairs on my head (while I still have most of them ) rather than decipher id software''s code... I have a good idea of what needs to be done, and I could probably do it, but I felt I should spare myself all the stress and read up on it. If your gonna do something, might as well do it right... right? Thanks.

It''s true, the Q2 source code is quite cryptic IMO. I mean, it -is- tightly integrated but I think the biggest factor for increasing its complexity and ultimately its readability is the optimisation that had been done to the engine (Namely, but not isolated to, vertex interpolation / model drawing). But I guess the Q2 engine was not designed to be readable it was designed to be functional, flexible and stable.

I would never recommend copying someone elses code. I think the best thing to do would be to find as many open source game engines as you can and study the aspect of the code you are thinking about. I''ve got a small database of around 30 open source game engines and I am quite familiar with the structure of each of them. I am using this knowledge to help me structure my own engine. As for online resources, AFAIK they are few and far between (If you can find the few that must be out there, I never have).

With regards to writing a switchable backend to your game engine, personally IMO I wouldn''t bother. Juggling DX and OGL has little advantage in relation to the extra work it generates in debugging etc. Also it is inevitible that keeping your engine API specific is going to make it easier to optimise and or debug. Saying that, if you want your engine to be portable, a switchable backend can make things clearer for you as a programmer because of the level of abstraction between the engine and the rendering backend.



-------- E y e .Scream Software --------
----------------------------------------
                                  /-\
    http://www.eyescream.cjb.net | * |
                                  \-/
----------------------------------------

quote:

---

Original post by TheGilb
But I guess the Q2 engine was not designed to be readable it was designed to be functional, flexible and stable.

---

Personally I dont think its ever possible to separate those two design goals.



The computer was conceived as a tool to reduce complexity. Some people found this loss of complexity unacceptable, and developed UNIX to amend the situation.

I see what you guys mean. Personally, I don''t mind littering my engine with OpenGL/DirectX calls because I only intend to make this run on Windows (for now). How then do I go about detecting if the user has these API''s installed, and nicely exiting the application (maybe with a log entry) instead of it just crashing if opengl32.dll is missing for example?

quote:

---

Original post by glDino
I see what you guys mean. Personally, I don't mind littering my engine with OpenGL/DirectX calls because I only intend to make this run on Windows (for now). How then do I go about detecting if the user has these API's installed, and nicely exiting the application (maybe with a log entry) instead of it just crashing if opengl32.dll is missing for example?

---

You could load the dll with LoadLibrary(); and then use GetProcAddress(); to get addresses to the OpenGL API functions, but it is alot of work and not very easy or neat. Forgetting to load a function can lead to hours of 'This should work! Why the hell doesn't this work?'. You don't usually write code such as if(glVertex3f)glVertex3f(x,y,z);. Crashing is so much easier.

The only reason I have ever done that is because I couldn't link to the Bass library in Dev-c++, so I loaded the functions from the dll and did it all manually.

Edited by - smart_idiot on March 7, 2002 11:01:05 AM

Yeah, that was actually my first attempt. I noticed the same method being used in Quake II, so I gave it a shot. One of the wgl* calls caused a "memory cannot be read" error.


I''m tempted to switch back to static linking (I hate making decisions... it involves using my brain )