MFCD visibility issue due to SRGB being enabled in 2.8

[ColinM9991]

I've also started flying the A-10CII in VR again, as I stopped for some time after this issue was first introduced since it became more difficult to read the symbology.

Unfortunately it is still just as bad in VR.

[ColinM9991]

On 12/30/2022 at 1:55 PM, BIGNEWY said:

Personally not seeing a problem, but I will ask others to check also. 

 

Any updates?

[Hive]

Today I did some testing and raising the brightness of the MFCDs does not help (for me). Then I jumped into the F/A-18 (which I own, but do not fly) and the difference is insane, like night and day. ED, please, please, please just take the Hornet as your reference and adjust the A-10's displays accordingly. The font/symbology is much heavier for the F/A-18 and I think that's the solution as thinner lines are eaten by aliasing in VR (even with MSAA 4x) while thicker ones just shimmer on the contour and keep their readability. Make it optional, if you want to keep the new look for 2D (for me it looks great in 2D).

Edited January 24, 2023 by Hive

[ColinM9991]

Pinged BN on Discord. BN is unable to reproduce, though I don't know the test conditions and depth of testing. I did mention that everybody else here is seeing the issue beside him.

 

Will see how it goes. As mentioned before, it's disheartening to see a bug be introduced in a non-EA module, especially when said bug isn't given the time of day and is a big visibility issue for VR. Although I appreciate this is a low-priority issue given it doesn't affect the usability of the module.

Edited January 25, 2023 by ColinM9991

[IR.Clutch]

В 16.01.2023 в 13:02, ColinM9991 сказал:

Any updates?

Try to change resolution of the displays. If you set it to 512, it will update every second frame, I use 1024 every frame.

null

 

[ColinM9991]

1 minute ago, IR Sky said:

Try to change resolution of the displays. If you set it to 512, it will update every second frame, I use 1024 every frame.

null

 

 

I've personally tried this - not sure about anybody else, on both 2.7 & 2.8. This was one of the first things suggested in Discord back in October.

 

Unfortunately it doesn't solve the issue. The only working I've found, for now, is to bind VR Spyglass Zoom and use this when viewing the MFDs.

[IR.Clutch]

4 минуты назад, ColinM9991 сказал:

and use this when viewing the MFDs.

Do you have good eyesight? I ordered prescription lenses for Reverb G2  right away. I have -2 and there is no issues reading the MFDs

[ColinM9991]

8 minutes ago, IR Sky said:

Do you have good eyesight? I ordered prescription lenses for Reverb G2  right away. I have -2 and there is no issues reading the MFDs

I have prescription lenses mainly for my left eye. However, this issue simply isn't there in 2.7. It has only become a problem since 2.8. I run a fixed install of 2.7 where I can start the game up, hop in the A-10C II and notice a clear difference in the quality of the text. My eyesight can't fluctuate that wildly between two versions of the same game

 

Take these as an example. notice, in the 2.8 picture, how hard it is to see the decimal point on the left MFD next to OSB 8 (SLEW 5.0)? Now look at that same decimal point in the 2.7 picture.

2.7: https://forum.dcs.world/uploads/monthly_2022_10/2.7_4.jpg.1716526e94d50661473ca198de7f9550.jpg

2.8: https://forum.dcs.world/uploads/monthly_2022_10/2.8_4.jpg.0af7022994c0ed099a0d2c1acfdab6ec.jpg

Edited January 25, 2023 by ColinM9991

[IR.Clutch]

45 минут назад, ColinM9991 сказал:

Take these as an example. notice, in the 2.8 picture, how hard it is to see the decimal point on the left MFD next to OSB 8 (SLEW 5.0)? Now look at that same decimal point in the 2.7 picture.

Did you take screenshots in the same mission? Are all the conditions the same? I noticed that the F-16 had different MFD backlight levels in different OB versions, when starting airborne, etc. Would it become more readable if you increase the MFCD backlight brightness and symbology brightness?

null

null

Edited January 25, 2023 by IR Sky

[ColinM9991]

38 minutes ago, IR Sky said:

Did you take screenshots in the same mission? Are all the conditions the same? I noticed that the F-16 had different MFD backlight levels in different OB versions, when starting airborne, etc. Would it become more readable if you increase the MFCD backlight brightness and symbology brightness?

null

null

 

In terms of the mission, I created a test mission via the Editor that spawns you in an A-10C II at a fixed altitude. This was used for screenshots on both 2.7 & 2.8 back when this issue was originally introduced.

 

