[SOLVED]Build from source, unexpected rendering issue

1

I need to make some changes to source, so I decided I will finally build monogame from source. I made some minor changes to draw string. Now once I used my MonoGame.Framework.dll I’ve encountered unexpected issue that will be better to show with image.

Original:

This seems to affect only some render targets, what is even more confusing is the way how it is affecting them. This are definitely not just swapped color channels, difference is much more drastic. Has anyone encountered something like this?

Edit: at this point I know it is somehow related to Render Target surfaces as well as to my Gauss blur shader.

Edit2: It boils down to this difference:

This is post gauss blur pass, input is same

Edit3: Here is where it falls apart

SCREEN_MANAGER.Device.SetRenderTarget(lightRTa);
batch.Begin(SpriteSortMode.Immediate, BlendState.AlphaBlend, SamplerState.LinearClamp, null, null); //
batch.Draw(lightRT, new Rectangle(0, 0, lightRTa.Width, lightRTa.Height), Color.White);
batch.End();

if I use .Opaque then both results are same, on Alpha Blend behavior is vastly different, thing is I need that alpha channel.

Solved altho I am still confused, it seems like clear color after reusing RT is for whatever reason #442288 while prebuild framework dll clears to black.

Post solved edit: I am now 100% sure that reusing render target that discard content results in #442288 while prebuild monogame “clears” to #000000

Final edit: /Facepalm
#if DEBUG
private static readonly Color DiscardColor = new Color(68, 34, 136, 255);
#else
private static readonly Color DiscardColor = new Color(0, 0, 0, 255);
#endif

1 Like
2

Woops! Good that you figured it out! Still a nice read :stuck_out_tongue: What was the purpose of the code that caused the issue originally if I may ask?

3

You will have to elaborate on that question. If you mean code that I “quote” in the end, that’s the code from Monogame source I wasn’t aware of (the fact that monogame clears discarded content to black only if build for release, otherwise it clears to purple).

According to comment around that section they had compatibility issue when clearing to Purple (which is what XNA used to do) so they left this color only when compiling as debug. Over the years I simply got used to Monogame always clearing to black when discarding and I absolutely didn’t expect that build to release/debug provides different results as far as color goes.

4

Oh wow, I didn’t get that this was MG code. I thought it was yours. Looking through comments of the PR that made this changed, the rationale is that clearing to purple makes bugs easier to spot, but some Intel graphics cards can clear to all zeroes or all ones faster than an arbitrary color.
Tom also mentioned you shouldn’t really depend on the default clear color.

5

I am sure that I read somewhere “don’t clear if you don’t have to” - meaning when RT is discarding content… so kinda getting mixed messages on that one. Personally I think clear is so fast on modern HW that it hardly matters but hey (I gave up on trying to support integrated intel cards, it’s world of hurt and atm game is imho not that simply to justify it).

Also, hmm… it isn’t clearing to all zeros but to black, between new Color(0, 0, 0, 255) and new Color(0, 0, 0, 0) is quite a bit of difference, which reminds me Color.TransparentBlack doesn’t work as intended, had to make my own definition for it long time ago. (just mentioning to check if Intel really clears faster to black or transparent black).

6

The comment actually said all channels either 0 or 255, so I assume it means they don’t all have to be the same value. Maybe MG should clear to (255, 255, 0, 255). That way we get the alleged performance boost (if I understood correctly), but you still get a special color rather than black.

7

I don’t know, I personally prefer clear to black on discard. I find clearing to black/transparent black to be most common and it seems to me like it would artifically force double clearing in lot of cases, on the other hand, since I am already building from source I am not against that idea.

8

I would also prefer a clear to black by default.

If it’s guaranteed and consistent between debug and release, it should be fine to depend on it, right?

Clearing to 255, 255, 0, 255 for debug and release would be the 2nd best option in my opinion.
Having different behavior between debug and release builds seems like a bad idea to me.

1 Like
9

If i remember right i think i once heard that black does clear faster.
Something about because gpu’s use a hardware trick to do it via cycling the refresh on a block of memory basically some sort of power trick. But that really shouldn’t make a bit of difference gpu’s have buffers they just flip a switch and clear the old one in the background.