   Writing a Game Engine
  This is kind of a vague question, but I'm not sure about the exact definition of a game engine. So, like, SDL is an API, just for graphics right? (Also, what is the difference between and "engine" and an API?) Then, would an "Engine" be code that used SDL for graphics, but wrapped it in an easy to use package? Because, like Ogre3D uses DirectX or OpenGL for rendering, but it just wraps it up to make it easy to use. I guess my question is, what is the definition of an Engine and an API?   
  This is kind of a weird topic that comes up a lot because 'engine' is a cool word and we misuse it a lot.Graphics engines generally wrap a graphics API consistently so it makes sense; it may add data structures, etc, to make graphics development easier. An example is OGRE.Game engines do the same thing, but for game code; they may add a library of functions (string tokenization, serializers, functors, smart pointers, collision detection) or objects (sprites, physics entities) that will be helpful to build a game.Generally, my engines are constructed as the game goes along, and then I pull out the new code and slap it into my repository of existing code. So I have a rather large 'game engine' that just constantly gets updated, but I never set out to create a new game engine from scratch, just a game which I re-used the code from. You should do the same.   ;  Yea, that's kind of the definition I had in mind. Thanks for clearing that up for me![EDIT] Oh, one more thing that's kind of related. If I have a file with lots of functions that I use regularly, do I just #include that or what? If I just add it to my project in Dev C++, it doesn't work...Or, could I compile them into a DLL or library file?   ;  header files should do it , cause dlls provide an overhead -- that in this case is extremlypointless.in general you should use dlls and libs when you want to obscure the detailsof the implementations from the user of the functionality (if used during programming that is).;Quote:Original post by Code Fusionheader files should do it , cause dlls provide an overhead -- that in this case is extremlypointless.in general you should use dlls and libs when you want to obscure the detailsof the implementations from the user of the functionality (if used during programming that is).Actualy libraries don't add any overhead to my knowlidge, and they should be used to reduce the compile time. [my humble opinion, not a fact]The only real problem with library as far as i know is that it can't inline the functions compiled in, so they need to be placed at the header ... while this is what you do anyway with inline functions, i think that most compilers can inline small functions defined in source files, and not specified as inline, and lib is preventing this.[/my humble opinion, not a fact]   ;  There's no such thing as a humble opinion. (I hate it when people say "my humble opinion")Anyway, dll's do add an overhead. A small one, usually, but it's there. Calling a function in a dll corresponds to calling a function through a function pointer. There's an extra memory access involved, which causes a small overhead. Usually, it's no biggie though..Static libraries though, shouldn't cause an overhead, because they are linked into your app.   ;Quote:Original post by SpoonbenderThere's no such thing as a humble opinion. (I hate it when people say "my humble opinion")Of course there is; Just like you have an arrogant opinion.;  [my not humble opinion based on no facts]To me, an engine is something that is *possible* to create an entire (if simplistic) game out of with no 'code'. It may require scripts, but no code. However, actually programming might help out alot, depending on the engine.[/opinion]Edit: and to let you know, this is by no means what many people think. For all I know, I may be the only one who thinks this.   ;  I've always considered an engine to be anything that defines a structure that it knows how to work with.  For example, our graphics engine defines a mesh structure.  So now we can create and fill out a bunch of mesh objects and pass them off to the renderer.  The renderer knows how to efficiently send the mesh to the graphics driver and ultimately show it on the screen.  The renderer is completely hidden from the user, all they have to do is fill out a mesh object.   