Dark Engine Source Code

massimilianogoi on 22/11/2008 at 05:10

Quote Posted by ZylonBane

That would be infinitely stupid. Architectural complexity does not scale.

Why?

jolynsbass on 22/11/2008 at 05:53

Because they don't build a game engine with any thought about what gamers years from now will be doing with it... Thief 3 was made with no intention of releasing the "Editor", and therefore, there is no need to use "variable" memory allocation when you know for a hard fact that the Xbox will never have more than 64MB of memory... It's so much easier to just set a static limit, and work within that.

Volca on 22/11/2008 at 11:11

Quote Posted by lost_soul

All of these things have been achieved with the Quake source code.

A pity Dark(COM+plain C renderer ported from the DOS times, then rewritten to support hardware rendering as well) doesn't have such a clean code as quake has - I would like to quote some random guy on internet (recalling from memory):

Quote:

Carmack is a portability genius, his sources compile out-of-the-box probably even for microwave ovens...

To port to non-windows platforms, it should be sufficient to write a different renderer, aside the lgd3d (openGL one), and write some code to support the COM infrastructure Dark uses or do a rewrite to remove the COM (but that would be Hard).

Well, we can hope for the code, but in the meantime, I'll continue to do my work on openDarkEngine - just to be sure ;)

lost_soul on 22/11/2008 at 23:53

They could have also taken the modular approach that Epic did with the Unreal engine. The renderer can be swapped out and replaced. This was the case with getting good opengl support into DX/Unreal/Ut.

New Horizon on 23/11/2008 at 03:41

I'm fairly certain that we'll have the doom 3 source code for The Dark Mod, before we ever see The Dark Engine source code come to light...especially since John Carmack has said that the D3 source code will likely be released in 2009.

Volca on 24/11/2008 at 08:57

Quote Posted by lost_soul

I guess this would be possible with Dark Engine games as well, even without the source, but would require some hard work. With source, providing OpenGL renderer should be quite easy. They sure had some way to swap the renderer easily.

*Zaccheus* on 24/11/2008 at 10:36

Quote Posted by Volca

... and write some code to support the COM infrastructure Dark uses ...

Assuming it is simple COM (all interfaces derive from IUnknown) and not Automation (interfaces derive from IDispatch) then implementing the COM infrastructure would be relatively easy.

Volca on 24/11/2008 at 11:02

That's beyond my current shallow knowledge... Maybe Telliamed or Nameless Voice would know more about this :)

I know wine implements COM, but am unsure if the syntax is compatible with the VC's - (http://www.winehq.org/site/docs/winedev-guide/ole) seems it's not....

*Zaccheus* on 25/11/2008 at 11:30

Not sure what you mean by incompatible, the macros may be different but the way in which interfaces are implemented (C++ pure virtual functions) looks identical to me.

In any case, I was talking about implementing the simple COM support functions like (http://msdn.microsoft.com/en-us/library/ms686615(VS.85).aspx) CoCreateInstance. I know how to do that for any OS as long as it only needs to support objects with interfaces derived from IUnknown implemented in a DLL as apartment threading.

Volca on 25/11/2008 at 11:36

I meant the way the interfaces are declared in source - if we'd have the source, this would need quite some amount of rewrites to make it portable to at least some platforms :)

I was able to initialize OSM files under linux with some amount of wine code (stolen for testing from mplayer, which stole it from wine to load win32 codecs) so it is possible for x86 linux (it ended here). The syntax needed to declare interfaces was different though (simmilar to that Telliamed used in custom scripts - that I guess were compiled using MinGW).