Dunno if this post is still going or not, but here are my two cents (maybe three):

1. Read, read, read.
2. Implement whatever cool techniques that you learn, so you can see if they are really worthwhile or not.
3. Check out other people''s engines.

That is a pretty short list, but you get the idea. Also, my OpenGL Game Programming tutorials are basically going to guide people through creating an entire engine (without knowing it ), so that should be a pretty decent reference once it gets farther along.

------------------------------
Trent (ShiningKnight)
E-mail me
ShiningKnight Games (I had to make one up, to fit in with the rest of you )
Project: Writing tutorials and code for my OpenGL Game Programming series
OpenGL Game Programming Tutorials

Sure thing freyr :-)

The source will be open source when we produce some more stable code.
They are right, keep reading, you can never learn too much.

You can contact me if you need my help

From what people tell me, the book ''OpenGL game Programming'' teaches you all about OGL and then walks you thru building an FPS engine.

I am probably going to pick this book up soon.

I have the same question as freyr. I have been learing alot lately and I just want to find out how to put all the pieces together to make an engine and how an engine works.

Thanks,

Eastwood

Here goes...
I''ve been reading up on BSP trees and Portal engines. As I gather it BSP trees are good for implementing no overdraw, and that they work well for static environments, like in Doom. What happens when you have a dynamic environment like Quake. Since the BSP tree is generated beforehand, is it of any use in rendering moving 3D objects (e.g platforms or models)? What''s the alternative?
If I understand portals right then they are used to minimize the amount of non-visible polygons drawn. What happens if I have a dynamic portal? (e.g. a moving window) How about if I want to allow the players to be able to destroy walls? Is it possible to create new portals on the fly?
I know I''m probably jumping way ahead of myself but I find that the more completely I understand the limitations of something the easier it is for me to use it.
Thanks!

Actually the levels in DOOM where every bit as 'dynamic' as in Quake. They had moving parts, like doors and elevators (much as in Quake). In Quake the static parts of the world are stored in a big BSP tree and all moving parts (elevators and such) are stored in small separate BSP trees that are merged with the big one in real time. Enemies and such are not stored in BSP trees at all (simple triangle lists I think).

As far as I recall BSP trees generally generate lots of overdraw while portals (can be made to) generate zero overdraw.

Also BSP trees can be used for alot of things other than hidden surface rejection and rendering; such as collision detection.

Edited by - Dactylos on June 11, 2001 10:47:10 AM

it''s going to be alot easier to make an engine for a game than it is to build an engine for an engine''s sake...

my only advice, spend as much time thinking about, researching and documenting the exact feature list and logistics of your application as you do coding, testing and debugging it.

do this FIRST. don''t just dive in and start writing code, you''ll walk away with a redo that summer vacation won''t allow.


good luck, have fun,

-anon