journey starts...
Author
Hi all,
Could anyone guide me into "engine design" - not based on DX or openGL - those should just be a wrap on the engine.
I found many books but all of them are pointing in using the DX/openGL API not the "general concept".
I'm looking for any guide/info on how to create something similar to OGRE3D; Core components.
Better yet, anyone knows of a book that would explain the "3DEngine Pipline"?
Can be just a theory and pseudo-code - fine by me
I would say that 3D Game Engine Design(2nd Edition) by David H. Eberly is a good book for you. As you asked for the explanation of concepts and pseudocode this book seems to suit you well as it is really theoretic in nature
Hi,
I knew a guy called Zdunek once;)
I have an ebook "3d game engine design" by David Eberly but to tell the truth I have only read 2 chapters of it. It all depends but I would recommend not to get too deep into designing architecture at the beginning but adding more features incrementally. And yes, download and take a look at Ogre, Irrlicht or any other engine.
I knew a guy called Zdunek once;)
I have an ebook "3d game engine design" by David Eberly but to tell the truth I have only read 2 chapters of it. It all depends but I would recommend not to get too deep into designing architecture at the beginning but adding more features incrementally. And yes, download and take a look at Ogre, Irrlicht or any other engine.
To properly abstract the rendering api from your game engine read up on interfaces and plugin architectures. I once wrote an article that incidentally uses this very scenario in its example code:
Building a Better Plugin Architecture
Game engines can be built and designed in so many ways that it's hard to give any guide on how to approach this topic. The book 3D Game Engine Design by David Eberly is, afaik, the only book trying to teach this. I own it and I think it's a good read :)
If you accept a personal recommendation, get acquainted with an existing engine (like the Ogre engine) first. Using it for a small project of your own will give you more insight into the workings of modern engines than any number of articles and tutorials can.
-Markus-
EDIT: Damn, ninja'd two times while I was writing this :)
Building a Better Plugin Architecture
Game engines can be built and designed in so many ways that it's hard to give any guide on how to approach this topic. The book 3D Game Engine Design by David Eberly is, afaik, the only book trying to teach this. I own it and I think it's a good read :)
If you accept a personal recommendation, get acquainted with an existing engine (like the Ogre engine) first. Using it for a small project of your own will give you more insight into the workings of modern engines than any number of articles and tutorials can.
-Markus-
EDIT: Damn, ninja'd two times while I was writing this :)
Author
thx, the book has been ordered :)
btw, as i have heard a lot of discussions, should the STL or BOOST be used in engine programming or should i use my own containers?
I was avoinding them in many applications as they were not too complicated and i tried to stay in plain C, but from what i can see so far, there is a lot to be handled in an engine...
and just to keep to my motivation going - is it really that hard to write an engine? :)
btw, as i have heard a lot of discussions, should the STL or BOOST be used in engine programming or should i use my own containers?
I was avoinding them in many applications as they were not too complicated and i tried to stay in plain C, but from what i can see so far, there is a lot to be handled in an engine...
and just to keep to my motivation going - is it really that hard to write an engine? :)
Quote:Original post by zdunek
thx, the book has been ordered :)
btw, as i have heard a lot of discussions, should the STL or BOOST be used in engine programming or should i use my own containers?
I was avoinding them in many applications as they were not too complicated and i tried to stay in plain C, but from what i can see so far, there is a lot to be handled in an engine...
and just to keep to my motivation going - is it really that hard to write an engine? :)
Using plain C to create an engine might be a valid option. This would not be my choice (because, by itself, an engine is not valuable; so you'd better spend less time developing it, and more time developing your game - and this is a typical case where more high level languages like C++ can help. To be honest, I think you should not even build your own engine - there are many free alternatives that are going to be better than what you'll do anyway).
You should use the C++ standard library (the STL is just a tiny part of it) whenever you can. If you prove that the standard library cannot be applied as is to your very specific project, then try to force it to do what you want (there are many ways to change its behavior; for example, memory allocation can be modified to use custom allocators). If this doesn't work, then try to use boost containers and library extensions.
If this still doesn't work, you'll make your own containers.
Best regards,
Quote:
and just to keep to my motivation going - is it really that hard to write an engine? :)
Have you written any games? If not, then it's really impossible for you to write anything that could be considered a serious engine. It's more beneficial write games, not engines, and build your engines by iterative refactoring of common code in your games. Otherwise you're pretty much setting yourself up for failure unless you are very experienced (and if so, wouldn't need to be asking these questions).
That said...
Eberly's books are a good read, but by no means definitive on the subject - there are more correct ways to write engines than you can count. You should also favor using the SC++L if you are writing C++, because its the standard library for the language, and if you aren't going to use it you shouldn't be writing C++. Reinventing the wheel wastes your time, and chances are your implementations will be worse -- you need to do extensive profiling and analysis to determine if the SC++L containers and functions are even a bottleneck in your code (just because they have been in somebody elses does not mean they will be in yours). Boost is excellent as well, and common enough to be almost standard, but you can make an okay argument for avoiding it. Maybe.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement