Jump to content
The Dark Mod Forums

TDM after D3 Source code release


Shadowhide

Recommended Posts

I will feel really bad for those players who are 'borderline' able to play TDM, but for the most part can't, if some of the overhead can't be relieved. I also think the loading times are definitely a huge turn off for a lot of people...even though I personally remember waiting just as long for Thief 2 levels to load on my old crappy system back in 2000. :laugh: All the same, it would be great if they could be cut down considerably. If I remember correctly, someone here said that TDM has to compile sound prop matrix at load time? Oh yes, I remember now. Someone was looking into a file extension they found references to in the SDK, .spr I believe. If we were able to compile those while dmapping, it would make one less thing to compile during map start.

Link to comment
Share on other sites

Ironically, long load times is one of the reasons why mod support will not be provided Battlefield 3. :unsure:

 

I don't mind the load time so much as the inactive map compile time at the end. I have calmed my nerves by enabling the FPS display ( com_showFPS ) but if some other animation took place during compile it would be a less nerve-wracking experience. ^_^

 

The ultimate solution, of course, is to provide a better stream-in solution for textures and ditch the "load the whole map into video ram at once" method. That would be pretty complicated though... but would go hand-in-hand with any LOD, Procedural (SEED) and Culling system work. Of course the competitor ideology is to get some version of Megatexture running for this part.

 

It remains to be seen whether Carmack will remove the primitive Id Tech 4 Megatexture code when Doom 3 is released... Has he mentioned this possibility either way? :unsure:

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

Link to comment
Share on other sites

 

I don't mind the load time so much as the inactive map compile time at the end.

 

 

Some of that could be the sound prop matrix stuff I mentioned above. If that were compiled and packaged with the map as an .spr file, it could likely shave that down a bit since it would just be loaded like .aas and the other files packaged with the map.

Link to comment
Share on other sites

If general 3D texture support is added certain particle effects can be replaced with lower cost 3D texture versions such as this demo:

 

http://www.humus.name/index.php?page=3D&ID=48

 

Well, one can dream :)

 

Especially this one (its from 2010 I believe)

 

 

Waterous!

 

 

Thew new rage seems to be to automatically generate sound from collisions:

 

http://www.cs.cornell.edu/projects/Sound/mc/

 

(That would be highly appropriate for us!)

 

Bendy trees:

 

http://run.usc.edu/substructuring/

 

Here is more new stuff from this year:

 

http://kesen.realtimerendering.com/sig2011.html

 

 

So much cool ideas, so little time...

"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

Link to comment
Share on other sites

Excellent news :)! I was thinking that John Carmack will realese the Doom 3 source after Prey 2 only - say, at QuakeCon 2012 or even at Xmas 2012. It's good to know that this event will happen much earlier than I thought :).

He mentioned during his 80 Q&A at Quakecon that he was a bit surprised Zenimax allowed it before Prey 2 as well. I think said thanks to Zenimax several times during that session about allowing it to happen in general given all the legal liabilities it can potentially open up. Was a cool video.

 

 

 

Link to comment
Share on other sites

I watched John Carmacks hour-and-a-half long talk at QuakeCon 2011. That was a cool video. I just grabbed some popcorn and listened to him talk. It's cool to hear some of the familiar deadline headaches, programming migraines, and small insights into design.

 

Brilliant guy. If I were to go into a programming/engineering career, he'd totally be my hero :).

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

Some of that could be the sound prop matrix stuff I mentioned above. If that were compiled and packaged with the map as an .spr file, it could likely shave that down a bit since it would just be loaded like .aas and the other files packaged with the map.

I'm pretty sure we profiled that and found it wasn't worth the effort. Back when we first started soundprop we were going to compile it to a file, but then found it wasn't worth the effort because traversing the portal tree was pretty fast.

Link to comment
Share on other sites

I'm pretty sure we profiled that and found it wasn't worth the effort. Back when we first started soundprop we were going to compile it to a file, but then found it wasn't worth the effort because traversing the portal tree was pretty fast.

 

