Jump to content
The Dark Mod Forums

duzenko

Active Developer
  • Posts

    4149
  • Joined

  • Last visited

  • Days Won

    50

Posts posted by duzenko

  1. 22 hours ago, Nort said:

    Further, this version of TDM doesn't even seem to write a console log anymore! Is there a way to enable it? ...because these logs seem to contain more details about errors and warnings, and I often copy them into other documents.

     

    Depends on what you call 'console log'

    Game console GUI works for me

  2. 1 hour ago, Nort said:

     

    Since I am completely unable to get rid of this error, even after having recreated the entire map from scratch, I guess I really can't solve this on my own. This error wasn't always there during the map creation either.

    Exactly what files do you need, and where do I upload them?

     

    Your mission folder

  3. 2 hours ago, Nort said:

    Okay. You're being a bit cryptic here, but my best assumption is that I made a negative scale on a texture at some point, or made a negative rotation of it, which I vaguely remember doing. It sure would help if I had a search function for what I assume is "texture number 34842". (I only know how to find brushes and entities, and I doubt there's 35 000 brushes in my map right now.)

    There are of course the warnings regarding two normal stock models, which can't find some textures for some reason, and a model I tried to reskin with a texture it didn't want. I could try removing them. Maybe I should upgrade to the latest version after all.

     

    To be able to repeat the warning I'll need a test map

  4. 7 minutes ago, HMart said:

    Holly sh I saw something strange right now, when I started the game with my own compiled exe. 

    When using the original TDM exactable, all sliders in the menu miss the small red gismo, that you use to see where the slide value is at, when using my compiled exe the gismos are there!? What could be causing that? 

    Off the top of my head the versions of compiled and original are different

  5. 1 hour ago, Whatev said:

    I used to play TDM years ago on this same old laptop and it worked fine. Decided to reinstall it today and any mission I launch I get appcrash before it even starts (just after the loading bar fully loads it crashes). I was wondering if new updates made the game unplayable on old stuff like the HD 4000? 

     

    cheers

    https://forums.thedarkmod.com/index.php?/topic/21333-tdm-wont-run/&do=findComment&comment=471717

  6. 4 hours ago, datiswous said:

    So is it possible to make walls and ceiling of a room look transparent through an x-ray screen? It seems to be possible at least through skins. If a bigger room is put around it, through the x-ray screen it would look like it has the bigger room size, looking through transparent walls.

    I suppose so

  7. There's the mini-ITX option, but not sure if any of your two GPUs will fit into it - and it would require a new motherboard - and a new monitor purchase at destination

    A friend of mine relocated twice internationally with a PC, _two_ monitors, and a kid. No idea how he pulled it off. When I asked, he said "I put it into the luggage"

  8. 2 hours ago, stgatilov said:

    I will probably have to get rid of my desktop PC, and I'm worried about how to work on TDM without it.

    Obviously, I need a laptop, but:

    • Laptops without discrete GPU will probably run TDM too slowly. Can anyone share positive experience about that?
    • Laptops with discrete GPU (gaming laptops) are often unreliable. I'm worried that they die too quickly...

     

    You should absolutely get a discrete GPU. They are not that expensive.

    As for reliability, just turn VSync on and switch the GPU driver to power saving mode.

    Intel HD5500 (15W). Iris 540 (15W), AMD Ryzen 4650U (20W) have all disappointed me greatly.

    I also own one with a discreet GTX 1050 and it's so much better. OTOH its old CPU is stuck at 2.5GHz, so I'm sometimes cpu-limited in some missions.

    Maybe the full-power chips from the Ryzen H series are slightly better, but they cost as much as discreet GPU models and are generally rare.

    The integrated graphics has always been about cost saving, never about competitiveness.

    So discreet only, and equally important to have two memory slots or at least 32GB soldered. Ideally with a CPU that can turbo-boost to 4GHz.

    I would ironically advise a macbook, even though I don't own one because I like my notebooks to have touch screen interface. I'm curious to see how Apple silicon fares compared to x86 gaming market.

  9. On 3/20/2022 at 3:32 PM, HMart said:

    I don't know, not a graphics programmer, just curious but I'm sure there are more than one, like for all graphics techniques. 

    A online search gets me this links:

    https://developer.nvidia.com/gpugems/gpugems3/part-ii-light-and-shadows/chapter-13-volumetric-light-scattering-post-process

    https://www.slideshare.net/BenjaminGlatzel/volumetric-lighting-for-many-lights-in-lords-of-the-fallen

    https://dl.acm.org/doi/10.1145/1730804.1730823

    https://www.jianshu.com/p/f5e87d23f18d   // intel invented technique

    https://github.com/robertcupisz/LightShafts   // using the Intel technique of the link above

    Also have you guys looked at the sikkmod god rays post process effect? IMO Is not as good looking and realistic, compared to the current one you guys implemented, is mostly for outdoor, sun rays and also uses ARB shaders but one thing it has for it, is smooth looking and is fast.

    "The original effort was naive multisampling" The only thing I know about MS is that is used for anti-alising :D

     

     

    Don't they all talk about the same thing? I can't see any shader code, only general description

  10. 1 hour ago, nbohr1more said:

    Yes both. "Scroll of Remembrance" is possibly our worst case scene. Briarwood Manor at least appears to have made a reasonable attempt to optimize based on advised practices.

    Scroll of Remembrance

    image.png

    Written in Stone

    image.png

    IMHO the former is sheer draw call abuse while the latter is more than that - many moving entities, etc

    I never looked at Scroll of Remembrance before, but yeah, the lack of optimization effort is obvious

    • Like 1
  11. 1 hour ago, nbohr1more said:

    "Written in Stone" is not the heaviest mission for CPU's.

    Try "Scroll of Remembrance" if you want to make a CPU scream in pain.

    Even "Briarwood Manor" outdoor area is heavier than "Written in Stone" .

    Also opening scenes?

    AFAIR Briarwood Manor was classic case of triangle count excess

    Written in Stone is not - it's doing a lot of everything, not just iterating over one huge triangle list

    • Like 1
  12. Could be as trivial as out of memory

    In order from least pain

    1. Add more RAM
      • kill all running and background programs, including antivirus
      • use the texture quality cvars
    2. Search the web for recipes how to install "not suitable" drivers on locked laptops like yours
      • Try dual boot Linux with latest driver for it
    3. Get a newer PC
    4. Stay on 2.09
    5. Get the source code, debug, offer a workaround patch
  13. 1 hour ago, stgatilov said:

    I see the error on the same call stack.

    I don't understand why multi-draw-indirect code path works, and this one crashes. There is no check for invalid buffers in either of them.

    Perhaps we can simply check for validity of vertex&index cache here:

    	vertexCache.VertexPosition( attribBind == ATTRIB_REGULAR ? drawSurfs[0]->ambientCache : drawSurfs[0]->shadowCache, attribBind );
    	vertexCache.IndexPosition( drawSurfs[0]->indexCache );

    And skip drawing if any of the caches is invalid?

    UPDATE: Ok, I think multi-draw-indirect goes away because: "Note that indices stored in client memory are not supported. If no buffer is bound to the GL_ELEMENT_ARRAY_BUFFER binding, an error will be generated." Ordinary draw calls support client memory, so the driver treats zero offset as a pointer, leading to crash.

    I'm not sure why indirect path does not crash - maybe its group's first handle is valid, and the invalid handles don't unbind the index VBO

  14. Awwwww, on a Nth retry I was gifted with some debug context wisdom

    Capture.PNG

    This happens when index buffer resizes and some frame-temporary surfaces don't have valid VBO handles.

    So what I think the difference between the new and old backends is - the old sends the client-side index data to the draw routine while the new ignores the error and still sends nullptr (with index buffer unbound) to driver.

    I'm going to let @cabalistic and @stgatilov decide on it

    Capture.thumb.PNG.d79d64abced00970019c2168fd9eb0b1.PNG

    • Like 3
×
×
  • Create New...