Is this being run in a VM? If not, what is the graphics card running this? The bug is as it says on the top line: the FBO is incomplete. If your GPU doesn't support ARB_framebuffer_object, you won't have much luck with MonoGame in general.

from fna-mghistory.

Is this being run in a VM?

No. It's being run natively. It does work when running in a VirtualBox VM using 3D accelleration if I recompile it using XNA and VS.

I'm testing on a Clevo P150EM which has both Intel HD4000 and Nvidia 670MX graphics. When running with the Intel graphics, I get the InvalidFrameBufferOperation. I wouldn't have expected any problems with such a simple app, since things like FEZ run fine with the HD4000 (and will switch modes fine).

When running with the NVIDIA 670MX graphics (via bumblebee & primusrun), I don't see an error and the program doesn't abort (or seem to throw any console errors) - but it still fails to render the sprites after the mode change.

from fna-mghistory.

Going to need a sample application then. Can't debug based on the trace, since it currently sounds like a GL driver issue at first glance.

from fna-mghistory.

No worries. I'll work up a minimal test case and post back here shortly.

from fna-mghistory.

Okay! I've put a test project up at: http://www.eternaldusk.com/jl-misc/toggletest.tar.gz

The only code added from the MonoGame template is in Game1.cs. Pressing the F key switches modes (and waits 5 seconds before re-enabling Draw), Esc exits.

When I run this on the Intel HD4000 graphics, the character texture renders as a black square once I switch from full screen to windowed mode.

When I run this on the Nvidia graphics, the texture appears invisible once I switch to windowed mode. Either it's not actually being rendered, or it is defaulting to cornflower blue. The program continues to run, either way.

If you disable the delay on switching modes, you will see the original GL error I reported, when Draw is called immediately after the mode switch.

As a XNA/MonoGame newb, I thought maybe the texture was just being freed/invalidated when switching modes (though I didn't see this documented as expected behavior). So, I tried adding a call to LoadContent to reset spritebatch and reload the texture immediately after switching modes, but it did not change the symptoms. I also tried a call to LoadContent after the 5 second delay... but that also produced no change.

Below are details of the build environment. It's basically a completely up to date Ubuntu 14.04 pre-alpha, with Mono, MonoDevelop, and MonoGame-SDL2 all built from the current gits.

=== MonoDevelop ===

Version 4.2
Installation UUID: 02bab466-edd5-482d-8573-285b6dbb1f5c
Runtime:
Mono 3.2.7 (master/0737529 Sun Dec 1 06:34:18 CST 2013) (64-bit)
GTK+ 2.24.22 theme: Zukitwo
GTK# (2.12.0.0)

=== Build Information ===

Git revision: 97401a1725f99e140c0242f75407fc9195cc55ec
Build date: 2013-12-01 12:44:10+0000

=== Operating System ===

Linux
Linux clevo 3.12.0-4-generic #12-Ubuntu SMP Tue Nov 26 22:38:40 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I really appreciate you taking the time to look into this, and telling me if I'm hitting a bug... or if I'm just off my rocker and doing something in completely the wrong manner. I'm really puzzled as to why I'm seeing this with such a simple test case whereas other things like your FEZ port work great on the same system (under either graphics chipset).

from fna-mghistory.

Should be fixed now:

3165947

Generally we assume that the Texture/Sampler collections don't clean up after themselves, but if you manage to never trip over that GL code, the SDL2 window's window resize would stomp over the currently bound texture.

Good catch on that!

from fna-mghistory.

Wow! You certainly don't waste time when identifying and fixing the bugs. One day, I'll manage to find a bug that takes you more than an hour to figure out. Until then, keep up the great work!

from fna-mghistory.