Skip to content

[develop3d][Android] Screen being filled by purple color #838

Closed
juli1 opened this Issue Oct 3, 2012 · 11 comments

6 participants

@juli1
juli1 commented Oct 3, 2012

Dear all,

I am facing a strange issue when developping an Application with Android and the develop3d branch of MonoGame. When launching my game, everything is draw correctly. But after a while, big parts of the screen are being filled by a purple color and thus, the rest of the screen is not correctly displayed.

It happens only on the develop3d version of Monogame, I do not experience such issues with the 2.5 revision. Moreover, I do not know if this is a bug related to the emulator itself, monodroid or monogame. As it happens only with the develop3d version of MonoGame (and not the 2.5), I am likely to think this is because of monogame but any thought about that would be welcome.

Thanks for any help,

Best,

Picture of the game when starting : http://tof.canardpc.com/view/e4d80412-f358-4808-88cd-9f367747be31.jpg
Picture of the game after starting : http://tof.canardpc.com/view/030f62ad-6789-4e39-a338-0ade45f51e50.jpg

@Nezz
Nezz commented Oct 7, 2012

We had a similar issue with rendertarget on windows phone. Do you draw the background from a rendertarget? What color are you using in graphicsdevice.clear()?

@tomspilman
Mono Project member

MonoGame mimics the behavior of XNA... unless a RenderTarget is set created with "preserve content" it is cleared with purple when you switch to it. This keeps you from doing things that are incompatible with Xbox/WP7.

@juli1
juli1 commented Oct 9, 2012

Hi,

I do use a render target. On the other hand, with the latest of monogame, the behavior is different. Now, the screen is still rendering a bad background color but is full of black (the color I used to clear the screen). However, the weird thing is that some sprites are correctly displayed while some other are not. See the following pictures: in the level selection, the frame is correctly displayed while the background is not (the black color). On the other hand, in the game itself, the frame is not displayed and more than half of the screen is black.

The same code works correctly on other targets (Windows, Linux, etc ...). So, I am wondering if this is a monogame issue or if this could also be a problem related to the emulator of monodroid ?

Pictures:
Level selection: http://tof.canardpc.com/show/c191a644-334c-4124-ac34-441fdb57f6f3.html
Level selection with one level selected (clouds are then displayed): http://tof.canardpc.com/show/06ece21f-abe6-4fd5-9404-60b1e5eeae9a.html
In game screenshot : http://tof.canardpc.com/show/dd28b5dc-f036-49f6-86e3-423b8f852b9f.html

@dellis1972
@juli1
juli1 commented Oct 9, 2012

Also, I see the heap growing. Is it possible that it leads to a rendering error/problem ? (basically, the heap is used for storing rendering things, etc...) ? I attached the output below.

As for now, for the emulator, I used the API15 with GPU, so, it shall render everything in order.

Greetings,

Grow heap (frag case) to 6.807MB for 262160-byte allocation
Grow heap (frag case) to 7.103MB for 309688-byte allocation
Grow heap (frag case) to 7.148MB for 309688-byte allocation
Grow heap (frag case) to 7.353MB for 524304-byte allocation
Grow heap (frag case) to 8.323MB for 1016616-byte allocation
Grow heap (frag case) to 8.792MB for 1016616-byte allocation
Grow heap (frag case) to 8.824MB for 1048592-byte allocation
Grow heap (frag case) to 10.225MB for 1470176-byte allocation
Grow heap (frag case) to 10.627MB for 1470176-byte allocation
Grow heap (frag case) to 10.226MB for 1048592-byte allocation
Grow heap (frag case) to 12.118MB for 1983168-byte allocation
Grow heap (frag case) to 13.009MB for 1983168-byte allocation
Grow heap (frag case) to 14.356MB for 2346016-byte allocation
Grow heap (frag case) to 15.593MB for 2346016-byte allocation
Grow heap (frag case) to 9.351MB for 2936848-byte allocation
Grow heap (frag case) to 12.089MB for 2936848-byte allocation
Grow heap (frag case) to 7.820MB for 524304-byte allocation
Grow heap (frag case) to 19.818MB for 12582928-byte allocation
Grow heap (frag case) to 31.319MB for 12582928-byte allocation
before base init
GraphicsDeviceManager.ResetClientBounds: newClientBounds={X:0 Y:0 Width:480 Height:320}
end init

@juli1
juli1 commented Oct 9, 2012

Hello,

More investigation about that. In fact, it happens only when using different functions for drawing with an OnDrawTop and OnDrawBottom. If I use only one draw method, the problem does not appear if I use one single method for drawing.

@totallyevil

FWIW. i see the "purple" screen sometimes in one of our games when going from portrait to landscape and the landscape bounds are not the entire screen, so there is a 12 pixel buffer space that shows the previous framebuffer contents, which sometimes is the purple screen and other times it's part of the last screen image. I think this happens when we do a .Clear(color) on the screen but the screen dimensions (the viewport) are not correct (12 pixels - inset by 6 on both sides). Not sure yet. I posted an issue related to this ...

@totallyevil

This issue looks like a possible inconsistent implementation of the RenderTargetUsage.PlatformContents setting for render targets. Maybe there is one case where it is using PreserveContents logic (where I see the prior frame appears in the border), and then another that uses DiscardContents logic (where we see the purple in the screen).

@juli1
juli1 commented Oct 12, 2012
@totallyevil

@juli1 do you still see this issue? I no longer see this problem in our games when switching orientations.

@danzel
danzel commented Apr 23, 2014

Sounds like this has been fixed, otherwise dead bug. Close please @tomspilman

@tomspilman tomspilman closed this Apr 23, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.