A general help question about engines.... Ok i've been using and programming in direct x for quite a while, i know how to do quite a lot of things, through setting up a window, displaying fonts, loading models to (basic) shaders. I'm currently thinking about starting my own engine project in my spare time. However i've got a couple of queries im a bit unsure about.... first off Would i be better to code seperate sections and test sections individually then combine them. For instance code some resource or texture manager seperate from the rest of the engine and then include it after its been tested and works, and do this approach for the whole engine. Or would it be better to include everything and work individual elements of the whole system. Secondly baring in mind that i've never coded an engine before, would it be better for me to start with basic support or code the whole engine thinking about the future. I might want to include terrain rendering and shaders in the engine eventually but at the moment have no idea how i might do that. Thirdly i have a basic renderer which obviously sets up a window and can draw basic 3D or 2D geometry. The renderer needs only Five lines of code to set up. Is it generally a good idea to keep code as easy for the user to use as possible or to make it easier for yourself to program. I figured that making it very easy for the user would take away some of the functions, or limit the usability of the engine. Is there any decent tutorials on how to modify a renderer to include it with an engine. Just a couple of questions that i've been thinking about whilst "brainstorming" my next project there is more but i can hopefully find the answer to those questions on my own >.> Cheers Fallout.

I was in a similar position to you when I started working on a graphics engine a year ago. Basically, for people like you and I who are learning, you can't write an entire engine that can account for anything. No matter how well you plan, you'll learn something later or come up with a better design, and that will disrupt your plan.

As for coding parts of your engine separately, that entirely depends on the part. My resource manager class (ResourcePool actually) is used by, but defined separately from the graphics engine. This is because that code can be used elsewhere as well, like for audio resources.

Just start by writing a simple engine, and keep it nice and modular. Then go through successive rewrites as you learn new things. Keeping your code modular will make the rewrites much less painfull, as you can quickly reuse existing code.

I like the idea of an engine being simple to start up (mine does that too), but make sure to provide some means for the user to provide extra parameters. I do it the way Ogre3D does it: I have an overload of the function that initialises everything that accepts an array of data. That array can contain anything, be it multisample settings, a handle to a user created window, or whatever.

But regardless, be aware that writing an engine is NOT easy and takes a very long time. But it's very gratifying and educational as well.

I coded a small simple engine a while back, it had a seperate font managers, model manager, input manager and sprite manager but they all ran independantly of each other, using string references to various aspects which was very bad for accessing individual models etc. It also ran very slowly and had no optimisation or proper scene managment at all, although it did allow the user to produce this output with very minimal amounts of code. I think it might be a good idea to try to re code this engine with some optimisations in place and maybe look at some kind of scene managment. Well it would definetly help my learning at least. I guess even little changes such as making a couple of factory functions and allowing the engine to run in dx or opengl would be interesting to try and implement too.

My engine uses opengl, directx, and xna, and I love that. But be warned: it really, really, really, increases your workload. I can't stress that enough.

You have to abstract them away behind a common api, and make sure that the three implementations behave the same. That's a heck of a lot of work. As gratifying as platform independence is, there's still the odd time I've thought about reverting to a single api. Simply because it'd be so much less work.

i think i'll give it a shot and see how the progress goes, thing is its a third year dissertation project for next year so im going to try and make it as impressive as possible in a year space, is it possible to allow custom shaders, i was thinking about it and the only way i thought it would be possible would be to have general shaders for something like Lights and just allow them to be editable, i not 100% sure this would work but there must be a way to allow it??

The way I'm going is to allow the user to define shaders in material scripts. The scripts describe things like colors, texture blending states, etc, but also allow the use to provide pixel and vertex shaders. They work pretty much like direct3d fx files. The script also informs the engine of what the shader is capable of, be it lighting, vertex blending, or whatever.

If the shader has a specific capability like that, it must conform to some requirements imposed by the engine. Mainly that the shader constants used must have certain names so the engine can find them and set them for the user.

The one major hurdle is the large differences between Direct3D and OpenGL shaders. Even if you use cg, the shader isn't guaranteed to work for both unless you carefully plan for it. And besides, I get the feeling cg is falling behind the times.

There's also fundamental differences like the fact that direct3d allows you to provide multiple sets of vertex positions, while in opengl you have to hijack one of the texture coordinate sets. You need to account for this in your shaders.

I wrestled with this for a while, and finally decided the only sensible solution was to require the user to supply separate shaders for direct3d and opengl. The engine looks through the material for a technique that uses a shader language and profile supported by the current rendering system. The user can also provide a technique that doesn't use a shader, to fall back on in case a supported shader isn't found.

well you've been very helpful gharen2 i'll be back if anything else crops up but everything seems to be going somethely just got a quick renderer together, allowing initialisation of both openGL and DX shame i know nothing about openGL surely cant be that different from DX, the next step i guess.

Fallout

Good to hear.

I forgot to mention, another thing you'll have to account for is that opengl uses right handed matrices, while direct3d uses left handed. So you'll have to learn to convert between them. I recommend having your engine use right handed ones. They're the more mathematically standard, and most online resources use them. Then when supplying to matrix to direct3d you'll have to convert it to left handed.

I'd love to know why microsoft chose to use left handed matrices.