Jump to content
The Dark Mod Forums

Doom3 GPL Source Release has landed


rebb

Recommended Posts

Happy birthday Sparhawk!

 

It seems that the new method pre-loads the shadows unless the player is inside the volume. Not exactly sure what the pre-load means in this context but if i am optimistic this means that only the volume the player is inside of will take the full performance hit... Pessimistic would mean that any time the player is inside any shadow volume the full hit will happen everywhere. Fortunately, even for the worst case, alternative shadow methods exist anyway (such as doing it all on the GPU)...

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

Link to comment
Share on other sites

Just to set the record straight, I didn't find any guards because I had previously ran killmonsters on that save game in the past with the original D3 to check out the map. It wasn't like the guards failed to show up in the open source version of D3, which is what my post kinda sounded like.

 

**updated*

Tested again with a fresh mission load. The guards walk around and patrol just fine, but the game still died a horrible death when I pressed esc to bring up the menu. I had to switch to a virtual terminal to kill it because in Linux you can't alt-tab out of games (dumb!).

 

As for performance, it still ran okay on my GT440 at 1280x1024 with 2xaa/af. We need someone with a real old card like a Geforce 7xxx to try it. I may do this next time I go to my mom's place and report back.

 

... but it is great to see the full vision of this mod come to pass. We now have the content AND the source code to create a stealth game where the only limitation is the abilities of the FM author. The taffer community is no longer stuck with only making maps/script edits to a closed technology! Congratulations and thanks to everyone who has made this happen.

Edited by lost_soul

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

Link to comment
Share on other sites

It's perfectly possible that the open source community will end up putting the depth fail method back in, since (1) software patents aren't universally enforceable and (2) companies don't generally bother suing open source projects for patent infringement because there is no money in it (and a lot of bad PR).

 

It's primarily a legal issue for id software: as I recall the GPL requires the copyright holder to grant a free licence for any patents that they know apply to the software, which obviously id software cannot do because they don't own the patent in question. This will be why their lawyers required the change to be made before the GPL release.

  • Like 2
Link to comment
Share on other sites

It's perfectly possible that the open source community will end up putting the depth fail method back in, since (1) software patents aren't universally enforceable and (2) companies don't generally bother suing open source projects for patent infringement because there is no money in it (and a lot of bad PR).

 

It's primarily a legal issue for id software: as I recall the GPL requires the copyright holder to grant a free licence for any patents that they know apply to the software, which obviously id software cannot do because they don't own the patent in question. This will be why their lawyers required the change to be made before the GPL release.

 

I agree, and we all enjoy this:

 

***********************

// patent-free work around

if ( !external ) {

// "preload" the stencil buffer with the number of volumes

// that get clipped by the near or far clip plane

qglStencilOp( GL_KEEP, tr.stencilDecr, tr.stencilDecr );

GL_Cull( CT_FRONT_SIDED );

RB_DrawShadowElementsWithCounters( tri, numIndexes );

qglStencilOp( GL_KEEP, tr.stencilIncr, tr.stencilIncr );

GL_Cull( CT_BACK_SIDED );

RB_DrawShadowElementsWithCounters( tri, numIndexes );

}

***********************

 

"Patent free work around", ROTFL! ;-)

 

Really cool John! :-D

 

=> from row 1146 on the source:

 

https://github.com/TTimo/doom3.gpl/blob/master/neo/renderer/draw_common.cpp

  • Like 1
Link to comment
Share on other sites

...I had to switch to a virtual terminal to kill it because in Linux you can't alt-tab out of games (dumb!).

Depending on the game, and your linux desktop, there are ways out. Obviously you used a virtual terminal, but there is at least one alternative similar to alt-tab.

With WoW running in Wine, I could press ALT-F2 to bring up KDE's run dialog and type "killall WoW.exe". I don't remember being able to do so with TDM/Doom3 running.... I think ALT-F2 did not respond when I tried.

Another option is to press CTRL-ALT-F3 to change to linux terminal 3, login as your user, and then do either 'killall doom.x86' or do 'pidof doom.x86' to get the pid number followed by 'kill (pid number)'. Then 'exit' to log out and either CTRL-ALT-F7 or CTRL-ALT-F8 to return to X.

Edited by PranQster

System: Mageia Linux Cauldron, aka Mageia 8

Link to comment
Share on other sites

and now someone can implement reverberation/advanced audio effects without requiring proprietary hardware or drivers. The Unreal 1 engine did this to great effect. You could hear sounds bouncing off the mountains in the distance and it was really awesome with headphones on.

  • Like 1

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

Link to comment
Share on other sites

I agree, and we all enjoy this:

 

"Patent free work around", ROTFL! ;-)

 

Really cool John! :-D

 

Yep, as I recall Carmack said the actual work-around was four lines. Four lines of code representing the order in which programmers are legally allowed to call OpenGL functions. How the spineless corporate fellationists can defend this garbage with a straight face is beyond me.

Link to comment
Share on other sites

Four lines of code representing the order in which programmers are legally allowed to call OpenGL functions

:laugh:

Edited by lowenz

Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Link to comment
Share on other sites

I added the links to the discussion page for the Coding in the SDK article.

 

Here ya go:

 

https://github.com/TTimo/doom3.gpl

 

mirror:

 

http://waffles.za.net/tdm/random/idtech4-doom3-source-GPL.zip

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

Will the downloadlink be put into our wiki as well? Woul dbe nice. I'm looking for the source and can't find it.

 

I added the links to the discussion page for the Coding in the SDK article

 

