Jump to content
The Dark Mod Forums

TDM 2.09: Main menu corrupted with 64-bit Color Precision


zergrush

Recommended Posts

2 hours ago, zergrush said:

I have the same problem too, and I also have a Radeon card. On Linux, however, instead of a black screen, it produces a bunch of colored artifacts obstructing view on the menu. I'll try both test versions and see the results1000

 

etOnf2y.jpg

On Linux try r_fboColorBits 32 and r_useBindlessTextures 0

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

Link to comment
Share on other sites

  • 7 months later...

@Alberto Salvia Novella, crappy colors in menu is another bug, but this time rather surely of AMD driver.

Series of old AMD GPUs don't support 64-bit colors, so you need to set "r_fboColorBits 32", or go to advanced tab of graphical settings and toggle Color Precision to 32.

Unfortunately, we cannot do anything about it, because 1) GL 3.3 requires support of 64-bit color, and 2) the implementation should report unsupported formats via framebuffer incompleteness, and our code already checks for it and prints warning... but in this particular case the driver says everything is OK. There is no proper way to detect this problem.

2 hours ago, Alberto Salvia Novella said:

- [ALSOFT] (EE) Failed to set real-time priority for thread: Operation not permitted (1)

Well, I guess OpenAL decided to bump priority of its thread but your permissions don't allow that. I don't think it is a big issue, and I surely cannot do anything about it.

Quote

- Running from the terminal "./thedarkmod.x64 &> log.txt" results in an incomplete log.

Perhaps lack of flushing?

We usually use either logFile cvar or condump command.

  • Like 1
Link to comment
Share on other sites

14 minutes ago, Alberto Salvia Novella said:

Shall this be fixed in the driver?

Yes, but given the age of GPU, it probably won't happen.

Originally, the problem was narrowed thanks to this news: https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-FP16-DCE8-Patches&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Phoronix+(Phoronix)

But it is not clear what happened with this patch, which drivers it affects, and whether it is about our problem or something else.

Link to comment
Share on other sites

I have found a related "bug": FBO with GL_RGBA16F texture format silent drawing corruption

It turned out to be not a bug.
OpenGL spec says that if either source of destination framebuffer are multisampled, then they must have the same internal format (4.3.2):

image.png.6e48c769620643a6ff6ac7f24028ee39.png

I wonder if something like this could happen in our case.

By the way, if someone who experiences the problem sets "r_ignoreGLErrors 0" and then turns on "r_fboColorBits 64", does it result in spam of "GL_CheckErrors: ???" messages in game console?

Also I wonder if the issue happens always regardless of antialiasing, it if it magically disappears with antialiasing off...

Link to comment
Share on other sites

8 minutes ago, stgatilov said:

I wonder if something like this could happen in our case.

That would surprise my. The resolve framebuffer is always created with the same resolution and format as the multisampled one. If there were an error in the code here, this would be an error that would most certainly also happen on our own machines, because I've seen these kinds of errors when I messed something up :)

Link to comment
Share on other sites

21 minutes ago, cabalistic said:

That would surprise my. The resolve framebuffer is always created with the same resolution and format as the multisampled one. If there were an error in the code here, this would be an error that would most certainly also happen on our own machines, because I've seen these kinds of errors when I messed something up :)

I guess default framebuffer cannot be multisampled, at least GLFW manual says that for the current implementation, and the previous code also disabled multisampling. Both implementations suffer from the problem, as far as I remember.

Link to comment
Share on other sites

We have at least 3 users affected by this:

@Araneidae:
OpenGL vendor: X.Org
OpenGL renderer: AMD CAYMAN (DRM 2.50.0 / 5.9.8-100.fc32.x86_64, LLVM 10.0.1)
OpenGL version: 4.3 (Core Profile) Mesa 20.2.2 core

@zergrush:
Can't find anything more specific than: Radeon card. On Linux.

@Alberto Salvia Novella:
OpenGL vendor: X.Org
OpenGL renderer: AMD CYPRESS (DRM 2.50.0 / 5.10.63-1-MANJARO, LLVM 12.0.1)
OpenGL version: 4.3 (Core Profile) Mesa 21.2.1 core

 

I wonder if we should already introduce a hack for automatically switching to 32 bits on such platforms.
Either by searching for CYPRESS, CAYMAN, and similar codenames of pre-GCN drivers...
Or by checking main menu screenshot for corruption 🤣
Interestingly, screenshot checking sounds more reliable to me.

Link to comment
Share on other sites

The tricky point seems being able to detect if 64-bit color is supported.

Are you sure there isn't a standard way to check which color formats are supported?

Or perhaps which OpenGL version the driver supports, then infer from there the supported color formats.

For example I get:

$glxinfo | grep "OpenGL version string"
OpenGL version string: 3.1 Mesa 21.2.2

Link to comment
Share on other sites

1 hour ago, Alberto Salvia Novella said:

Are you sure there isn't a standard way to check which color formats are supported?

Yes, because we request and require OpenGL 3.3 and don't run on anything prior. And 3.3 requires 64 bit color buffer support, so there's no separate way to query the support. This is - plain and simply - a driver bug.

Link to comment
Share on other sites

6 minutes ago, cabalistic said:

Yes, because we request and require OpenGL 3.3 and don't run on anything prior. And 3.3 requires 64 bit color buffer support, so there's no separate way to query the support. This is - plain and simply - a driver bug.

As I wrote above, there is a general way to check for image format support: create framebuffer object with desired format and check it for completeness. There is special type of error for a driver to say "this is not supported".

We do this check, but the OpenGL implementations under discussion don't report any error.

Link to comment
Share on other sites

  • 6 months later...

@stgatilov

I have this problem too with TDM 2.09/2.10 and

ATI Radeon HD 4650, Linux 5.4.0-107
OpenGL vendor string: X.Org
OpenGL renderer string: AMD RV730 (DRM 2.50.0 / 5.4.0-107-generic, LLVM 12.0.0)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.2.6

Until a fix is rolled out I suggest to put the manual fix into the FAQ Driver Issues.

Edited by reisig
  • Thanks 1
Link to comment
Share on other sites

  • 4 weeks later...
On 4/17/2022 at 2:26 AM, reisig said:

Until a fix is rolled out I suggest to put the manual fix into the FAQ Driver Issues.

I fear there won't be any fix for this.

Drivers won't get updated because I suppose this series of GPU is considered to be too old today.
And to the best of our knowledge, there is no good way to detect this driver defect on TDM side. The best idea yet is to automatically create a screenshot of the menu after a few seconds, then run some heuristic image analysis to detect if it is broken 😲. That's totally unreliable, and will need considerable effort to implement.


Regarding FAQ...

If you have looked through several FAQ locations, please post links to them, and we'll add information.
One of the problem with community-driven wiki is that it gets filled with too much information over time, with most of it becoming irrelevant/outdated 😥

  • Like 1
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

      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.
      · 1 reply
    • 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
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...