Jump to content
The Dark Mod Forums

Recommended Posts

Posted

Yes, but the structure has implications for both. For example, the backend spends a noticable amount of time binding vertex buffers, which the BFG edition doesn't have to, afaict. As such, I believe that the BFG version lowers costs for both frontend and backend, which is exactly what we'd need at this point.

If only someone could just switch our system to one big vertex buffer...

  • Like 1
Posted

Original:

 

https://pastebin.com/rHrwP0nA

 

Revelator's first relay of it:

 

http://forums.thedarkmod.com/topic/15178-tdm-engine-development-page/page-25?p=358097&do=findComment&comment=358097

 

he also has a hybrid BFG\Vanilla with some of these changes:

 

https://github.com/revelator/Revelation

 

Pat Raynor's hybrid BFG\Vanilla version also uses mapBufferRange:

 

https://github.com/raynorpat/Doom3

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

Posted

@nbohr1more: I was now able to reproduce the visual artifacts you reported on an older PC with an older Nvidia card :(

Unfortunately, I don't normally have access to this PC, so unless I accidentally find the root cause tonight, it's still going to be tricky to debug this since it's just not happening on my primary dev machine.

 

Evidently, this needs more testing. I'd really appreciate some more people try out the build (you don't need a VR device) and report any problems along with their hardware. There are clearly some issues left.

  • Like 2
Posted

@nbohr1more: I was now able to reproduce the visual artifacts you reported on an older PC with an older Nvidia card :(

Unfortunately, I don't normally have access to this PC, so unless I accidentally find the root cause tonight, it's still going to be tricky to debug this since it's just not happening on my primary dev machine.

 

Evidently, this needs more testing. I'd really appreciate some more people try out the build (you don't need a VR device) and report any problems along with their hardware. There are clearly some issues left.

You should now have full svn access?

Could you add a switch to toggle SMP on and off?

  • Like 1
Posted

No I don't. Or if I do, nobody told me.

Either way, working on this in SVN isn't helpful, because I need people to actually *test* it. Until the SVN assets are publically accessible, that means tests can only happen with my 2.05 build :(

  • Like 1
Posted

To my knowledge, you should now have full SVN access.

 

I understand that it's not your preferred workflow but the "TDM team" does test changes in SVN and then when the 2.06 beta begins

the assets will be made available to "beta testers". (We could possibly consider a 2.06 alpha as well to gather more testers.)

 

Don't get me wrong, I wholly agree that we should offer assets to accompany our read-only developer SVN access so

that outside developers can more easily integrate their work.

 

I think it's time to start another big internal argument about that soonish... ;)

  • Like 3

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

Posted

Added the r_smp cvar.

My wild guess about the glitch some have with smp could be related to vertex buffer use on a thread? If so we need to switch to permanent VB data pointer that must be safer in terms of thread sync.

  • Like 1
Posted

I was able to make the Problem disappear by ensuring that Frontend and Backend run after one another, but still in separate threads. So the use of vbo on the other thread is not in itself a Problem. It appears there is still a genuine race condition, with the Frontend manipulating something that is used in the back. Just wondering why I can't reproduce it on my dev machine.

 

I do habe a work laptop with a 960M, I'll try if it happens there.

  • Like 1
Posted

 

 

Thank you. I'm not sure if logging is on. Perhaps you can tell by the contents of my log file, which are as follows:

 

[game\DarkModGlobals.cpp ( 362):INI (INIT) FR: 0] LogFile created at 2017.08.08 21:03:23
[game\DarkModGlobals.cpp ( 365):INI (INIT) FR: 0] DLL last cleaned and rebuilt on Jul 23 2017 11:13:21
[game\DarkModGlobals.cpp ( 367):INI (INIT) FR: 0] The Dark Mod 2.05, code revision 6757
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogBegin: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogEnd: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogInfo: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogDebug: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogWarning: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogError: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FRAME: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_SYSTEM: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MISC: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FROBBING: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_AI: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_SOUND: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FUNCTION: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_ENTITY: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_INVENTORY: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_LIGHT: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_WEAPON: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MATH: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MOVEMENT: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_STIM_RESPONSE: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_OBJECTIVES: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_DIFFICULTY: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_CONVERSATION: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MAINMENU: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_LOCKPICK: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_AAS: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_STATE: 0

 

 

For system crashes, turn 0's to 1's since I'm not sure what's causing your crash.

It might make TDM run slower, but this is only temporary. Once the game crashes, post the darkmod.log file here.

Sorry for the late reply.

  • Like 1

I always assumed I'd taste like boot leather.

 

Posted

I was able to make the Problem disappear by ensuring that Frontend and Backend run after one another, but still in separate threads. So the use of vbo on the other thread is not in itself a Problem. It appears there is still a genuine race condition, with the Frontend manipulating something that is used in the back. Just wondering why I can't reproduce it on my dev machine.

 

I do habe a work laptop with a 960M, I'll try if it happens there.

 

LOL you and John Carmack

 

 

John Carmack - This was explicitly to support dual processor systems. It worked well on my dev system, but it never seemed stable enough in broad use, so we backed off from it. Interestingly, we only just found out last year why it was problematic (the same thing applied to Rage’s r_useSMP option, which we had to disable on the PC) – on windows, OpenGL can only safely draw to a window that was created by the same thread. We created the window on the launch thread, but then did all the rendering on a separate render thread. It would be nice if doing this just failed with a clear error, but instead it works on some systems and randomly fails on others for no apparent reason.

  • Like 1

I always assumed I'd taste like boot leather.

 

Posted

Heh, yeah, that's pretty mich every developer's Problem ;)

This issue is different from Carmack's, though. It should be entirely fixable once I've understood the root cause.

  • Like 1
Posted (edited)

Ok, so I can also reproduce the issue on my laptop, so I do have a device to debug with.

Also, in fullscreen at an increased resolution, I finally managed to see a glimpse of the issue also on my dev machine. Only for a second or so, but it was there. So this is definitely a general issue, which is a relief. For some reason, the GTX1070 is much more stable against it than the GTX960, but still.

Unfortunately, concurrent race conditions are still tricky to debug, but hopefully I can track it down now that I've seen it for myself.

 

@nbohr1more: I did not receive any credentials for SVN. So even if there exists an account for me with access, I still can't access it :)

Edited by cabalistic
  • Like 2
Posted

@nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

 

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

  • Like 2
Posted

@nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

 

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

I would try glMapBuffer + ring pointer writes

Configurable buffer size would allow for 3+ frames of geometry.

Posted

But you have to unmap it for the backend to actually render it. I think the BFG approach of having two buffers and swapping them between each frame is the more viable approach.

 

In any case, this only works for the frame-allocated buffers. Currently, the engine also creates a lot of static objects dynamically in the frontend, which BFG got rid of. That might be a more substantial rewrite, though.

  • Like 2
Posted

Hmm. I guess if you want to go older than OpenGL 3.2, ATI\AMD support NV_fence going back to Radeon 9200

 

http://feedback.wildfiregames.com/report/opengl/feature/GL_NV_fence

 

https://www.khronos.org/registry/OpenGL/extensions/NV/NV_fence.txt

 

Or do a GL version check and do either depending...

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

Posted

@nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

 

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

 

Yes, this build has solved the problem! :)

 

I can now max out tdm_lg_split and tdm_lg_interleave and really open up the FPS here.

 

Edit:

 

Well... 99%of the problem. The skybox in Briarwood Manor flickers when I set tdm_lg_interleave > 1. tdm_lg_split 1 still works though.

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

Posted

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

I think the current approach with OpenGL is: we use something very old like version 2.1, and we enable extensions for anything relatively modern (like e.g. framebuffer).

If you need a fence, there is no problem in using it via GL extension.

Just make sure that when cvar for multithreaded rendering is disabled (I hope it is already present in the code?), this extension is not required. In such case people with old video card can still play the game without issues.

Posted

 

I think the current approach with OpenGL is: we use something very old like version 2.1, and we enable extensions for anything relatively modern (like e.g. framebuffer).

If you need a fence, there is no problem in using it via GL extension.

Just make sure that when cvar for multithreaded rendering is disabled (I hope it is already present in the code?), this extension is not required. In such case people with old video card can still play the game without issues.

