Jump to content
The Dark Mod Forums
Sign in to follow this  
Shadowhide

TDM after D3 Source code release

Recommended Posts

hi taffaz... or dudes

 

I'm sure,D3 source code will be released soon (half year or so),so I wonder,what TDM team do with them.

 

Will make TDM separate game ? Or boost D3 (TDM will be boosted too) ? Will TDM stay D3 mod ? if TDM became separate game,all fms released so far will go to the trash can ? (cause mappers use some default D3 entities like "info_player_teleport" or movers,damn even "info_player_start" is default d3 entity ! also we use textures like portal_sky,monster_clip ect that is belongs to D3 too)

 

just curious...

Edited by Shadowhide

Proceed with caution!

Share this post


Link to post
Share on other sites

It's already been talked about in a lot of threads around here. Simple answer is the TDM team probably isn't going to work on making TDM independent, in the foreseeable future anyway (who knows down the road), because it's not a good use of finite resources to remake existing assets when there's so much work to do improving it. But it's more likely an independent team might take on the task of making TDM stand-alone. Then it's just a matter if such a team could get itself motivated, do the work, and see it to completion, which seems unlikely but is anybody's guess. Maybe they can, which would be great if they could. Standalone & Multiplayer both are branch-projects I would love to see.

 

That said, I'm sure there's a ton of things the TDM team does want to do when D3 goes open source, since it opens up so many new systems they can optimize or add new features, like the graphics engine, etc.


20js9wp.jpg

Share this post


Link to post
Share on other sites

The main thrust would probably be to optimize some things that we will gain full access to.

 

Exactly what will happen is anybody's guess. We'll have to wait and see.

 

As for making TDM standalone, I think that will require a separate dedicated team of enthusiasts to pull off. A team who would be willing to put the time in to figure out all the shared assets from D3, create replacements that don't completely change the look of the original work, and then go through the existing maps to replace them. There is absolutely no way the current maps would ever be trashed. Once all the assets were replaced, we would need some type of automated script that could go through and search / replace everything within the maps. I think the core team will be too busy working on other things to dedicate much time to that, but it's certainly possible if enough people are kind enough to help us out. I certainly don't think we would shoot the idea down if people put their spare time where their mouth is. :)

Share this post


Link to post
Share on other sites

I recall there being interest in optimizing lighting and introducing various features such as smooth lighting. As for your question about what assets we could use, I'd assume that every asset no matter how insignificant would need to be replaced.

Share this post


Link to post
Share on other sites

Could there be an "awaiting D3 source" category on the bugtracker roadmap page?

 

http://wiki.thedarkmod.com/index.php?title=IdTech4_Open_Source


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

I think steadily cleaning the code is the most probable answer.

 

The first thing to do will be remove all the dirty hacks from the code. Especially SourceHook hacks :wacko:

 

 

 

 

 

Share this post


Link to post
Share on other sites

I added three items to the Wiki list:

 

* Determine why "no_dups" doesn't always work and correct it. Remove SDK workaround.

* Correct the occasional bad "trace" the engine performs.

* Eliminate as many hard-coded limits as possible.

Share this post


Link to post
Share on other sites

I'd put physics improvements on my wish list. Specifically the problem with impulses between movables.

Share this post


Link to post
Share on other sites

I wonder if the open source version of the engine will have less performance in the renderer because of someone else's imaginary property. Also, I would like to see OpenAL support in the Linux version of Doom 3. It is currently unavailable.


--- War does not decide who is right, war decides who is left.

Share this post


Link to post
Share on other sites

I think steadily cleaning the code is the most probable answer.

 

The first thing to do will be remove all the dirty hacks from the code. Especially SourceHook hacks :wacko:

 

We probably also want to remove the distinction between the game (.exe) and the "mod" (.dll) by merging them. That would remove the problems with the two heaps and memory allocation, and who knows what else problems.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Part of me wonders whether or not the entire physics engine is already included in the DLL. The LCP solvers are already right there.

 

No matter, if someone does rewrite and replace physics, he would likely still need source access.

 

I'd also love to see the memory allocation problem kicked. It's baffling to see doom3.exe tank on my desktop once it reaches 999,999K.


yay seuss crease touss dome in ouss nose tair

Share this post


Link to post
Share on other sites

Part of me wonders whether or not the entire physics engine is already included in the DLL. The LCP solvers are already right there.

 

My understanding was that the physics engine was included.

Share this post


Link to post
Share on other sites

If not, IIRC the Havoc engine is free now and could replace the existing physics engine.

 

 

 

I'd also love to see the memory allocation problem kicked. It's baffling to see doom3.exe tank on my desktop once it reaches 999,999K.

 

YES!

 

Also the source code would possibly enable outside of Doom3 compilers (in the editor maybe) and an accurate lighted view in the editor.

Share this post


Link to post
Share on other sites