Or to actually checkout the code itself:

 

git clone https://github.com/TTimo/doom3.gpl.git

Link to comment
Share on other sites

Quake 1 coding community has made their first shadow performance fix (average = 1.5x faster and scales further in heavy scenes):

Code:

 

if (!external)

 

{

qglStencilOpSeparate (backEnd.viewDef->isMirror ? GL_FRONT : GL_BACK, GL_KEEP, tr.stencilDecr, tr.stencilDecr);

qglStencilOpSeparate (backEnd.viewDef->isMirror ? GL_BACK : GL_FRONT, GL_KEEP, tr.stencilIncr, tr.stencilIncr);

 

RB_DrawShadowElementsWithCounters (tri, numIndexes);

}

 

qglStencilOpSeparate (backEnd.viewDef->isMirror ? GL_FRONT : GL_BACK, GL_KEEP, GL_KEEP, tr.stencilIncr);

qglStencilOpSeparate (backEnd.viewDef->isMirror ? GL_BACK : GL_FRONT, GL_KEEP, GL_KEEP, tr.stencilDecr);

 

RB_DrawShadowElementsWithCounters (tri, numIndexes);

 

 

http://forums.inside3d.com/viewtopic.php?f=9&t=3491&start=45

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

Link to comment
Share on other sites

Quake 1 coding community has made their first shadow performance fix (average = 1.5x faster and scales further in heavy scenes):

 

I'm not knowledgeable enough to say for sure, but that code looks rather a lot like

 

the open source community will end up putting the depth fail method back in,
Link to comment
Share on other sites

Well, it seems the author is claiming that the IHV drivers are tuned better for the qglStencilOpSeparate extension as the reason for the performance gain...

 

"Someone else" would have to confirm :laugh:

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

There are a number of people already working on amd64/x86_64 (take a pick). Have a gloss over the graph of branches on github and you can sort of follow what's going on. The zfail method has also already been reimplemented, but the performance difference is rather minimal it seems.

Link to comment
Share on other sites

The zfail method has also already been reimplemented, but the performance difference is rather minimal it seems.

 

It is not much about performance, it is more about easy of install. After all if performance were so better I think Id would already did it.

 

Are you referring to native 64-bit support? Serpentine was talking about the "Carmack's Reverse" graphics optimisation which had to be removed for legal reasons, which is a performance issue. You're right that 64-bit support is nothing to do with performance but being able to easily use the application without having to install a load of compatibility libraries.

Link to comment
Share on other sites

Are you referring to native 64-bit support? Serpentine was talking about the "Carmack's Reverse" graphics optimisation which had to be removed for legal reasons, which is a performance issue. You're right that 64-bit support is nothing to do with performance but being able to easily use the application without having to install a load of compatibility libraries.

 

Uh, I think that the convience to not have to install/load compatibility libraries isn't really the selling point of 64, but the performance (and memory usage) is. After all, TDM works just fine on all systems so far, the few libs it loads/contains statically really don't make a difference.

 

Using 64 means you have more registers (at least that is so on x86 vs x86-64), so the CPU can hold more things internal instead of furring them to/from memory - think if you want to copy a very long telephone number by hand from one piece of paper to another one. If you can memorize 5 digits at a time that goes faster than if you can only remember 3 at a time. (The same idea is behind the SSE/MMX etc code, it computes 2/4/whatever numbers instead of 1 at a time, so if used properly it can speed up some things).

 

Also, on a 64bit OS a 32bit application can only use 3 (under Windows w/o large patch even only 2) gbytes of memory - if your application needs more than that, it either crashes or needs a complicated and slow paging/caching system. With 64bit, it can use 8 Gbyte or whatever just fine.

 

The downside of 64bit can be that if you simply convert data structures to be 64bit wide instead 32bit (even when all data fits in 32bit wide integers), than you use twice the amount of memory. Which can have serious performance downsides if that overflows the cache and/or main memory capacity because then slow paging occurs. Usually that can be avoided tho by not blindly making everything 64bit wide.

 

 

Anyway, having a 64bit version of D3 can only be good. All these people hacking away at the source means that we need to not only integrate it in ours, but also need to have some way to update our integration somehow. Oh well...

"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

Make a github fork of the "best" optimization fork, and merge regularly. It doesn't seem too hard.

 

Though considering you already have a system in-place maybe it is too disruptive for your workflow.

 

Not using git?

 

No, we use SVN (and we like it :). The problem isn't even with regular merging stuff from upstream, but our engine source is already quite a bit modified and we'd somehow sync these back. Over time, the two versions would just diverge too much.

 

Definitely not an easy topic :)

"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

Uh, I think that the convience to not have to install/load compatibility libraries isn't really the selling point of 64, but the performance (and memory usage) is. After all, TDM works just fine on all systems so far, the few libs it loads/contains statically really don't make a difference.

 

I realise there are long-term development benefits of 64-bit. However in a practical sense it is unlikely that simply compiling D3 in 64-bit mode is going to give a big performance boost, which makes installation ease the most visible benefit at this stage. Certainly there could be other benefits down the line, for example support for large maps by using > 3GB memory.

 

Not using git?

 

No, we use SVN (and we like it :).

 

It might be a good opportunity to consider the versioning system used for the mod code (not the assets, SVN is probably a better choice there). Merging in general is a lot easier with git, especially if the upstream changes are being published using git as well. Certainly after using it for some time, even just locally with a shared SVN repository using git-svn, going back to raw SVN feels like developing with one hand tied behind your back.

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

      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.
      · 1 reply
    • 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
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...