Zero multisamples in fullscreen causes washed-out look

General Discussion
1

Hello,

I’m developing a 90’s style game running on 640x480 resolution fullscreen. I’m trying to disable multisamples to get a crispy, sharp look, which isn’t really achievable with antialiasing. In window it seems to work fine, but when switching to fullscreen, the screen looks washed-out. My suspicion is that an extra sRGB conversion takes place.

This issue can be reproduced by using the Roaming Ralph demo. First I set the following variables to config:

win-size 640 480
fullscreen #f
framebuffer-multisample #f
multisamples 0

The result seems perfectly fine in windowed mode. Ralph model is not being antialiased:

Then I set fullscreen on (fullscreen #t), and what I get is this:

I’ve tried to fiddle with textures-srgb and framebuffer-srgb config parameters, but nothing seems to yield the correct result in fullscreen. Any ideas? I’m running pre-built Panda3D 1.9.4 on Windows 7 64bit.

2

Try playing with the gamma setting to see if that might be configured differently:

base.win.getGsg().setGamma(1.0)
3

Using a value of 0.6 seems to bring it roughly back to the right brightness. That’s odd, it would be reasonable to expect that multisamples wouldn’t have an impact on gamma. But I’ll take this as a workaround, thanks for the help!

4

Wow, that is really strange. If it were a faulty sRGB conversion, the right gamma correction to revert that would be closer to 0.45.

Could you share your graphics card details, for the record?

5

Actually now that you say it, 0.45 might be closer than 0.6. It’s a bit difficult to measure the correct values since gamma fix is not applied to screenshots, so I’m just eyeballing it.

Here’s the graphics card info. My drivers were a bit outdated, but I updated and checked that the same issue persists with the latest ones, just to be sure. If it helps, I’m running a fullHD dual-monitor setup with DVI connectors.

6

Oh, and one more thing. Each time I launch a Panda3D application, Windows Aero gets disabled during the execution time. This happened also with some older editions of Blender. No idea if this has anything to do with this issue though.

7

Ah, it disables Windows Aero? Could it be that Windows is running it in compatibility mode for some reason? Try rightclicking python.exe (or ppython.exe - whichever one you launch) in the “python” subfolder of the Panda3D installation folder, and going to Compatibility, to make sure all compatibility settings are off.

Furthermore, try adding “notify-level-wgldisplay debug” to Config.prc. This will tell us about the pixel format that it’s selecting (including whether it grabbed an sRGB pixel format for some reason).

8

No compatibility modes seem to be active. Aero gets disabled during the creation of Panda3D window, not when the Python interpreter starts, so I think it’s safe to rule out compatibility mode as a cause.

When this happened to Blender, there was some discussion around the topic:
developer.blender.org/T49215

This is what Roaming Ralph outputs when notify-level-wgldisplay is set to “debug”:

Known pipe types:
  wglGraphicsPipe
(all display modules loaded.)
:display:wgldisplay(debug): Preliminary pixfmt #197 = depth_bits=24 color_bits=48 red_bits=16 green_bits=16 blue_bits=16 alpha_bits=16 back_buffers=1 force_hardware
:display:wgldisplay(debug): Found 140 advanced formats: [ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 5
1 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 13
7 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 200 201 202 203 204 205 206 207 ]
:display:wgldisplay(debug): Selected advanced pixfmt #197 = depth_bits=24 color_bits=48 red_bits=16 green_bits=16 blue_bits=16 alpha_bits=16 back_buffers=1 force_hardware
:display:wgldisplay(debug): ================================
:display:wgldisplay(debug): Selected GL PixelFormat is #197, ICD driver
PFD flags: 0x0000000000000225 ( PFD_DOUBLEBUFFER| PFD_SUPPORT_OPENGL| PFD_DRAW_TO_WINDOW| PFD_SWAP_EXCHANGE|)
PFD iPixelType: PFD_TYPE_RGBA
PFD cColorBits: 64  R: 16 G: 16 B: 16
PFD cAlphaBits: 16  DepthBits: 24 StencilBits: 0 AccumBits: 0
9

Oh, nice find! From that bug report:

This seems to be exactly what is going on with Panda, judging by the output you posted:

PFD cColorBits: 64  R: 16 G: 16 B: 16

Does it work when you set the precise following settings in Config.prc?

color-bits 8 8 8
alpha-bits 8

Panda does give priority to pixel formats that match the requested number of bits precisely, but it may not be enough to cause it to win out over the 64-bit format.

We’ll need to do something similar to what Blender does: down-prioritise pixel formats higher than 32 bits per pixel.

10

Yes, it seems to fix the issue, gamma seems absolutely fine in both fullscreen and windowed, and no need for the previous compensation workaround. Awesome, thanks!

11

I think I’ve checked in a fix for this issue now in the latest GitHub version.