If it wasn't too much effort to put it back in, since it seems like it existed at one point, then it probably couldn't hurt to have the file created during dmap. Every little bit helps. :)

Link to comment
Share on other sites

If it wasn't too much effort to put it back in, since it seems like it existed at one point, then it probably couldn't hurt to have the file created during dmap. Every little bit helps. :)

It would take effort, probably ~500 lines of code and a bunch of potential new bugs that could go wrong, all to save 1 second or less is probably not worth it.

Link to comment
Share on other sites

It would take effort, probably ~500 lines of code and a bunch of potential new bugs that could go wrong, all to save 1 second or less is probably not worth it.

 

Do we know with absolute certainty that the ability to create these .spr files isn't in the closed source, and just disabled for the time being? They existed at one point. I'm not talking about recreating it all from scratch, but if the framework still exists and only needed some minor additions to reactivate, then that's what I'm talking about being worth it.

Link to comment
Share on other sites

Do we know with absolute certainty that the ability to create these .spr files isn't in the closed source, and just disabled for the time being? They existed at one point. I'm not talking about recreating it all from scratch, but if the framework still exists and only needed some minor additions to reactivate, then that's what I'm talking about being worth it.

Those saved sound-prop files were never in vanilla Doom3, those were a system I was using very early on, but it turned out to be flawed and not useful. I'm not even sure what you'd save for the current soundprop system, probably just the area/portal tree, but it already exists as a linked list in RAM for the visual stuff; it would actually be slower to parse it from text files and re-create that linked list than it is to traverse and copy the existing one in RAM.

Link to comment
Share on other sites

Those saved sound-prop files were never in vanilla Doom3, those were a system I was using very early on, but it turned out to be flawed and not useful. I'm not even sure what you'd save for the current soundprop system, probably just the area/portal tree, but it already exists as a linked list in RAM for the visual stuff; it would actually be slower to parse it from text files and re-create that linked list than it is to traverse and copy the existing one in RAM.

 

Ahhh, so you made that system. I didn't realize that, nor do I think the person who was trying to get them to work did either. :) We were under the impression they were part of vanilla doom 3.

Link to comment
Share on other sites

Ahhh, so you made that system. I didn't realize that, nor do I think the person who was trying to get them to work did either. :) We were under the impression they were part of vanilla doom 3.

Ah, no. There are .EFX files which handle the player-audible sound settings for EAX. It would be great to make those work with OpenAL once it goes open source so that people can get richer sound environments without needing an EAX card. It would also be great to incorporate an EFX editor in DarkRadiant, I think we can do that without the map compiler source. Although, if you choose to define EFX areas by portal area number instead of idLocation, it requires some foreknowledge about what number a given portal area will get. Most of the time idLocation is fine, it seems like setting different sound properties on different area numbers would only be useful if you had like a tiny one-room bathroom that you wanted high reverb in and didn't want to bother with idLocation separators on the portals.

Link to comment
Share on other sites

I think the foreknowledge problem with the portal-number (considering you can still get it after the fact from the compiled file) wasn't as bad as the fact every time you dmap you can get a different number, so the post-hoc number is only reliable if you're done with the architecture, or maybe small changes that don't change the portal numbering. But maybe that's what you meant by a "foreknowledge" problem. I guess your point was if we had the compiler source then DR could know what they number is going to be each time, but without it, obviously it can't.

 

I guess the *least* we could do is get DR to know what the *last* portal number was, and set that as long as there's no number changing dmapping. Then if there is a number-changing dmap, DR clears the setting and the mapper would have to reset it. That would probably be annoying as hell for mappers, but it might be better to have an annoying option available than no option at all... But if you do have it, maybe bury it, lol, so then only a mapper that knows it's there & respects its reason for being annoying can use it. That might be a respectable compromise.

 

