Jump to content
The Dark Mod Forums

duzenko

Active Developer
 View Profile  See their activity

  • Posts

    4149

  • Joined

  • Last visited

  • Days Won

    50

 Content Type 

Everything posted by duzenko

  1. duzenko
    Can any _mapper_ repeat this?
  2. duzenko
    Could be as trivial as out of memory In order from least pain Add more RAM kill all running and background programs, including antivirus use the texture quality cvars 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 Get a newer PC Stay on 2.09 Get the source code, debug, offer a workaround patch
  3. duzenko
    The biggest issue with android port is not touchscreen operation but the fact that android runs on low power systems that can't handle the graphics quality for most recent missions
  4. duzenko
    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
  5. duzenko
    Awwwww, on a Nth retry I was gifted with some debug context wisdom 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
  6. duzenko
    I get a crash in driver with the reported .cfg (but not with mine) The breaking difference seems to be r_glCoreProfile 0 vs 2 and new backend 0 vs 1 _Darkmod.cfg
  7. duzenko
    The size is in relative screen units, so it will be the same physical size no matter the screen resolution. Quite few people have 32'' screens honestly. I can see your point however there should be some protection from making the font too small so that user can no longer set it even back
  8. duzenko
    It's capped to min of 3, which was deemed as "ought to be enough for anybody" Related cvars are con_legacyFont, con_fontColor, r_smallCharSpacing, con_noWrap
  9. duzenko
    The only reason could be port incompatibility between monitor and video card.
  10. duzenko
    @stgatilov Where is USE_INTRINSICS defined? I can't see it anywhere in .h files or solution settings It seems to be defined somehow for the tools project but not for the no-tools one
  11. duzenko

    Dying Light 2

    duzenko replied to Fidcal's topic in Off-Topic

    It was not about zombies, it was about melee combat. All that skull-crashing bone-breaking pulp-mashing RAGE!11 if you know what I mean Oh, well, I suppose you did not experience that suppressed frustration thing like I did at the time when the game was released.
  12. duzenko
    The starting location seems to need some optimization.
  13. duzenko
    Conversation subtitles: at some points two phrases overlap and jump over Depth fighting 3. This GUI could use some margin on the right
  14. duzenko

    Which should be the default?

    https://ibb.co/FbcCjP7

    image.png

    1. Show previous comments  4 more
    2. Epifire

      Epifire

      I like how it stands out but I probably wouldn't do so at the expense of how choppy it makes the smooth menu/font elements. EDIT: This was me assuming the left one was getting a sharpening pass.

    3. AluminumHaste

      AluminumHaste

      Filtered looks better to me anyways. Though I like the old style pixels of the left image too, it looks out of place with the quality of the mod.

    4. jaxa

      jaxa

      Right-hand side for sure.

  15. duzenko
    I wondered if Intel got their shit together with that new chip. Apparently not (as expected). Their "market targeting" is utter nonsense. They put 96EU into 25W or even 15W chips and the 125+W chips only include 32/24/16 EUs.
  16. duzenko

    The final solution for low-end GPUs: 

    r_skibSubviews 1

r_skipInteractions 1

r_shadows 0

r_ambientMinLevel 0.6

    tdm_lg_interleave  0

    If you don't get 60 fps after this then either your CPU is really slow or it's a map bug

    EDIT. tdm_lg_interleave is probably not required since r_skibSubviews supersedes it.

    1. Show previous comments  13 more
    2. nbohr1more

      nbohr1more

      r_shadows 1 ( stencil shadows ) is more CPU impacting than GPU impacting but it still relies on GPU "fillrate". Fillrate is really resolution sensitives so be careful with resolution and AA

    3. STiFU

      STiFU

      @nbohr1more those screens are amazing. Playstation 1 style TDM. 😄

    4. nbohr1more

      nbohr1more

      WOO!!! @duzenko just fixed the GUI scaling. Now you can set FBO resolution to 0.05 and still read the console, readables, lightgem, etc :)

  17. duzenko
    While I can't offer any wisdom on Apple ecosystem, assuming we're talking about the same person you've recently had a son with, I'd play it safe and just go with the one they want - and speak up my opinion on the matter one time only at the most. I'd think your son would agree with me when he can speak.
  18. duzenko
    LOL the fog lights are the worst I converted them from texgens to GLSL, and in the process I realized I don't want to spend any time on analyzing the math behind it. Feel free to dump the generated fog texture to a .tga and try to make something off it. I think mappers never liked it too. I suspect (!) that whatever implementation D3 had was a compromise they had to settle on because they were limited with texgens. I want to think about it as a rudiment, that we're better off without. And we'll save on draw calls too. Talking about desired behavior, I'd love the fog to account for diffuse texture alpha. This way we'd be able to fog translucent objects properly.
  19. duzenko
    What it does now is not ideal of course Initially I tried to revise "new fog" path in fog.fs but quickly realized we already have a superior solution in volumetric We might want to copy-paste it into the fog shader and further tweak it there
  20. duzenko
    Should be in the next beta. The exe is for quick feedback.
  21. duzenko
    Thanks, I'm sure there's going to be at least some issues with it. Credits due to stgatilov, his work in the volumetric shader isIused here. Perfect on first try is not my style, lol
  22. duzenko
    Try this exe https://drive.google.com/file/d/0B9OoHSmkeSeNZWdyZFliQkNsVTA/view?usp=sharing&resourcekey=0-4XspmLMtaTte6z6CuIB42g with this fog light { "classname" "light" "name" "light_fog1" "_color" "0.114 0.082 0.063" "light_center" "0 0 0" "light_radius" "496 400 64" "nodiffuse" "0" "noshadows" "0" "nospecular" "0" "origin" "432 696 -184" "parallel" "0" "shaderParm3 " "800" "texture" "fogs/delta1_fog" "volumetric_light" "1" "volumetric_noshadows" "1" "volumetric_dust" "0.0001" } Use volumetric_dust to control fog density It still gives noticeable banding though, especially with postprocessing and 32 bit color Regret your test map is missing a lot of brushes and materials, is mostly black for me
  23. duzenko
    Do you prefer control over fog via light material keywords or spawnargs?
  24. duzenko
    The math behind the Doom3 fog frankly makes little sense Ideally we should tweak the fog shader so that it's not giving seams, etc Do you have a test map with the that bug for me to look at?
  25. duzenko
    Your best map would be to attach a test map
×
×
  • Create New...