Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


duzenko last won the day on September 22

duzenko had the most liked content!

Community Reputation

502 Legendary


About duzenko

  • Rank
    Uber member

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Added GL3 fallback. It's visibly slower on heavy maps like Perilous Refuge but still playable nVidia 1050: 80 vs 56 fps. Intel 630: 26 vs 24 fps. Do we want to duplicate static data on GL3 GPUs so that we can use mapping with a single VBO? At least for indices, which are more dynamic than vertices. I'm a bit sad that glBufferSubData is this slow. I expected higher speed on nVidia. It feels like the driver pages the changed buffer portion in on a per-drawcall basis. Or maybe add one more 'back' buffer, map it, and then just qglCopyBufferSubData from it to main VBO? Must be faster than stalling everything with what I have now. Then we'll have two dynamic frames + back buffer, instead of three frames as now.
  2. Worrying: on my work PC even the latest nvidia driver crashes with x64 builds.
  3. Problem: crash on x64 after map load inside nVidia driver. x86 just works. Puzzle: qglFlushMappedBufferRange does not seem to be doing anything. x86 works great without it. x64 still crashes after map load. No crash on Intel. Edit: NM, driver bug. Went away after driver update. As for flushing, should we not unmap the buffer every frame?
  4. Did this in svn. The persistent mapping path only for now. Will add fallback for incompatible drivers later. The extension seems to be supported for all GL4 drivers, even though it was only cored in 4.4.
  5. If it's something needing a fix on the C++ side, I can look at it but I will need a test package.
  6. duzenko

    Raspberry Pi 4

    Where is the source code the compiled from? What they should have benchmarked was Doom3 BFG which is a much more modern, performant, adapted for current hardware version. Number wise, FPS = TDP. Aren't there Intel Atom based micro PC's that can do the same thing faster and easier?
  7. Done more web research and it gets frustrating. Here's my thoughts at this point. I take it for granted that everyone today is on digital-interface screens. I mean, there's exactly 256 grades of each color component that your screen can show, with any given backlight intensity. If your screen is cheap, you can get 64 instead of 256 (18-bit panels). It should mean that any non-default (<>1) value for r_gamma and r_brightness will absolutely result in loss of color precision. Same applies to postprocessing, unless it squashes all low-range pixels to black. I would like to hear from everybody interested 1. Why are people stuck with non-default gamma/brightness? Is the picture too dark for them? Why is it a bad idea to just give them control over r_lightScale instead (lightgem excused)? 2. If you want to light up the dark areas without overbrightening what's already well lit, then what about crunching up the main ambient light? Returning to sRGB feature I was playing with. The gamma compensation works well for me but it's not actually how it was supposed to be used. The idea behind it was, AFAI understand it, to give more precision in low-range (darker shades) which, if done properly would have effectively eliminated color banding. The shocking conclusion (unless I am wrong) is, there's no way to actually display this improved picture to the end-user because your digital screen still can only show the same fixed colors. Similarly, Windows DWM only knows about 8 bits per color in linear space. So even if we get better color range in video memory, we still need 1. a screen that understands more than just linear color space, 2. graphics driver that can communicate to that screen and can translate from OpenGL, and 3. Windows support if we want to see this HDR in a window, rather than exclusive fullscreen. Back to color banding. Is it an issue? Do people here want to see it fixed?
  8. Hi @JackFarmer Can you do one more tweak for me please? The terrain patches seem to be able to cast shadows which renders my single shadow map code terribly slow. Could you mark them as noshadows?
  9. No problem Does it make sense to try to repeat the crash with notarget/noclip cheat codes?
  10. @nbohr1more Please review revision: 15724
  11. Played some with this It seems like a good replacement for shader-level ambient crutch-up like I did way before with r_ambientMinLevel Q: How is it better than r_gamma? A: It only affects the 3D world. Other system windows, 2D and GUI remain un-bleached Q: How is it better than r_ambientMinLevel? A: The latter cvar only applies to ambient lights (and arguably makes small ambient lights ugly). This alternative works with all lights, and accurately does additive blending on them. We should probably drop r_ambientMinLevel completely as it's a worse option and clutters the shader code. Q: What about color banding in shadows? A: Regret it's still there, and it might be the only deterioration compared to r_ambientMinLevel. On the other hand we can now use extended range framebuffer formats (e.g. 10 bit per color channel vs. 8 bit) to work around that. Q: What about non-light materials, such as environment cubemaps, emissives, etc? A: It probably does not make sense to apply this color correction to them as it would break existing missions. Total assets rebuild is not something anyone wants. Q: Lightgem? A: Not affected. Q: But r_gamma allows me to tweak the correction to the level I'm most comfortable with. Do I have the same options with sRGB? A: No. The sRGB values are fixed and cannot be adjusted AFAIK. Q: What is gamma again and why do I need to bother? A: It's all about your monitor. All monitors produce different picture. You obviously run TDM on an LCD that, theoretically, has nothing to do with CRT's non-linear input/output curves. In the end, it all boils down to your own perception - is the picture too dark or bleached out? (See the attached pictures) Toggling this option should give you some control over that.
  12. Right, I meant to upload to google drive or somewhere and link to it here Can you still crash it from the original save?
  13. Could you attach your savegame please, just in case
  • Create New...