Re: setting individual locations for just one room (to have its own EAX), you can do that and keep the ambient playing (if it's set to the same ambient, it just keeps playing without pause)... But it's worth noting there are still situations where a new location might have effects, not many, but like if you wanted to run a script on the old one, etc.

 

Edit: Sorry I'm thinking this out as I go. If DR can get the number from the compiled file, of course the compiled file has the number attached to the portal region. Basically DR could get away with it if every time you opened DR, it searched the compiled file for that portal location and got the number from there. So even if the dmap did later change the number, the next time you opened up DR it could reset it to the new number. Or what you might have is a button like "Update EAX locations", and that would prompt DR to find the compiled file (maybe the mapper has to browse for it)... Then when a mapper complains, "my EAX is gone", you can answer, "After you dmap you need to restart DR or push the 'Update EAX Location' button; and the locations will recalibrate". Still annoying, but more in the realm of tolerable.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

Meanwhile, CryEngine 3.3 becomes available for non-commercial use. Anyone?

 

No Linux or Mac users:

 

Supported operating Systems: Windows XP SP2, Windows Vista SP1 or SP2, Windows 7

 

Dead in the water.

 

Unigine might be a candidate, as it works on Linux and Mac:

 

http://unigine.com/products/heaven/download/

 

However, porting our AI over to it, and the lightgem and the buttload of other features we have is a non-trivial task. And given that we haven't even managed to do some basic things (like adding subtitle support) which require at least 10x less work, I think the idea that we switch to the engine is aking to magical fairies appearing and giving everyone around here a pink pony.

 

Right now we have about 1 developer working on TDM. In words: One. There are two other people who still do work, namely grayman (he is on a break until end of August) and greebo (on a longer break, works mostly on DR). These two people do work a lot, too, but even with all three of us, there is no way we could even attempt an engine switch.

 

It will be already a challange to incorporate the new D3 source code into our source code and make a TDM version that works without Doom3.exe - switching engines is like starting all over again. Forget it. (I think I am starting to repeat myself here :)

"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

Link to comment
Share on other sites

It's objectively interesting that CryEngine 3 was opened for non-commercial use, since it's associated with pretty environments and I'm sure some indie teams will do great things with it. TDM just won't be one of them. ;)

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

It's objectively interesting that CryEngine 3 was opened for non-commercial use, since it's associated with pretty environments and I'm sure some indie teams will do great things with it. TDM just won't be one of them. ;)

 

i dont think so

 

modern gamers are lazy

 

how much UDK projects was released ?

 

another example is Id-Tech's forks . 50 or so forks for quake 1.no less.15 or so forks for Quake 2.And Quake 3 forks could be counted by the fingers : xReal,ioQuake3...is that all ? I dont think there will be more then 1 or 2 forks for Tech4 .and probably one of them will be made by TDM team

 

modern gaymers generation cant handle that.

 

No Linux or Mac users

 

yeah,but linux and mac fairly sucks

Edited by Shadowhide

Proceed with caution!

Link to comment
Share on other sites

  • 4 weeks later...

If the renderer for Doom 3 would be rewritten to DX this would be awesome for me. Best woul dbe if it is possible to keep it as a DLL so you can switch it, for Linux to OpenGL and on Windows to DX. Reason is, that nvidia supports their 3D shutter lenses only for DirectX and not OpenGL, so it's really sad that TDM can not be run in 3D.

Gerhard

Link to comment
Share on other sites

Looking at the 3D Vision site I can see that there is a list of 3D Ready games. This implies that support is a bit more involved than just switching to a DirectX rendering path. It seems TDM would have to handle locking the framerate and alternately rendering left and right images. If that's the case you might as well scratch maintaining two separate render paths and just figure out how to send a timing signal to the glasses. A quick google search suggests that enough information is available.

Link to comment
Share on other sites

The porting Doom 3 from OpenGL to Direct3D is a helluva job, IMO. Who from the Doom 3 community can perform this task? How much time can it take? Which exactly Direct3D version will be the target: D3D9.0 + SM2.x, D3D9.0 + SM3.0, D3D10.0 + SM4.0, D3D10.1 + SM4.1, D3D11.0 + SM5.0, D3D11.1 + SM5.1? BTW, has anyone ever ported Quake 3 to Direct3D?

Edited by MoroseTroll
Link to comment
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.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...