OpenGL2's r_autoExposure 1 doesn't work correctly in splitscreen

[zturtleman]

The whole screen is affected instead of being applied to each drawn viewport separately.

It's disabled by default as of 764cc7c.

[ghost]

Maybe I'm wrong, but I think this is also true for the sunrays (r_drawSunRays). They are turned off by default, but if they are turned on, the sunrays are affected by parts of the whole screen (or at least part of the screen of the other splitscreen players).
As already said, the sunrays are off by default, so it's no big issue for the moment...
Here is a screenshot showing the scoreboard mixing into the sunrays of the other viewports, or at least the colors of the scoreboard are mixed into the sunrays:

Tested with Wolfenstein-Enemy Territory map called battery (r_drawSunRays 1).

[zturtleman]

I disabled sun occlusion query which did not work correctly with multiple world scenes. c9159d2

I'm not able to get the sun rays to change colors. Can you edit code/renderergl2/tr_backend.c to display the sun ray image and post a new screenshot?

const void *RB_PostProcess(const void *data)
{
...
	// ztm: disable the if 0 for sunRaysImage block
	//if (0)
	{
		ivec4_t dstBox;
		VectorSet4(dstBox, 256, glConfig.vidHeight - 256, 256, 256);
		FBO_BlitFromTexture(tr.sunRaysImage, NULL, NULL, NULL, dstBox, NULL, NULL, 0);
	}

[ghost]

Here is a screenshot when I disable the if 0 for sunRaysImage block:

Unfortunately, the sun ray image doesn't show the mixed scoreboard.
On the other hand, at least I found out that the mixed colors/scoreboard depends on r_ext_multisample. If it is > 0 the colors occurs, if it is 0 the psychedelic sun rays are gone :)

Example: start battery map again, do r_drawSunRays 1; r_ext_multisample 2, now you can move your mouse around and you can change the color of the sun rays! For example the yellow 'line' in the sun rays of player 1 is the yellow text of '3rd' of the third or fourth player's scoreboard. The red rays of player 2 is the scoreboard header (ping, time, etc.)...

Probably this issue is somehow related to ioquake/ioq3#121, although this time I talk about r_ext_multisample not r_ext_framebuffer_multisample. This is just a thought!

...or it's just Lucy in the Sky with Diamonds?

[zturtleman]

Ah, yeah r_ext_multisample 2 causes that for me too (which looks kind of awesome). It seems to be issue with ioq3 opengl2 accessing wrong framebuffer data when viewport is smaller than screen size. It seems unrelated to r_autoExposure and flares through mirrors.