Quote:Its simple, the engine does not create the window, the renderer does. And the renderer is a common component shared by both the engine and the editor. Why the hell should the editor have to bother with a bulky engine, when it can just use the renderer. Simple enough?
Simple, but totally useless. All my renderer does is render the portion of my scene graph I tell it to. More accurately, it's passed a render list from my sorter. That render list referances nodes that are part of my scene graph. My scene graph is the heart of my engine. After all, the job of my editor is to generate a scene graoph file which I can load back as a level. How can I do that without access to the engine components that actually define my scene graph?
That aside, I want to avoid interaction between my renderer and anythhing outside my 3D engine. Hell, I'm even trying to keep interaction between it and the rest of my 3D engine to a minimum. Any renderer state information I need to set can be set through global settings for my scene graph. That's what they're there for.
Quote:Implement that feature in your engine. Where do you want the problem to be?
Yeah, that could work. Or, I could just give the developer control over that 5 function main loop in the base application, and they can do whatever they want. You realize that this little bit of code that's causing all the problems, namely the window creation code and main loop, is a couple of pages of source, right? If I let them write that themselves, all these problems disappear.
Quote:Its impractical because it forces each game to create its own executable and worry about such irrelevant details as the initialization of the engine (and often alot more than that).
So, what's so much harder about compiling 3 pages of source into an executable? And these "details" are far from irrelivent, or they wouldn't cause so many problems if you couldn't control them. Besides, as I said, this is a few pages of code we're talking about here. A few pages that could well save me from writing an extra few hundred, and in the end, this method would still be better.
Quote:The "engine in executable, game in dynamic library" is also the most logical layout. The engine is a "game operating system". And it works like the stages of a rocket. The engine runs on top of your operating system, taking care of all system specifics. The game runs on top of the engine, and only has to worry about the behavior of the game. The game does not "use" the engine, it runs on top of the engine.
I agree, the 3D engine should call the game content. I'm not talking about the game content though. There should be a third layer of abstraction here at the base. You should have your window creation code and your main loop in the executable. On top of that sits the engine, and on top of the engine sits your game code, be it in scripts or a dll or whatever. That's unimportant here. The issue is the 3D engine and where it starts, and I don't think it should handle window creation, or control the main loop of the application. It makes it too inflexible. As I said before, this application at the base is only going to be a few pages of source, but it's vital if you want the engine to be flexible in any way.
Quote:This approach also has some added benefits. Such as the fact that the engine can load a different game without having to restart. And of course, if you were to have your engine in an executable, and your game in script files... You could run your game on multiple platforms, with no modifications, simply by running it on the engine binary that is specific to your platform.
All of that is still perfectly possible with the way I'm describing, and I don't know where you got the idea I'd have to restart the engine from for this approach. During the game, the base application will be doing little more than:
while(!done){ engine.update(time) SwapBuffers() engine.draw() CheckMessages()}
