I'd like to discuss a creation of the core engine for our future projects. I chose this forum not accidentally, I hope that professionals (especially from Microsoft) will help me in my questions.
First, I'll say a few words about the core engine. It provides system, input, video and audio core techniques. Also, it has a pluggable system. The main COMponent 'MWCore' (from 'MWCore.dll' server) is only the bridge which connects the parts listed above together with the game. So, it's something like an abstraction layer between the operating system and the game engine.
There are following main interfaces:
- IMWSystem - window handling, timing & synchronization, configuring & profiling, data packing and so on;
- IMWInput - input handling, action mapping;
- IMWVideo - rendering, scene & resource managing;
- IMWAudio - playing music & sound effects;
- IMWCoreHandler - core event handling (game, game engine, gui engine or something else).
'MWCore' at the initialization requires the listed items to be set. For example, it may deal with 'MWVideoD3D9.dll' and 'MWVideoD3D10.dll' through the same interface 'IMWVideo'. But the problem is to write such interface taking into account the great differences of these two APIs. And this problem will be the problem of the thread.
And if it's permissible, I'll write my questions here...
The COM-based CORE engine (a lot of questions)
Moien
Well, it doesn't really matter what you call it. Code like this should be installed side-by-side with the game that uses it, for the reasons I mentioned earlier.
mtsman
There's only one question you need to ask yourself.
Are you interested in just building middleware, or do you want an actual game
dlmac
I don't think this a good design for a game engine
I'm speaking about the CORE engine. As for a game engine You are quite right. The CORE engine is planned to be some abstraction layer between the OS & DirectX and the future GAME engine.
Tyler Whitney - MSFT
The used language has no impact on the operation system you need. A C# engine will run on XP and Vista. I only recommend C# because most people I know prefers C# over C++ in a full managed environment.
Daniel Kolman
There's probably no reason for you to implement these functions. Just have your DLL export a function like CreateMWCoreEngine and have that return an IMWCoreEngine pointer through which you can create all the other objects. It's the way Direct3D works, and it's much simpler then building full scale COM server.
kkam
Yes, it's easier. But my core engine will be fully separated from the game and won't be in eny system directory (as Direct3D is). The game doesn't know where the core engine DLLs are located, but it calls CoCreateInstance() function to find them through the registry. That's the reason to use COM server.
Cola_03
I done some testing with com-based engine, and i notices it was slower as a normal win32 with dllexport.
So i think it might be better not to use com. If using win32 exported classes, your engine will still be scalable, u can inherit the classes from your existing engine and extend them, then link your game to the new dll containing the extended classes.
The original dll's will still be required, except if u put all extendable classes into your core dll.
I prefer win32 dll's with exported classes and put the engine dll's at same place with the game executable. This way, games using different versions of the engine can't conflict with eachother.
Only advantage i found using com:
- Creating subsystems from inside the core dll by passing a guid
- Putting your mainloop and game logic code in the core dll
- Working with event's instead of callbacks
jbmeeh
Vista will support the whole COM system you know from Windows XP.
The rules how to build a DLL that contains COM objects are unchanged.
You can use Win32 or WinForms. Windows XP and Windows Vista support both ways.
Yes you can create a Core engine with managed C++. But if you would build the whole engine as managed system maybe C# will a better language.
Amarelo_Mrt
I don't think this a good design for a game engine. Instead each game should ship side-by-side with a specific version of your engine that they've been built and tested with. Otherwise it's going to be a recipe for disaster. You're stuck a fixed interface to your engine, and even minor bugs fixes will risk breaking any game that uses it.
mkamoski
So, my first general questions:
miguelangel
But if you would build the whole engine as managed system maybe C# will a better language.
No, I just want my engine to run under WinXP & WinVista well. So, If the Vista WinAPI has some additional functionality, but the base of this API is the same that WinXP has... If it's true, I'll use WinAPI and unmanaged C++.
Thanks.