Can't see why support 2.1 when everyone is on DX10 hardware these days: http://store.steampowered.com/hwsurvey/videocard/.

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

    • jivo

      I just uploaded a new version of the Visible Player Hands mod. It's been updated for TDM 2.13 and has new animations. Check out the post if you're interested!
      · 0 replies
    • datiswous

      I moved from Manjaro Linux (rolling release) to Linux Mint (LTS). One of the reasons was that I found the updates a bit too often and long. But now on Mint I get updates every day, although they're usually small updates.
      · 3 replies
    • JackFarmer

      "Hidden Hands: Vitalic Fever" - new update available including subtitles & compressed briefing video (thanks to @datiswous) and several fixes.
      · 0 replies
    • Wolfmond

      🇬🇧

      2025-04-20
      I'd like to track my level design progress a bit more often now, so I'm using the feed in my profile here.
      I've been working intensively on Springheel's YouTube course over the past few days. I'm currently up to lesson 8. There is so much information that needs to be processed and practiced. 
      I have started to create my own house. As I don't have the imagination to create a good floor plan, I grabbed a floor plan generator from Watabou and experimented with it. I chose a floor plan that I will modify slightly, but at least I now have an initial idea. 
      I used two guards as a measuring tape: The rooms are two guards high. It turned out that I can simply double the number of boxes in DarkRadiant in grid size 8 that are drawn in the floor plan. 
      I practiced the simplest things on the floor plan first. Drawing walls, cutting walls, inserting doors, cutting out frames, creating VisPortals, furnishing rooms.
      I have had my first success in creating a book. Creating a book was easier than I thought. I have a few ideas with books. The level I'm creating will be more or less a chill level, just for me, where I'll try out a few things. I don't have an idea for my own mission yet. I want to start small first.
      For the cellar, I wanted to have a second entrance, which should be on the outside. I'm fascinated by these basement doors from the USA, I think they're called Bilco basement doors. They are very unusual in Germany, but this type of access is sometimes used for deliveries to restaurants etc., where barrels can be rolled or lifted into the cellar. 
      I used two Hatch Doors, but they got completely disoriented after turning. I have since got them reasonably tamed. It's not perfect, but it's acceptable. 
      In the cellar today I experimented with a trap door that leads to a shaft system. The rooms aren't practically finished yet, but I want to continue working on the floor plan for now. I'll be starting on the upper floor very soon.

      __________________________________________________________________________________
      🇩🇪

      2025-04-20

      Ich möchte nun mal öfters ein bisschen meinen Werdegang beim Leveldesign tracken, dazu nutze ich hier den Feed in meinem Profil.
      Ich habe mich in den vergangenen Tagen intensiv mit dem Youtube-Kurs von Springheel beschäftigt. Aktuell bin ich bis zu Lektion 8 gekommen. Das sind so viele Informationen, die erstmal verarbeitet werden wollen und trainiert werden wollen. 

      Ich habe mich daran gemacht, ein eigenes Haus zu erstellen. Da mir die Fantasie fehlt, einen guten Raumplan zu erstellen, habe ich mir einen Grundrissgenerator von Watabou geschnappt und damit experimentiert. Ich habe mich für einen Grundriss entschieden, den ich noch leicht abwandeln werde, aber zumindest habe ich nun eine erste Idee. 

      Als Maßband habe ich zwei Wächter genommen: Die Räume sind zwei Wächter hoch. Es hat sich herausgestellt, dass ich in DarkRadiant in Gittergröße 8 einfach die doppelte Anzahl an Kästchen übernehmen kann, die im Grundriss eingezeichnet sind. 

      Ich habe bei dem Grundriss erstmal die einfachsten Sachen geübt. Wände ziehen, Wände zerschneiden, Türen einsetzen, Zargen herausschneiden, VisPortals erstellen, Räume einrichten.

      Ich habe erste Erfolge mit einem Buch gehabt. Das Erstellen eines Buchs ging leichter als gedacht. Ich habe ein paar Ideen mit Bücher. Das Level, das ich gerade erstelle, wird mehr oder weniger ein Chill-Level, einfach nur für mich, bei dem ich ein paar Sachen ausprobieren werde. Ich habe noch keine Idee für eine eigene Mission. Ich möchte erst einmal klein anfangen.

      Beim Keller wollte ich gerne einen zweiten Zugang haben, der sich außen befinden soll. Mich faszinieren diese Kellertüren aus den USA, Bilco basement doors heißen die, glaube ich. Diese sind in Deutschland sehr unüblich, diese Art von Zugängen gibt es aber manchmal zur Anlieferung bei Restaurants etc., wo Fässer dann in den Keller gerollt oder gehoben werden können. 
      Ich habe zwei Hatch Doors verwendet, die allerdings nach dem Drehen vollkommen aus dem Ruder liefen. Inzwischen habe ich sie einigermaßen gebändigt bekommen. Es ist nicht perfekt, aber annehmbar. 
      Im Keller habe ich heute mit einer Falltür experimentiert, die zu einem Schachtsystem führt. Die Räume sind noch quasi nicht eingerichtet, aber ich möchte erstmal am Grundriss weiterarbeiten. In Kürze fange ich das Obergeschoss an.



      · 2 replies
    • JackFarmer

      On a lighter note, thanks to my cat-like reflexes, my superior puzzle skills and my perfect memory, I was able to beat the remastered version of "Tomb Raider: The Last Revelation" in a new superhuman record time of 23 h : 35 m, worship me!
      · 5 replies
×
×
  • Create New...