Jump to content


Photo

TDM after D3 Source code release


  • Please log in to reply
198 replies to this topic

#1 Shadowhide

Shadowhide

    Advanced Member

  • Member
  • PipPipPip
  • 1282 posts

Posted 11 July 2011 - 05:13 PM

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, 11 July 2011 - 05:27 PM.

Proceed with caution!

#2 demagogue

demagogue

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 5502 posts

Posted 11 July 2011 - 05:46 PM

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.
Posted Image

#3 New Horizon

New Horizon

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 13902 posts

Posted 11 July 2011 - 05:51 PM

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. :)

#4 jdude

jdude

    Uber member

  • Development Role
  • PipPipPipPip
  • 4001 posts

Posted 11 July 2011 - 05:58 PM

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.

#5 Shadowhide

Shadowhide

    Advanced Member

  • Member
  • PipPipPip
  • 1282 posts

Posted 11 July 2011 - 06:02 PM

thanks for replies

good to know !

i'm happy that TDM will still a D3 mod,dont know why,but i do




Proceed with caution!

#6 jaxa

jaxa

    Advanced Member

  • Member
  • PipPipPip
  • 1420 posts

Posted 11 July 2011 - 06:06 PM

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

#7 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 12 July 2011 - 12:31 AM

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


http://wiki.thedarkm...ch4_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

#8 _Atti_

_Atti_

    Advanced Member

  • Member
  • PipPipPip
  • 1044 posts

Posted 12 July 2011 - 05:19 AM

Will in-editor re-scale of models be possible?

#9 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1722 posts

Posted 12 July 2011 - 07:31 AM

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:






#10 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12924 posts

Posted 12 July 2011 - 10:18 AM

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.

#11 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37756 posts

Posted 12 July 2011 - 10:34 AM

I'd put physics improvements on my wish list. Specifically the problem with impulses between movables.
TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#12 lost_soul

lost_soul

    Advanced Member

  • Member
  • PipPipPip
  • 1456 posts

Posted 12 July 2011 - 11:46 AM

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.


#13 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 12 July 2011 - 12:01 PM

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

#14 Mortem Desino

Mortem Desino

    Uber member

  • Development Role
  • PipPipPipPip
  • 2443 posts

Posted 12 July 2011 - 12:14 PM

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

#15 New Horizon

New Horizon

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 13902 posts

Posted 12 July 2011 - 12:43 PM

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.

#16 jdude

jdude

    Uber member

  • Development Role
  • PipPipPipPip
  • 4001 posts

Posted 12 July 2011 - 02:40 PM

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.

#17 demagogue

demagogue

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 5502 posts

Posted 13 July 2011 - 12:58 PM

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.
Posted Image

#18 muncadunc

muncadunc

    Newbie

  • Member
  • Pip
  • 7 posts

Posted 13 July 2011 - 01:38 PM

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.

#19 Mortem Desino

Mortem Desino

    Uber member

  • Development Role
  • PipPipPipPip
  • 2443 posts

Posted 13 July 2011 - 01:43 PM

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

#20 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 13 July 2011 - 03:32 PM

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

#21 New Horizon

New Horizon

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 13902 posts

Posted 13 July 2011 - 03:42 PM

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?

#22 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 9507 posts

Posted 13 July 2011 - 03:54 PM

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, 13 July 2011 - 03:56 PM.

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

http://www.indiedb.c...ds/the-dark-mod

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

#23 New Horizon

New Horizon

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 13902 posts

Posted 13 July 2011 - 03:58 PM

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.

#24 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 13 July 2011 - 04:15 PM

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

#25 Tels

Tels

    Mod hero

  • Member
  • PipPipPipPipPip
  • 15024 posts

Posted 13 July 2011 - 04:22 PM

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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users