Also, it has just occurred to me that it's possibly worth me updating the main post to include a list of tried and tested steps.

So far, the following steps have been performed as an attempt to resolve the issue. None have yielded a successful result:

• Repairing the game
• Deleting the DCS directory from Saved Games, to start with a clean slate
• Deleting FXO and Metashaders (I perform this after every update, naturally)
• Tested on 2.7 and 2.8 with no graphical or setting changes, to demonstrate the issue being present only in 2.8 and onwards.
• Adjusted Resolution of Cockpit Displays to various values
• Adjusted brightness values as you've mentioned above. Several other users have provided their results in this thread too, the displays can't be returned to their original 2.7 brightness.
• Haven't changed any Nvidia Control Panel settings and I'm loath to do so as the A-10CII is the only aircraft with this issue. So I'm of the opinion that this isn't related to anything external of DCS, since none of that has changed.

[ColinM9991]

I ran BeyondCompare (a diff tool) on my 2.7 install and compared it to my 2.8 install and looked for differences in the A-10C_2 files between the two versions.

From the install folder, the following script was changed in 2.8 - DCSWorld\Mods\aircraft\A-10C_2\Cockpit\Scripts\MFCD\indicator\BAKE\page.lua

The change was to enable SRGB on the MFDs. I have commented on the lines that were added with 2.8. picture.input_space_SRGB is the culprit. Removing the line will resolve the problem. Why was SRGB set at the MFD base? In all other aircraft it is only set at a weapon or system level, such as TGP, SLAM, MAV, FLIR, PNVS and TADS. Although for the latter two it's commented out (disabled)

SetScale(1)

