Jump to content
The Dark Mod Forums

TDM Engine Development Page


zergrush

Recommended Posts

  • 2 weeks later...

Pretty sure we will.

 

We already have a 2.07 beta thread, sorta:

 

http://forums.thedarkmod.com/topic/19257-testers-and-reviewers-wanted-bfg-style-vertex-cache/

  • Like 1

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

Pretty sure we will.

 

We already have a 2.07 beta thread, sorta:

 

http://forums.thedarkmod.com/topic/19257-testers-and-reviewers-wanted-bfg-style-vertex-cache/

 

I have the update 10 applied and I switched my mapping project to that build, as it supports the engine commands I need (reloadimages first and foremost). And, with all these uncompressed TGA textures I'm using, the loading time is 10x times faster than on 2.05. I'd be grateful if you did some future updates, and I can test stuff, if need be.

Link to comment
Share on other sites

Yep.

 

For outdoor shadows you either need to have cutoff distance\size for Shadow Maps to Shadow Volumes

or you need some sort of projection sampling LOD system like Parallel Split Shadow Maps:

 

https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch10.html

 

Not that I'm current on the scene at all but the the latest Shadow Map performance technique I know of is this one:

 

http://hd-prg.com/tileBasedShadows.html

 

It requires OpenGL 4.4 but is supposedly a beast for multiple moving lights (etc).

  • Like 2

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

FXAA can be used from the old ARB shaders also, so that would not be a problem.

Speedwise its not noticable atleast for me with sikkmod, but less capable gfx cards might take a bigger hit.

 

seems AA and FBO does not play super well together from what i can gather around the net, though it should be possible to fix it.

All comes down to the ammount of code needed to get there :)

Link to comment
Share on other sites

I made an experiment and converted the fbo code to C++ classes.

I have not upped this experiment to svn so no worries i wanted to discuss it first.

 

Theres a good reason why we might want this, for one automatic constructors / destructors, and we could simplify the code a good deal.

 

Speedwise i had not anticipated any gain but strangely enough it actually loads faster now, go figure... :huh:

 

I can upload the changed code somewhere if you want to toy with it before deciding.

Link to comment
Share on other sites

Afaik, we don't have any problems with AA and FBOs currently, that's all been resolved. And yes, we do want to encapsulate them in their own class. In fact, I already created a prototype for this which has already been discussed in the internal dev forum, so you might be a little late to the party ;)

 

But it's been postponed till after 2.07 and is planned for the major renderer upgrade to GL3. Right now, this change is just too risky for a release aimed at bugfixing...

  • Like 1
Link to comment
Share on other sites

So the AA problems have been fixed ?, ok thats nice :)

 

Tested my version of the class based FBO code, it works just like the unmodified version, no visible change besides faster loading.

I made some of the functions private because they are not used outside the FBO code.

I also moved the static initializers to a constructor but kept the destructor as a seperate function for now.

 

So far i tried 10 maps with different shadow options and i see no visible difference, from the unmodified one.

I dont mind posting a test executable you can try if you want.

Link to comment
Share on other sites

So the AA problems have been fixed ?, ok thats nice :)

 

Tested my version of the class based FBO code, it works just like the unmodified version, no visible change besides faster loading.

I made some of the functions private because they are not used outside the FBO code.

I also moved the static initializers to a constructor but kept the destructor as a seperate function for now.

 

So far i tried 10 maps with different shadow options and i see no visible difference, from the unmodified one.

I dont mind posting a test executable you can try if you want.

With recent experience I am actually anticipating code loss and a series of re-reverts after something like this

Are there any benefit beside the change itself?

Where is the "speed up" coming from?

Why not re-write entire renderer in classes? Why come at the part that is changing most frequently?

Link to comment
Share on other sites

Rewriting the entire renderer with classes might be next step, but it will be a big ammount of work.

The goal for me was simplifying the code a bit, i did not expect any gains speedwise at all, but strangely that was what i got. Need to investigate that one.

 

Reducing the state changes would have been a more likely candidate for a speedup, but that part was not even in when i tested it the first time around.

Link to comment
Share on other sites

Keep in mind, please, that I also do have some early prototypes lying around for a move to GL3/4 with significantly reduced state changes. I'd suggest postponing any such experiments until after 2.07 and then coordinating our efforts towards the GL upgrade. Because otherwise we're just duplicating each other's work...

  • Like 1
Link to comment
Share on other sites

Rewriting the entire renderer with classes might be next step, but it will be a big ammount of work.

The goal for me was simplifying the code a bit, i did not expect any gains speedwise at all, but strangely that was what i got. Need to investigate that one.

 

Reducing the state changes would have been a more likely candidate for a speedup, but that part was not even in when i tested it the first time around.

What I am trying to say, this is very much WIP. Any change for the sake of change is bound to bring more problems than good.

There are real and important things to do - if you want to help, just ask.

  • Like 2
Link to comment
Share on other sites

no sense in that atleast, though its interresting with the load times ;).

 

Do you plan on an approach like fhdoom's when changing to gl3/4 ?, i noticed he changed most of the renderer to class based.

Haven't looked at fhDoom's approach. But a class-based design is the goal, yes. It will especially come in handy to cleanly separate the optional GL4 improvements.

  • Like 2
Link to comment
Share on other sites

Changes with no use would be counter productive i agree on that :) the goal was not so much speeding anything up, but rather to compartialize the code making it easier for other devs with no previous history coding in C to just jump in and make fixes. Im sorry if im not allways clear, english is not my main language.

 

What i wanted to achive was something similar to cabalistics plans for gl3/4, i just started in the framebuffer code because it was allmost pure C, but eventually i want to make the entire renderer class based like he would.

 

So it seems we had the same idea, i just came in a bit to late. But when the time comes then i would not mind in helping getting it together :).

 

So what are the most WIP problems atm ?, please nothing in regards to shaders, im not profient enough with those yet.

Link to comment
Share on other sites

Changes with no use would be counter productive i agree on that :) the goal was not so much speeding anything up, but rather to compartialize the code making it easier for other devs with no previous history coding in C to just jump in and make fixes. Im sorry if im not allways clear, english is not my main language.

 

What i wanted to achive was something similar to cabalistics plans for gl3/4, i just started in the framebuffer code because it was allmost pure C, but eventually i want to make the entire renderer class based like he would.

 

So it seems we had the same idea, i just came in a bit to late. But when the time comes then i would not mind in helping getting it together :).

 

So what are the most WIP problems atm ?, please nothing in regards to shaders, im not profient enough with those yet.

@nbohr1more has reported blinking skybox in Rightful property with r_shadows 2

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