Physics, that's the other thing I'd love to see too. But we've talked about it in a number of threads already also. But it just fits with Dark Mod being in the simulation category of immersion, where you're interacting with objects and the world around you like real things & places. I really hope it's in the realm of feasible.


20js9wp.jpg

Share this post


Link to post
Share on other sites

It would be cool if load times could be reduced. Doom 3 doesn't take long to load on my machine, but TDM takes for. ever. to load on my quad-core Intel Core i7.

Share this post


Link to post
Share on other sites

Doom3.exe frontloads almost everything (no idea why id Software did this, other than that it's easy). Games like Crysis frontload some, and then trickle in the rest of the resources as needed. It's not an easy system to make.


yay seuss crease touss dome in ouss nose tair

Share this post


Link to post
Share on other sites

Doom3.exe frontloads almost everything (no idea why id Software did this, other than that it's easy). Games like Crysis frontload some, and then trickle in the rest of the resources as needed. It's not an easy system to make.

 

Even worse is that some things are just loaded because they are there, not because they are referenced. Like .gui files. That means when D3 starts, it loads literally hundreds of GUI files from the D3 packages, and then on top of it the dozends of GUI files from TDM. Only that the former GUI files are never used anywhere...

 

In any event, I guess the original poster meant the level loading times - as the startup time of the menu is long, but not that much longer than D3. Level loading, however, even tho we already improved it, is still in the minute(s) range on slower systems, esp. if you have a slow HD and the PK4 files are not yet cached...


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Even worse is that some things are just loaded because they are there, not because they are referenced. Like .gui files. That means when D3 starts, it loads literally hundreds of GUI files from the D3 packages, and then on top of it the dozends of GUI files from TDM. Only that the former GUI files are never used anywhere...

 

Wow, seriously? What a waste of time and resources huh? There is no way we can stop that from happening?

Share this post


Link to post
Share on other sites

The physics code is in the SDK except for the Collision Model Manager apparently. Without that piece it would likely take a great deal of reverse engineering to utterly replace all the physics code with another vendor's version. Even then it would still be somewhat bound by the Collision Model Manager limitations... So "Awesome physics! ... Shit things still fall through floors at random!" etc...

 

 

Even though it hasn't been too popular I think that extending the unified surface concept with new keyword types might be better than tossing the whole thing. So having a Fur material keyword for Fur Shaders (etc). I especially would look forward to seeing new light keywords so that Cubemap and 3D texture based lights could be used alongside the existing 2D+1D methods. Plus, lights should be able to have multiple and dynamic LightFalloffImage stages instead of just one.

 

Can Doom Script already be supplanted with another scripting language interface? If not, that old AI thread seems to indicate replacing Doom Script with something more universal would be a worthy change. I would take that a step further and request that a simple high-level scripting language also be made available for less advanced mappers in the same vein as the topic of Prefab Speed-building or the Script Library concept (but much more TDM tailored).

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

The collision manager code was accidentally released in the first Prey SDK. I have a copy, and it's still easily found online. It would make reverse engineering far easier.

Share this post


Link to post
Share on other sites

Wow, seriously? What a waste of time and resources huh? There is no way we can stop that from happening?

 

(loading of GUI files)

 

I found this out by accident a few weeks ago when I removed all the D3 strings from the english.lang file and D3 would suddenly complain about missing strings that were never referenced anyway. After a long search I found them referenced in D3 GUI files like mpmain.gui etc.

 

In some cases TDM was lucky because we kept the GUI name (mainmenu.gui f.i.) but in others we replaced the GUI, then renamed it. So D3 loads both the old and our version.

 

In a few other cases (like the dozend so Kbyte GUI files mpmain.gui, hud.gui and intro.gui) I replaced these files with empty versions in TDM. That doesn't stop the loading, but at least it prevents the parsing and the endless spewing of "string xyz not found" messages.

 

I guess this can easily be fixed with D3 open source and a stand-alone TDM, but right now it would be a hassle to add the who-knows-how-many empty files we need (the D3 PK4 has dozends of subdirectories with gui files...)


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

The collision manager code was accidentally released in the first Prey SDK. I have a copy, and it's still easily found online. It would make reverse engineering far easier.

 

The problem with replacing the physics engine is that it is a HUGE task because you either:

 

* need to write an interface for the new engine that is compatible to the old, so the old code can still use the same calls. Plus you also need to stuff the data that is loaded at level loading time somehow into the new engine. However, that interface might not suited and thus be slower.

* OR somehow convert all data to the format of the new engine, and then replace all code places to use the new engine which are A LOT places, not just collision detection.

 

Unless we magically gain 10x the developer power (e.g. we are actually more than 3 developers, where at any time, 2 of them are on a break :), I do not see this happen.

 

And in both cases, the D3 game exe will still not know anything about the new engine and happily use its own engine... so it would not really work. So this is truly best left until the engine goes open.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...