function addPicture(left)
	local verts 			 =	{{-1, 1},
								 { 1, 1},
								 { 1,-1},
								 {-1,-1}}
	local inds  			 = {0, 1, 2, 0, 2, 3}
	
	
	
	local hud_only_background			 = CreateElement "ceMeshPoly"
	hud_only_background.material		 = MakeMaterial("",{0,0,0,255})
	hud_only_background.vertices		 = verts
	hud_only_background.indices			 = inds
	hud_only_background.additive_alpha   = false
	hud_only_background.controllers 	 = {{"render_purpose",1,2,3}}
	Add(hud_only_background)
	
	
	
	local picture			 = CreateElement "ceTexPoly"
	picture.material		 = MakeMaterial("ccMFCD_Bake_SRC",{255,255,255,255})
	picture.vertices		 = verts
	picture.indices			 = inds
	picture.input_space_SRGB = true -- Added in 2.8, remove to fix the issue
	picture.additive_alpha   = true
	if left then
		picture.tex_coords	 = {{0, 0},{0.5, 0},{0.5,1},{0,   1}}
	else
		picture.tex_coords	 = {{0.5, 0},{1, 0},{1,1}  ,{0.5, 1}}
	end
	picture.controllers  	 = {{"display_backlight"}, --[[Added with 2.8, doesn't contribute to the issue--]] {"render_purpose",0}}
	Add(picture)
	
	--[[
		picture2 variable and logic added with 2.8. Does not contribute to the issue.
                Removing this has no noticeable difference. Is it serving a purpose?
	--]]
	local picture2		 		    = Copy(picture)
		  picture2.controllers      = {{"display_backlight"}}
		  picture2.parent_element   = hud_only_background.name
		  picture2.input_space_SRGB = false
	Add(picture2)
end

If this isn't enough evidence that the issue was introduced with 2.8 then I have absolutely no idea where to go next with this bug report. Furthermore, if this issue isn't going to be fixed then at least don't make it any worse. At the very least I'd like to be able to use OvGME to fix this myself by patching over this file.

 

Before and After pictures.

Edited January 25, 2023 by ColinM9991

[ColinM9991]

@BIGNEWYApologies for pinging you directly. Please see my message above. It should contain all you need to see that this is an issue with A-10C_2\Cockpit\Scripts\MFCD\indicator\BAKE\page.lua

[BIGNEWY]

I will mention it to the team in the morning 

thanks

[Hive]

Wow, awesome find. Thanks ColinM9991. Please receive my "hero of the day" award! Looking forward to test it.

And thanks BIGNEWY for mentioning it to the devs. 

[Vakarian]

Am I the only one who thinks that current A-10 MFDs look more realistic, as in more like a screen now? Previously all the text was too sharp, too "good" IMO and I kinda prefer how it looks now.

[ColinM9991]

22 minutes ago, Vakarian said:

Am I the only one who thinks that current A-10 MFDs look more realistic, as in more like a screen now? Previously all the text was too sharp, too "good" IMO and I kinda prefer how it looks now.

That's all at the risk of making it harder to see certain phrases, characters, symbols and so on. Especially in VR.

As this wasn't mentioned in the changelogs and there has been no explanation so far, it looks more like an unexpected change.

 

To my point above, the A-10C and A-10C_II modules have both had SRGB applied to the MFCDs in their entirety which has caused a degradation in visibility. No other module does this. Why has this been applied at an MFCD level rather than a weapon or sensor specific level, such as TGP or MAV pages? This is how it's done on all other modules so that, when you choose a specific page like TGP, the SRGB space is applied then. You can see this for yourself by searching for input_space_SRGB in Installation - Mods - Aircraft directory, specify a file filter for *.lua.

Edited January 26, 2023 by ColinM9991

[Vakarian]

Oh, don't get me wrong. I do understand how this can be perceived as issue, I was using VR couple of years ago and MFD readability was always the thing I've struggled with.

I'm just stating that it looks more real to me now than before. Does that make it harder to read, yes, I can see how that can be a thing, especially for VR users. Maybe it could be made a special option?

As to why it's applied at MFD level, well that makes more sense to me. You have an MFD, set how thing are going to be rendered on it and then all underlying pages use same exact settings. That makes it much easier to maintain (speaking from programming point of view).

[ColinM9991]

9 minutes ago, Vakarian said:

As to why it's applied at MFD level, well that makes more sense to me. You have an MFD, set how thing are going to be rendered on it and then all underlying pages use same exact settings. That makes it much easier to maintain (speaking from programming point of view).

 From that perspective I agree. Using the former approach, whereby SRGB is assigned on a page by page basis, is simply an inheritance chain which can become cumbersome to maintain. The only caveat is it's now inconsistent with the approach that all other modules are taking with regards to SRGB. It also isn't just affecting the video on the page, which wouldn't be as much of a problem as we can see in other modules, such as the MAV page in the F-16 where all text is perfectly readable without extra zoom.

I did also consider a special option. I could even implement one myself as a proof of concept where a variable could be read from autoexec.cfg. It depends on the use case for SRGB though and why it is that ED want it enabled for this particular module over every other.

 

The only reason I could possibly think of is the ARC-210 radio and whether that also inherits properties from MFCD\indicator\BAKE\page.lua. Otherwise all that we can do, at this point, is to wait and see what ED say about the change and why it's necessary.

As mentioned previously, I now know what the issue is so I can just patch it out myself using OvGME, if the final decision is that it will remain as it currently is.

Edited January 26, 2023 by ColinM9991

[ColinM9991]

One more thought, excuse the spam, is that it could be related to these bug reports, since this affects both the A-10C and A-10C_II modules as they share files in a lot of areas.

 

 

Edited January 26, 2023 by ColinM9991

[ColinM9991]

I asked BN in Discord whether  there had been any updates in relation to this issue. Rather frustratingly, there are no updates and the dev team haven't been asked as to why the input_space_SRGB line of code was added to the page.lua file, as I mention above.

As I figured when I first raised this issue, I think it's just going to be a manual fix for the years to come. For anybody interested I have attached an OvGME compatible repository to patch over the LUA file thus disabling SRGB.

MFCD_Fix.zip

[Hive]

Sad to hear that, but thank you very, very much for all your effort.

I switched back to pancake and I will stay there for the moment as the VR performance got too bad anyways. It is ok for me as DCS really looks awesome in 4k with maxed details and it is more comfortable, too.

[ColinM9991]

Issue and line of code are still present in the latest patch, still no official statement from ED as to whether this is an intentional change that remains to be undocumented in the changelogs.

Edited March 10, 2023 by ColinM9991

[ColinM9991]

Still there in 2.8.3.37854.1, and so the cycle continues.

[SPAS79]

Posting as i will need to retrieve and fix. I was going mad in VR with the flimsy mfcd text.

[ColinM9991]

On 3/23/2023 at 9:56 PM, SPAS79 said:

Posting as i will need to retrieve and fix. I was going mad in VR with the flimsy mfcd text.

If you use OvGME, this should make it a bit easier to patch