Possible? Usefull?

Ok, this may be the wrong forum for this, so please dont burn me for it.

I have been thinking lately about a project, and I wanted all of your opinions on it. I want to create a “game” style engine, but one that is EXTREAMLY flexable. Basicaly, the entire “engine” would consist of DLLs. Let me expand on that a bit. Say I have an object to be loaded into the “game”, the object has a configuration file that tells me which DLL is used to load the object, as well as which DLL should be used to render teh object etc etc. This method allows me to release an engine, that could be updated by ANYONE with NO knowledge of teh actual internals of teh engine. If they wish to add a rendering feature, they can use an existing DLL to load into an internal format, that they then can then pass to there own RENDERING DLL. Or create there own rendering format inside of there loading DLL, and there own rendering DLL.
I think this system would allow, a GREAT deal of flexiablity, as long as teh foundation was set correctly. Meaning, timing/OS calls/etc would have to be handled by the engine itself, basicaly any of the technologies that dont change much, but are crucial to the ones that do.

What do you all think?

That dll stuff is crappy to be interfaced by “modders” imho.
I find there is a lack of a good 3d engine framework, not building on dlls or so, might be, but being cross-platform and giving the possibilities to quickly test and debug stuff as well as implementing an engine on top of it. We’re currently doing research on that topic and will produce a result in 5 years…

I think a problem is that OpenGL is not object oriented but procedural and a state engine. A plugin/dll which should load or render an object has to assure that every OpenGL state variable is in the right state for the object to load/render it correctly. So there has to be one certain OpenGL state that is granted before and after the execution of any module of the engine, so that any dll can be sure of OpenGL set to a ceratin state, and has to set OpenGL to this state after executing. This is very insecure and could cause a lot of unneccessary state setting calls, and the greatest problem might be that there are a lot of OpenGL states that do not even exist at the moment. Your DLLs can certainly not take care of OpenGL states that do not exist at the time they are written. So the engine framework has to take care of the state settings, which means that it has to be updated for any new state variable which is introduced into OpenGL, which could be very frequently (i.e, together with every new extension that is introduced), and a lot of unneccessary state setting will occur, and all this still will not grant any application to look the way it is intendend.

dabeav,

if I understand your question correctly, you can easily achive this using c++ interfaces. For example:

// This is part of the engine
class RenderDevice {
virtual void init() = 0;
virtual void shutdow() = 0;

};

// This class is in some mygl.dll
class OpenGLRenderDevice : public RenderDevice {
// now implement the pure functions here
};

// This class is in some mydx.dll
class DirectXRenderDevice : public RenderDevice {
// now implement the pure functions here
};

and so on…

Since all the details of the implementation are hidden from the engine, there’s nothing to worry about. The only thing that really matters is the interface. This kind of framework can make the various components in your engine “plug and play”, so to speak. This is a common practice in modern game engines.

That’s exactly what I do, though I’m thinking of going even a step further. I’m thinking of creating an even higher-level interface to the rendering device somewhat inspired by RenderMonkey. I’ll feed meshes, shaders (including textures), render passes, and other requirements for the object and tell the render device to simply draw it. This way, once the engine is completed, content is very simple to implement. The result is a much more complex render device, but that’s a small price to pay for faster and easier content implementation.

Gameplay will be coded in a scripting language I’m starting to try to design. This way there’s no arguing with DLLs.

EDIT: Individual components – such as the render device, the utility library, and other items – will be separated into their own DLLs so that they can be easily swapped with different versions without worrying about recompiling the entire solution, but that’s probably as far as I’ll go with them.

Ostsol,

sounds like a very cool plan. :slight_smile: I do something very similar. It’s just an abstract “Renderer”, and it drives the whole shabang. You just can’t beat a good interface with a stick.

edit:

God speed on the game scripting endeavour. I just battled that demon myself, and I haven’t been right since.

Ok, first off, I know DLLs are cross platform. I am saying DLL, but what I mean is a “conditional” compile situation, so for microsoft they will be DLLs, for linux then will be SOs, etc. Making it very cross platform, depending on the situation. Well only if the moders take the time to write both (but most of the code could be shared between one and the other, so it shouldnt be over bearing).

The one problem I do see from my design was brought up earlier, the fact that opengl is a state system. This could be a problem, unless I have a defaults list, which is published for the moders to use. Meaning, I tell them what the states are before I send there DLLs a call, and expect them to change only the states they change back. This obviously has some flaws, like “new” extensions that I havent hard coded (but in that case the list will simply be updated to state the Opengl Default for that extension), and the fact that the moders may NOT return there seats to the original upright possition. But if I create a “code verification system” in which I or someone else double checks there code before sumbitting, I think I can keep that to a minimum.

The other problem I see, is a modder attempting to write using a “cool” new extension, only to have peoples PCs unable to use it. So I would also ask them to create a “default” render mode, in which they only render in like a base mode, that all PCs can default to.

I know that this wont be the “fastest” method to do things, as well as putting ALOT of control to f things up in the hands of the moders, but I think if I did some sort of “check before release” situation, I think it would be good for a VERY extendable engine design?? What do you think?

Nothing against modders, but I would never let the game code touch the graphics, even if I were the one coding the game. I would separate them completely with an interface or a script. In the project I’m working on, nothing but the main game.dll ever sees any native code, the rest is all scripted. If you want mod authors to have access to native graphics code, you’re braver than I. :slight_smile: Keeping things modular and safe will be difficult, if not impossible. Once you introduce dependencies like that in the game, it’ll be hard to get rid of them later on when you want to change things. Thats my experience anyway…

Originally posted by Portal:
God speed on the game scripting endeavour. I just battled that demon myself, and I haven’t been right since.
Fortunately I found a good tutorial on writing a compiler.

http://compilers.iecc.com/

The “Let’s Write a Compiler” tutorial was pretty useful, even though it was written in Pascal in 1988-89. :slight_smile:

What I’m doing is compiling the high-level code down to an assembler-like byte-code and then using a virtual machine to execute it. The VM doesn’t -totally- mimmick a CPU, of course – that’s overkill. It will have some relatively high-level instructions, such as for calling native C++ functions, accessing variables, allocating dynamic memory, and other such things, but logic will be executed on an instruction-by-instruction basis.

This is an OpenGL forum. What you’re discussing is general software engineering and doesn’t even necessarily have anything to do with computer graphics.

– Tom