Difficulty: This task contains many individual subtasks that vary in difficulty, ranging from EASY to HARD. Pick any task you want, based on what you think you can do correctly in a short period of time.

Believe it or not, this project doesn't really do a good job of keeping track of what's actually a part of the XNA spec and what's just made-up crap someone did while hacking their XNA port together. And boy-o, there's a lot of that in here.

Here's a test program you can use to compare the XNA4 assemblies with the FNA assembly:

https://github.com/flibitijibibo/XNA4SpecTest

Additionally, here are the MSDN docs, just in case you want something more official to verify with:

http://msdn.microsoft.com/en-us/library/bb203940.aspx

We need to start keeping better track of this. In the long run we need to reproduce the XMLDoc for the public API, but for now, let's just worry about the accuracy of the API itself. This consists of the following tasks:

• Ensuring that the class/struct and its members are accurately declared
• Ensuring that the public members of the class/struct are meant to be public, or are even supposed to exist
• Restricting the accessibility of anything that does not fit in bullet 2, or marking them as extensions

Here is the current list of XNA4 mismatches, according to the XNA4SpecTest:

http://flibitijibibo.com/fna/SpecMismatches.txt

The Utilities/ folder is the only folder that is NOT to be touched. This is because we need to keep MonoGame compatibility for these files in particular.

If you decide to take a mismatch, please post here and let us know you're working on it. Because we're doing so much work on so much code, we need to be sure we're not conflicting with other branches.

I am trying to set pixel data to a Texture2D from a thread other than the main thread, its just that nothing seems to be set...

Some code of what I am trying to do:

            loadingMessage = "Calculating colors and rendering map...";
            result = new Texture2D(engine.GraphicsDevice, tileCountX, tileCountY);
            colors = new Color[tileCountX * tileCountY];
            for (int y = 0; y < tileCountY; y++)
            {
                for (int x = 0; x < tileCountX; x++)
                {
                    if (Tile.tileColor[tile[x, y].type] == Color.White)
                    {
                        if (Tile.wallColor[tile[x, y].typeWall] == Color.White)
                        {
                            if (tile[x, y].liquid > 0)
                            {
                                if (tile[x, y].typeLiquid == Tile.LIQUID_WATER)
                                {
                                    colors[tileCountX * y + x] = Color.Blue;
                                }
                                else if (tile[x, y].typeLiquid == Tile.LIQUID_LAVA)
                                {
                                    colors[tileCountX * y + x] = Color.Lavender;
                                }
                                else
                                {
                                    colors[tileCountX * y + x] = Color.White;
                                }
                            }
                        }
                        else
                        {
                            colors[tileCountX * y + x] = Tile.tileColor[tile[x, y].typeWall];
                        }
                    }
                    else
                    {
                        colors[tileCountX * y + x] = Tile.tileColor[tile[x, y].type];
                    }
                }
                loadingPercentage = 0.5f + 0.5f * (y / (float)tileCountY);
                if (engine.worldViewer == null)
                {
                    return;
                }
            }
            result.SetData<Color>(colors, 0, colors.Length);
            state = State.Done;

I did post this issue on the official MonoGame repository but I am unsure to whom this issue is related to (OpenGL on MonoGameSDL is still being used just like MonoGame's WinGL platform right?)

I also tried setting the data on a main thread but sadly that still did not work. All I get is black pixels (0,0,0,0 color data) aswell.

Any ideas?

One of the nastier things I've got in MG-SDL2 right now is the use of a thread to manage the audio stream. It's not as bad as when I had yet another thread for video frame management, but it's still a pretty obnoxious thread. That, and it's highly unportable.

I recently scribbled out something that essentially does the same thing, but without the need for a thread: the DynamicSoundEffectInstance implementation:

https://github.com/flibitijibibo/MonoGame/blob/monogame-sdl2/MonoGame.Framework/Audio/DynamicSoundEffectInstance.cs

This hasn't actually been tested yet, but it's at least a start if it doesn't Just Work.

Basically we just need to get rid of the thread and replace it with this, using the Event to pull in more audio frames from TheoraPlay. I trust that this will not affect perf (it might even improve perf on Mono, honestly), and it will make the VideoPlayer much more portable.

This task is tough though, because the VideoPlayer is kind of a house of cards when it comes to XNA4 accuracy. To see what I'm talking about, go look at GetTexture():

https://github.com/flibitijibibo/MonoGame/blob/monogame-sdl2/MonoGame.Framework/SDL2/Media/VideoPlayer.cs#L499

Yeah. Seriously.

Here is a list of games you should look at to test accuracy:

• Capsized (look at the opening video's alarm, see if the audio syncs)
• A Virus Named TOM (look at the sidewalk video's ending, the last frame it holds on should be black)
• Dust: An Elysian Tail (looping videos, very resource intensive, good for testing perf/leaks too)

If your MonoGame.Framework.dll doesn't work against the game, let me know and I can rebuild it fresh against upstream MG-SDL2 for you.

All I am doing is the usual loading of textures through ContentManager, no Texture2D.FromFile etc.

Microsoft.Xna.Framework.Graphics.MonoGameGLException was unhandled
HResult=-2146233088
Message=GL.GetError() returned InvalidOperation
Source=MonoGame.Framework
StackTrace:
at Microsoft.Xna.Framework.Graphics.GraphicsExtensions.CheckGLError() in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Graphics\GraphicsExtensions.cs:line 725
at Microsoft.Xna.Framework.Graphics.Texture.b__6() in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Graphics\Texture.cs:line 183
at Microsoft.Xna.Framework.Graphics.GraphicsDevice.AddDisposeAction(Action disposeAction) in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Graphics\GraphicsDevice.cs:line 1372
at Microsoft.Xna.Framework.Graphics.Texture.Dispose(Boolean disposing) in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Graphics\Texture.cs:line 180
at Microsoft.Xna.Framework.Graphics.GraphicsResource.Dispose() in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Graphics\GraphicsResource.cs:line 125
at Microsoft.Xna.Framework.Content.ContentManager.Unload() in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Content\ContentManager.cs:line 645
at Microsoft.Xna.Framework.Content.ContentManager.Dispose(Boolean disposing) in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Content\ContentManager.cs:line 183
at Microsoft.Xna.Framework.Content.ContentManager.Dispose() in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Content\ContentManager.cs:line 169
at Microsoft.Xna.Framework.Game.Dispose(Boolean disposing) in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Game.cs:line 210
at Microsoft.Xna.Framework.Game.Dispose() in c:\Users\Xanather\Documents\Programming\Libs\MonoGame\MonoGame.Framework\Game.cs:line 190
at hidden.Program.Main() in c:\Users\Xanather\Documents\Programming\Main\hidden\hidden\Program.cs:line 24
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

Hey again, small issue but hopefully not doing anything wrong here but my window icon isn't being set.
Specifically the larger icon gets set i.e on the taskbar;
http://i.imgur.com/ReKskv5.png

But in the actual main window, all i get is;
http://i.imgur.com/X9peP2K.png

I've set the icon in monogame solution settings underneath general. I think thats the correct way to-do it? In the general tab.
Just to test i just made a dummy openGL monogame project and added in my icon and the icon appeared just fine in both the taskbar and the window.

When closing my game I receive:

A callback was made on a garbage collected delegate of type 'SDL2#!SDL2.SDL_mixer+MusicFinishedDelegate::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.

Ok so I recently just redowloaded the repo and the memory leaking error is back:

A callback was made on a garbage collected delegate of type 'SDL2#!SDL2.SDL_mixer+MusicFinishedDelegate::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.

When I was testing the MediaPlayer changes before I had my SDL_GamePlatform Exit method as follows.

    public override void Exit()
    {
        // Stop the game loop
        INTERNAL_window.INTERNAL_StopLoop();

        // End the network subsystem
        Net.NetworkSession.Exit();

        // Stop the Media Player
        Media.MediaPlayer.Stop();

        // Close SDL2_mixer
        SDL_mixer.Mix_CloseAudio();
    }

If the Media.MediaPlayer.Stop(); is not there in the Exit (like it is now) method I receive the "passing delegate" error when calling Game.Exit() just like before. Ill think submit a PR for that in a moment.

I also submitted this issue for two other reasons as well.

When terminating the process through visual studio I get the same "passing delegate" message, how can a process termination result in a error/warning?

Finally (another MediaPlayer issue hehe), when a playing song sucessfully ends I get a untraceable NullReferenceException.

In porting Shipwreck over to FNA I've found that Bgr565 targets aren't drawing correctly, at least when scaled up with point sampling. Here's what it looks like:

And the same screen if I change to the Color format:

You can see the Bgr565 surface getting lots of incorrect pixels in there. Thankfully for my game I can simply switch to Color and it works just fine for my game (I think I used Bgr565 due to in-game screenshots which I've disabled now anyway), but this might be worth looking at.

I picked up a project I haven't touched in a few weeks and found that some recent changes seem to have broken the behavior of my resizable window.

Basically, the result that I'm seeing are that the texture I'm drawing is being affected 2x what it should be when the window is resized.

I don't do any scaling in my demo itself;. I simply draw everything to a RenderTarget2D at a fixed size. Then, in a separate SpriteBatch, I draw that RenderTarget to the client window:

            spriteBatch.Begin(
                SpriteSortMode.Deferred,
                BlendState.Opaque, 
                SamplerState.PointClamp,
                DepthStencilState.None,
                RasterizerState.CullNone
            );
            Rectangle screenRectangle = new Rectangle(
                0,
                0,
                this.Window.ClientBounds.Width,
                this.Window.ClientBounds.Height
            );
            spriteBatch.Draw(
                renderTarget,
                screenRectangle,
                Color.White
            );
            spriteBatch.End();

Previously, this was working and the rendertarget always filled my client window. But now...

Window before resizing:

Window when resized to half-width.

Window sized to Half-width, half-height

I've debugged this as far as getting to SpriteBatchItem.Set... and all for the source and destination look correct at that point. Is this something you might recognize off the top of your head before I spend time going deeper this weekend? I noticed you doing a lot of resizing in the Vine you posted on twitter yesterday. )

This isn't a huge deal, but my game uses the PacketNumber to detect that the gamepad input has changed. I use this to know what the last input from the user was (I check keys to see if they've changed and PacketNumber for gamepads). FNA doesn't appear to ever set this value so my game always thinks it's using keyboard input (the default until we see the PacketNumber property change).

It's pretty trivial in my use case to just compare the current and previous game pad states manually, but wanted to file the issue in case anyone thinks it's worth looking into.

Hi again,
Not sure on the relevance of these issues but there are a few issues relating to the PSM build. 2 sections of code in particularly are the course of these issues,

sounds[current_entry] = new SoundEffectInstance(audiodata, rate, chans);

Used in two places, the error message itself is present when close to nearby platform defines;
"Audio\WaveBank.cs(30,30): Error CS1729: 'Microsoft.Xna.Framework.Audio.SoundEffectInstance' does not contain a constructor that takes 3 arguments (CS1729) (MonoGame.Framework.PSMobile)"

The second code section to cause errors;
internal void GenerateMipmaps()
{
Threading.BlockOnUIThread(() =>
{
var prevTexture = GraphicsExtensions.GetBoundTexture2D();
GL.BindTexture(TextureTarget.Texture2D, this.glTexture);
GL.GenerateMipmap(GenerateMipmapTarget.Texture2D);
GL.BindTexture(TextureTarget.Texture2D, prevTexture);
});
}

Image attached showing the errors for this.

I should note, testing this with the latest Monogame-develop branch, the code runs fine. (Right now i just have a dummy app which clears the screen black).

Before we make a final pull request to add MonoGame.Framework.SDL2 to the official MonoGame repository, we need to merge as many of the additional changes in MG-SDL2 as possible. This issue tracks those changes, what problems they currently have, and pull request links when they are submitted.

I encourage everyone to make pull requests to this repository to address any issues in this list. XNA4 compliance is the big issue for most of these, so if you're very familiar with XNA4, you will be very helpful here.

Here is the current diff between MonoGame-SDL2 and upstream MonoGame:

https://github.com/flibitijibibo/MonoGame/compare#files_bucket

Let's shrink this a bit, shall we?

_Merged_

• The XACT implementation makes a bad assumption about the IsPlaying property. MERGED: MonoGame@ac64149
• SoundEffectInstance.cs and OALSoundBuffer.cs carry the audio data after loading it into OpenAL for some reason? I removed those variables and drastically reduced the memory use by the MonoGame audio engine. MERGED: MonoGame@8368d64
• SoundEffectReader.cs, SoundEffect.cs and WaveBank.cs have a similar problem. We load the wavedata, create a fake wav file out of that, then parse the fake wav file. It doesn't carry the audio everywhere, but it's a lot of work for nothing. Took it out, seems a bit faster, but I've not actually measured it. MERGED: MonoGame@8368d64
• WindowsGL/Linux shared pretty much all of the same Audio code, but it was in separate folders for reasons unknown. I have since merged it into Audio/SoundEffect.cs and SDL2/Audio/AudioLoader.cs. MERGED: MonoGame@5e1378d
• Graphics/Texture2D.cs introduced a bug in GetData when rect is null. I fixed that. MERGED: MonoGame@1c5bea5
• Graphics/GraphicsDevice.cs adds an "Adapter" property. MERGED: MonoGame@67eea9a
• Content/ContentReaders/SoundEffectReader.cs has MSADPCM support. This should probably be pulled, with the same platform conditions as the WaveBank MSADPCM support. MERGED: MonoGame@1cd5e68
• Graphics/DisplayMode.cs includes a bugfix for comparing null DisplayModes. This should probably be pulled for XNA4 compliance. MERGED: MonoGame@0193186
• Media/MediaPlayer.cs adds ActiveSongChanged. This can be pulled if the parameters make sense. MERGED: MonoGame@56d5e3c

_Submitted to MonoGame Upstream_

• Nothing at the moment.

_To Be Reviewed: XNA4 Compliance_

• Game.cs has a FIXME related to how we initialize the game with predefined GraphicsDeviceManager preferences... I think there have been a number of bug reports related to this in upstream, this fixes it for us on MG-SDL2. Perhaps this should be pulled?
• GraphicsDeviceManager.cs has a ToggleFullscreen FIXME that I actually wanted to ask about... I thought this immediately toggled fullscreen, am I wrong on this?

_To Be Reviewed: MonoGame-specific Issues_

• Content/ContentReaders/Texture2DReader.cs and Graphics/Texture2D.cs add a GenerateMipMaps() call for S3TC textures. Somewhat related to MonoGame#1783. It's a crap solution though, I'd like something better if it's available.
• Graphics/GraphicsExtensions.cs has a tiiiny tweak for DXT1 in GetGLFormat(). I have a couple games that fail when we assume RGB rather than RGBA; maybe this works with the MG content pipeline, but apparently not XNA4?

_Not A Big Deal, Ignore For Now_

• XACT support. Basically, everything in the Audio/ folder can be ignored. While it works for all of my titles, there were a few nasty premature generalizations I made early on, and it might not be worth pulling unless the core team is okay with something that at least works a little, and leave the more advanced features to someone else.
• SoundEffect/SoundEffectInstance/OpenALSoundController changes. Again, this is a part of my audio rewrite.
• Working on instanced drawing for OpenGL. Ignore those bits (Particularly in GraphicsDevice.cs).

_Ignore for Main MG-SDL2 Pull_

• I copied the Desktop/Audio/ and Linux/Audio/ contents and merged them into SDL2/Audio/. This is to clearly indicate use of these files for all SDL2 platforms, and was part of my goal to eliminate the 'Desktop/' folder. You'll notice that a couple Desktop/Audio/ files have some diffs in them; this is so I can easily merge back into SDL2/Audio/ from develop if someone modifies these files.
• All of the diffs that trash (WINDOWS && OPENGL), MONOMAC and LINUX. We will deal with this once SDL2 is an official platform.

_This Diff Sucks_

• Graphics/GraphicsResource.cs is what happens then the garbage collector starts locking up my game 10 minutes into runtime and I don't have any tables to flip.

Updates to this list will be posted here. If you want to take on an issue or can address any concerns listed, feel free to post them here as well.

Is a TextInput implementation possible on MonoGameSDL2? I was the one to originally introduce the feature on some MonoGame platforms. It is a much needed feature for any game that has extensive UI. I plan to continue my game development on MonoGameSDL2 but the only thing stopping me is not having TextInput.

It is based off http://msdn.microsoft.com/en-us/library/system.windows.forms.control.keypress.aspx using the KeyChar value that is returned from that event.

Since the XACT updates, overlapping PlayCues for the same sound are playing correctly on Linux (Ubuntu 13.10beta with default PulseAudio setup). However, after several minutes all Cues stop playing completely with the aforementioned error:

WARNING: AL SOURCE WAS NOT AVAILABLE. SKIPPING.

I was mistaken, NullReferenceException is back when the song ends, however it only happens when I load the game's world/starts processing/possible garbage collections occur. I either get:

A callback was made on a garbage collected delegate of type 'SDL2#!SDL2.SDL_mixer+MusicFinishedDelegate::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.

or a out of source NullReferenceException.

What it seems like is that the GC is cleaning up something to do with the SDL mediaplayer/loaded song which breaks something.

Any ideas? Sadly it seems like this is the exact same error as a month ago and it occurred on two different machines.

My game's code touches nothing to do with the garbage collector except for some explicit GC.Collect() calls.

I noticed you have been working on an XAct rewrite. I figured out a few things on clip events that you may find useful...

var eventInfo = clipReader.ReadUInt32();
var randomOffset = clipReader.ReadUInt16() * 0.001f;

// TODO: eventInfo still has 11 bits that are unknown!
var eventId = eventInfo & 0x1F;
var timeStamp = ((eventInfo >> 5) & 0xFFFF) * 0.001f;
var unknown = eventInfo >> (16 + 5);

The timestamp and random offset are in seconds and are part of the base event type all other events derive from.

Also some other event ids...

• 0 = Stop Event
• 7 = Pitch Event
• 8 = Volume Event
• 9 = Marker Event

In GraphicsDeviceManager.cs there is the following code:

// It's bad practice to start fullscreen.
presentationParameters.IsFullScreen = false;

Yet, our game always starts fullscreen (which it didn't on regular Monogame or in XNA). We also have code which calls ToggleFullScreen() and that just causes the screen to flicker (but stays fullscreen), so perhaps that's a hint of what's wrong?

Difficulty: This is considered an EASY task. If you're just looking to kill some time, this is the task for you.

In FNA, we will be strictly using LF newlines and keeping an ASCII format. On Fedora 20, file reports the file as "ASCII text", and OSX Mavericks reports the file as "ASCII c program text". If the file is reported as anything else, THIS IS A BUG!

Most of the time this is just a matter of re-saving the file with Unix newlines. I've just been doing this with gedit. But, sometimes you get some weird characters in the file that make it report as "UTF-8 Unicode text". There are two explanations for this:

1. A symbol like the (C) copyright symbol in the license header. Just take these out.
2. A weird character starting the file (typically <U+FEFF>). There are probably simple ways to fix this, but I just open them in gedit, add a few lines of text to the start of the file, then delete the offending character in vim where I can see it. If you've got a nicer way of fixing this, let me know.

As far as I know there is no file in the entire source that requires any other file format. If there's a file that's questionable, let me know.

Note that this is the ONLY change you are making to the files! Let others handle regions, license headers, etc. You are ONLY changing the file format, and maybe deleting a few characters here and there!

Now, on to the files in question.

The following folders need work:
M - Content/ - Completed by @meklu 93fd738
M - Content/ContentReaders/ - Completed by @meklu 93fd738
H - Graphics/ - Completed by @3vi1 85c4105
M - Graphics/PackedVector/ - Completed by @khbecker 3ee6770
M - Graphics/Vertices/ - Completed by @khbecker 1e8640d
E - Input/ - Completed by @khbecker 2b05953
E - Input/Touch/ - Completed by @khbecker 2b05953
E - Media/ - Completed by @khbecker f84404d
E - Storage/ - Completed by @khbecker f84404d
H - ./ - Completed by @khbecker 02df1ca

E - Easy. Probably still work, but nothing deadly.
M - Medium. Things start to get ugly here.
H - Hard. I hope you're proudly unemployed while you're doing this.

The following folders have already been completed, and should be used as references:
Audio/
Graphics/States/
SDL2/

The following folders are NOT to be touched. This is because we need to keep MonoGame compatibility, or because it will be dealt with in a separate project:
GamerServices/
Graphics/Effect/
Graphics/Shaders/
Net/
Properties/
Utilities/

If you decide to take a folder, please post here and let us know you're working on it. Because we're doing so much work on so much code, we need to be sure we're not conflicting with other branches. Be sure to check ALL [FNA] issues before taking on a folder!

Difficulty: This is considered an EASY task. If you're just looking to kill some time, this is the task for you.

One thing that we didn't really touch on in the first FNA pass is the using statements. These blocks are really useful for telling us what each file depends on, and having this part be clean and consistent can be really important when considering dependencies, portability, and other similar factors.

So, we need to go through each and every file and clean these up. There are two main things we need to fix:

• Remove unused using statements.
• Organize using statements according to dependency type.

The first category is pretty simple. In the most brute-force way, you can just remove each statement, compile, and see if it still works. Often you'll be able to tell right away if it's not needed (like enum declaration files), but sometimes the brute-force method is the easiest way to knock them out.

In the second category, we're going to categorize in this manner:

// .NET runtime dependencies first...
using System;
using System.Xml;

// Other libraries second (note the space in between!)
using SDL2;
using OpenTK.Graphics.OpenGL;

// Internal namespaces last, in our case, XNA namespaces.
// Again, note the spacing! These comments aren't part of it though.
using Microsoft.Xna.Framework.Audio;
using Microsoft.Xna.Framework.Graphics;

Now, on to the files in question.

The following folders need work:
@rlabrecque took care of the organization for all files, all that's left is unused statements: ad5afb2
@3vi1 did a passthrough of removing unused using statements, if someone wants to do a second pass: 583cfe5
E - Audio/ - Completed by flibit 88c0eec
E - Content/
H - Content/ContentReaders/
M - Graphics/
E - Graphics/PackedVector/
E - Graphics/States/
E - Graphics/Vertices/
E - Input/
E - Input/Touch/
M - Media/
E - Storage/ - Verified as okay by flibit
E - SDL2/ - Verified as okay by @3vi1
E - SDL2/Input/ - Verified as okay by @3vi1
E - SDL2/Media/ - Verified as okay by @3vi1
H - ./

E - Easy. Probably still work, but nothing deadly.
M - Medium. Things start to get ugly here.
H - Hard. I hope you're proudly unemployed while you're doing this.

The following folders are NOT to be touched. This is because we need to keep MonoGame compatibility, or because it will be dealt with in a separate project:
GamerServices/
Graphics/Effect/
Graphics/Shaders/
Net/
Properties/
Utilities/

If you decide to take a folder, please post here and let us know you're working on it. Because we're doing so much work on so much code, we need to be sure we're not conflicting with other branches. Be sure to check ALL [FNA] issues before taking on a folder!

Let me know if I'm just doing something wrong, but setting AllowUserResizing to true does not appear to actually enable resizing of the SDL window, much like bug MonoGame#1069 showed the same issue with OpenTK (though thefiddler indicates that might have been fixed in OpenTK 1.1).

XNA/Monogame's Content.Load function loads XNB assets using relative paths which are /relative to the game executable/. However, Monogame doesn't follow the same rules when Content.Load'ing native resources like PNG files. Instead, it assumes those paths are relative to the current directory.

This is probably just an oversight in the MonoGame implementation. The most noticeable effect is that games using assets in subdirectories will crash or fail to load assets if you execute them without changing to the directory of the executable first.

I think we should use one consistent standard and make Content.Load's behavior always the same as XNA uses when dealing with XNB resources (i.e. treat all asset paths as relative to AppDomain.CurrentDomain.BaseDirectory). This would make swapping code between the two types of assets easier and more reliable.

I've noticed an interesting issue with PNG transparency.

Using my own RenderTarget2D and SpriteSortMode.Deferred, BlendState.AlphaBlend, SamplerState.PointClamp, DepthStencilState.None, RasterizerState.CullNone as my spriteBatch Begin options, I do not get the expected results from Draw calls.

Texture pixels that have a completely transparent alpha value (0) are being rendered to the screen as completely opaque if they have /any/ color value. I believe that with BlendState.AlphaBlend they should not be rendered at all, or am I crazy?

I ran into this after resizing an image in Gimp and finding that the original half of the image was rendering previously deleted colors in the "transparent" portions, whereas the new half looked correct. Re-exporting the image and disabling “save color values from transparent pixels” works around the issue.

This looks incorrect:

https://github.com/flibitijibibo/MonoGame/blob/monogame-sdl2/MonoGame.Framework/Storage/StorageDevice.cs#L62

Don't we want that to return false on exception? DriveInfo.IsReady already does nothing but return true (with no checks), so the only reason for an exception to be thrown is if the DriveInfo constructor fails because driveName is invalid.

If that's happening, returning true is a very hacky way to gloss over the real problem (apps that pass hardcoded Windows-style drive letters instead of calling GetDrives).

I cant hear anything when I try to play a song. SoundEffects work though. No exceptions are thrown which is rather odd.

Also, when running my game idle on its menu screen, the CPU consumes upto 25% usage! Comparing to MonoGame's directX platform, that only uses less than 1%.

Otherwise what are the list of dependencies for MonoGameSDL2 to work. Thanks for all your hard work, MonoGame-SDL is looking good!

When I want to dispose old buffer and then create new one with larger capacity:

Buffer.Dispose();
Buffer = new DynamicVertexBuffer(Parent.Engine.GraphicsDevice, typeof(VertexPositionColorTexture), sorted.Count, BufferUsage.WriteOnly);

I got this exception in method GenerateIfRequired (line 435)
GL.GetError() returned InvalidOperation

Without calling dispose everything is ok. I am using current branch monogame-sdl2.

This is another (seemingly) trivial issue I found while porting. There's an IsPrepared property on WaveBank in XNA that is missing in FNA. I simply added the property and set it to true after the wave bank loaded up and it worked for my situation. I'm not 100% sure that's the most conforming implementation, but it unblocked my game compilation failing.

Creating a new plain project (i.e. the cornflower blue window), when closing the project i receive a system access violation on the following lines in SDL2_GameWindow.cs in the INTERNAL_Destroy() function;

        GL.DeleteFramebuffer(INTERNAL_glFramebuffer);
        GL.DeleteTexture(INTERNAL_glColorAttachment);
        GL.DeleteTexture(INTERNAL_glDepthStencilAttachment);

Am i doing not linking in or creating something correctly?

This may be specific to MonoGame itself but it seems that layerDepth for SpriteBatch drawing is reversed when moving from XNA to MonoGame-SDL2. This means that a value of 1.0 is absolute foreground and 0.0 is absolute background. I have this declare for now in my engine when sorting sprites (by layer and by Z within that layer). In this case LayerPresets.One is my layer most in the background, and I'm using the below SpriteBatch parameters:

if MonoGame

            layerDepth = 1 - Position.Z / LayerPresets.One; // Works in MGSD2

else

            layerDepth = 1 / LayerPresets.One * Position.Z; // Works in XNA

endif

_spriteBatch.Begin(SpriteSortMode.BackToFront, BlendState.NonPremultiplied, SamplerState.PointClamp, DepthStencilState.Default, RasterizerState.CullCounterClockwise, null, camera.Transform);

Hi,

There seems to be a bug in the new implementation of Texture2D.FromStream. I'm getting a SIGSEGV at the following line (Texture2D.cs:499):

Marshal.Copy(INTERNAL_getSurfacePixels(surface), pixels, 0, pixels.Length);

The code which calls FromStream:

FileStream stream = new FileStream (filename, FileMode.Open);
return Texture2D.FromStream (screen.GraphicsDevice, stream);

The image file:

https://github.com/pse-knot/knot3-code/blob/master/Content/Textures/logo.png

Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Runtime.InteropServices.Marshal.copy_from_unmanaged (intptr,int,System.Array,int) <IL 0x00010, 0xffffffff>
  at System.Runtime.InteropServices.Marshal.Copy (intptr,byte[],int,int) <IL 0x00004, 0x00057>
  at Microsoft.Xna.Framework.Graphics.Texture2D.FromStream (Microsoft.Xna.Framework.Graphics.GraphicsDevice,System.IO.Stream) [0x00055] in /data/workspace/MonoGame-SDL2/MonoGame.Framework/Graphics/Texture2D.cs:499
  at Knot3.Framework.Platform.ContentLoader.LoadTextureFromFile (Knot3.Framework.Core.IScreen,string) [0x0003e] in /data/workspace/knot3-code/Framework/Knot3.Framework/Platform/ContentLoader.cs:161
  at Knot3.Framework.Platform.ContentLoader.LoadTexture (Knot3.Framework.Core.IScreen,string) [0x00045] in /data/workspace/knot3-code/Framework/Knot3.Framework/Platform/ContentLoader.cs:132
  at Knot3.Game.Screens.StartScreen..ctor (Knot3.Framework.Core.GameCore) [0x0002a] in /data/workspace/knot3-code/Game/Knot3.Game/Screens/StartScreen.cs:69
  at Knot3.Game.Core.Knot3Game.Initialize () [0x000ff] in /data/workspace/knot3-code/Game/Knot3.Game/Core/Knot3Game.cs:109
  at Microsoft.Xna.Framework.Game.DoInitialize () [0x00013] in /data/workspace/MonoGame-SDL2/MonoGame.Framework/Game.cs:761
  at Microsoft.Xna.Framework.Game.Run (Microsoft.Xna.Framework.GameRunBehavior) [0x00029] in /data/workspace/MonoGame-SDL2/MonoGame.Framework/Game.cs:462
  at Microsoft.Xna.Framework.Game.Run () [0x0000d] in /data/workspace/MonoGame-SDL2/MonoGame.Framework/Game.cs:452
  at Knot3.Game.Program.GameLoop () [0x00009] in /data/workspace/knot3-code/Game/Knot3.Game/Program.cs:82
  at Knot3.Game.Program.Main () [0x00051] in /data/workspace/knot3-code/Game/Knot3.Game/Program.cs:60
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <IL 0x0004c, 0xffffffff>

Native stacktrace:

    /usr/bin/mono() [0x4b73d8]
    /usr/bin/mono() [0x50f13b]
    /usr/bin/mono() [0x423d22]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x10330) [0x7fd71a11b330]
    /lib/x86_64-linux-gnu/libc.so.6(+0x98c7e) [0x7fd719dddc7e]
    [0x416c6afa]

Debug info from gdb:

ptrace: Die Operation ist nicht erlaubt.
No threads.

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

When Mouse.SetPosition(x, y) is called, Mouse.GetState() should return the new mouse position if it is called immediately afterwards or in the same Update() call (at least that's how XNA behaves).

The current behaviour is that the X/Y values from the MouseState returned from GetState() are still at the old position until the next Update() call.

I tried hardware instancing based on this article: https://web.archive.org/web/20120422215823/http://sciencefact.co.uk/2011/12/hardware-geometry-instancing-in-xna-4/ my implementation is here: https://github.com/Vodacek/TestProjects/tree/master/Instancing/TextureCube
Nothing is rendered, even if I try to draw everything in loop manually by drawindexedprimitives method. To switch between modes use SPACE key.

I know I am huge issue maker :-)

Right now Song looks like this:

https://github.com/flibitijibibo/MonoGame/blob/monogame-sdl2/MonoGame.Framework/SDL2/Media/Song.cs

Noticing some stubs in there?

On top of that, this file alone depends on SDL2_mixer on top of Vorbisfile (and consequently, Ogg/Vorbis, but VideoPlayer can use those too). Even worse, this one file pokes the sound server separately from the OpenAL context, and this can get kind of nasty for certain audio configurations. Plus, it looks pretty stupid in audio control panels.

I actually wanted to move this to a thread and straight Vorbisfile, but A: threads are dumb, and B: I couldn't quite get Vorbisfile# working.

For point A, we now have a solution: DynamicSoundEffectInstance:

https://github.com/flibitijibibo/MonoGame/blob/monogame-sdl2/MonoGame.Framework/Audio/DynamicSoundEffectInstance.cs

All you'd have to do is use the Event to pull in more Vorbis data when it's needed. Simple!

Point B, since creating this issue, has now been solved. Here is Vorbisfile#:

https://github.com/flibitijibibo/Vorbisfile-CS

With this, it should now be possible to write a new Song that uses DynamicSoundEffectInstance.

A lot of this sounds like it's more of a general technical problem, but a lot of what's pulling me away from SDL2_mixer is the portability aspect of it. SDL2 itself is portable of course, but DynamicSoundEffectInstance is even more portable in that we delegate all the real platform code to the Audio engine, so in the event that SDL2's not acceptable somewhere (pff), Song doesn't become an issue. If a platform can't even use Vorbisfile, well, that's their own problem (they could just move to csvorbis and not really change the code all that much, but I'd rather not have up to 2 different Vorbis libs in one project by default).

Here are some games you can test with, if you don't have one yourself:

• Capsized
• Gateways
• Dust: An Elysian Tail (Just the opening sequence)
• Fist Puncher

If your MonoGame.Framework.dll doesn't work against the game, let me know and I can rebuild it fresh against upstream MG-SDL2 for you.

I've been playing with MonoGame-SDL2, and can't seem to get ToggleFullScreen to work.

When called within the Game1 Update method, the app toggles between full and windowed, but it throws the error below on the next call to spriteBatch.End(). If I disable drawing for a small period of time (like 5 seconds, which is about 4.9 seconds longer than the window takes to toggle), I do not get an error when the draw is re-enabled... but the textures I'm drawing do not render properly (it renders a black square).

Microsoft.Xna.Framework.Graphics.MonoGameGLException: GL.GetError() returned InvalidFramebufferOperationExt
at Microsoft.Xna.Framework.Graphics.GraphicsExtensions.CheckGLError () [0x00022] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Graphics/GraphicsExtensions.cs:737
at Microsoft.Xna.Framework.Graphics.BlendState.ApplyState (Microsoft.Xna.Framework.Graphics.GraphicsDevice device) [0x00052] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Graphics/States/BlendState.cs:260
at Microsoft.Xna.Framework.Graphics.GraphicsDevice.ApplyState (Boolean applyShaders) [0x00082] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Graphics/GraphicsDevice.cs:2059
at Microsoft.Xna.Framework.Graphics.GraphicsDevice.DrawUserIndexedPrimitives[VertexPositionColorTexture](PrimitiveType primitiveType, Microsoft.Xna.Framework.Graphics.VertexPositionColorTexture[] vertexData, Int32 vertexOffset, Int32 numVertices, System.Int16[] indexData, Int32 indexOffset, Int32 primitiveCount, Microsoft.Xna.Framework.Graphics.VertexDeclaration vertexDeclaration) [0x00037] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Graphics/GraphicsDevice.cs:2415
at Microsoft.Xna.Framework.Graphics.SpriteBatcher.FlushVertexArray (Int32 start, Int32 end) [0x00031] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Graphics/SpriteBatcher.cs:287
at Microsoft.Xna.Framework.Graphics.SpriteBatcher.DrawBatch (SpriteSortMode sortMode) [0x001e9] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Graphics/SpriteBatcher.cs:267
at Microsoft.Xna.Framework.Graphics.SpriteBatch.End () [0x00026] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Graphics/SpriteBatch.cs:99
at walkabout.Game1.Draw (Microsoft.Xna.Framework.GameTime gameTime) [0x00094] in /home/evil/src/walkabout/walkabout/Game1.cs:132
at Microsoft.Xna.Framework.Game.DoDraw (Microsoft.Xna.Framework.GameTime gameTime) [0x00026] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Game.cs:752
at Microsoft.Xna.Framework.Game.Tick () [0x001d0] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Game.cs:566
at Microsoft.Xna.Framework.SDL2_GameWindow.INTERNAL_RunLoop () [0x00361] in /home/evil/src/monogame-sdl2/MonoGame.Framework/SDL2/SDL2_GameWindow.cs:456
at Microsoft.Xna.Framework.SDL2_GamePlatform.RunLoop () [0x00007] in /home/evil/src/monogame-sdl2/MonoGame.Framework/SDL2/SDL2_GamePlatform.cs:143
at Microsoft.Xna.Framework.Game.Run (GameRunBehavior runBehavior) [0x0007b] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Game.cs:474
at Microsoft.Xna.Framework.Game.Run () [0x0000d] in /home/evil/src/monogame-sdl2/MonoGame.Framework/Game.cs:452
at walkabout.Program.Main () [0x00010] in /home/evil/src/walkabout/walkabout/Program.cs:20

I ran pretty much the same code using XNA (apparently there's no spritebatch Draw that takes texture, position, drawRectangle, sourceRectangle, origin, rotation, scale, color, effect, depth' in XNA) in a Windows VM and the toggle works fne there.

As in title,it is simple:

When Game.Exit() is called, the game window closes, but with those errors:

Native stacktrace:

/usr/bin/mono() [0x4961e9]
/usr/bin/mono() [0x4e6d1f]
/usr/bin/mono() [0x41dcb7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbd0) [0x7f8da4827bd0]
/usr/lib/nvidia-331/libGL.so.1(+0x30f6e9) [0x7f8d99c976e9]

"Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries used by your application."

The same happens when I try ALT + F4 and clicking on the 'x' of the window.

I think maybe I am losing something, as the app seems to try access a memory
position it shouldn't.

The SoundEffectInstance is playing sound effects that do not sound right, if you listen to the same sound effect though WMP you can tell it sounds different.

Only after say 10 plays of the same sound effect does it eventually change and sound normal (it fixes itself really). I'm investigating but the problem seems to be lower level.

Though initial development of my game this is the final and last issue that ive encountered with MonoGameSDL2 (other than the vsync issue which effects all MonoGame platforms -> MonoGame#1184)

Is it possible to remove the OpenAL requirement and use SDL_Mixer? That way my end users on windows will not have to install any dependencies (other than .net 4.5) and SDL_Mixer behaves well now.

Depending on what you think of this I might have a stab at doing it.

Difficulty: This is considered a MEDIUM task. This might take a bit of work, but it still doesn't require any real skills to do.

Ordering: This task should occur AFTER removing unused defs! See #145 before taking a folder here.

The MonoGame source has some big files. The MonoGame source has some confusing files. Most importantly, the MonoGame source has some batshit crazy files that have been beaten to death over the last 5 years, with bizarre internal variables/methods, insane ordering of information, and worst of all, NONE of it is documented in the slightest way.

While we can't immediately go around changing how all the files work, the least we can do is organize things in a way that tells us what's public, what's not, what's XNA4 spec, what's junk we made up, and so on.

Something C# has that's actually really nice is the #region/#endregion system. Basically, you can define a region with a name, and you can collapse it, jump to it using your IDE, etc. this both looks nice and can help keep things very organized. If you're not familiar with this and would like to see examples, look at one of the completed folders listed below.

In general, this is how I'd like the region ordering to be:

Visibility:
    Public
    Internal
    Protected
    Private

Type:
    Properties
    Variables
    Static Constructors
    Constructors
    Methods
    Static Methods

So, for example, Public Properties come before Private Properties, and ALL Properties come before Constructors.

Also note that there are NOT any subregions! The point of regions is to organize things, and while there is probably a place for subregions, for now we're mostly just worried about organizing things on a very basic level. Things will probably get more complex as we determine what's XNA spec, what's just internal work, what's an extension, etc.

There's a good chance that this is confusing, and there are likely bizarre exceptions that need to be considered, so when this comes up, feel free to ask.

Also, feel free to split up types into subtypes that might be relevant with each other; for example, SDL2_GamePlatform overrides methods that GamePlatform declares, so I put those methods in a region called "Public GamePlatform Methods".

The most important thing to note here is that you are NOT actually changing any code! You're just moving it around. Were there actual changes occurring, this would certainly be ranked as a HARD task.

Additionally, note that this is the ONLY change you are making to the files! Let others handle license headers, tabbing, etc. You are ONLY moving blocks of code around and adding #region/#endregion where it's necessary.

Now, on to the files in question.

The following folders need work:
M - Content/ - Completed by @meklu d9483bf
M - Content/ContentReaders/ - Completed by @meklu d9483bf
H - Graphics/ - Completed by @extrahotchilipowder 8dd78db
M - Graphics/PackedVector/ - Completed by @extrahotchilipowder 8dd78db
M - Graphics/Vertices/ - Completed by @extrahotchilipowder 8dd78db
E - Input/ - Completed by @extrahotchilipowder 1dddd3d
E - Input/Touch/ - Completed by @extrahotchilipowder 1dddd3d
E - Media/ - Completed by @3vi1 95d90b4 with changes from flibit a87b7b9
E - Storage/ - Completed by flibit bd7d2d2
H - ./ - Completed by @extrahotchilipowder 02957f8

E - Easy. Probably still work, but nothing deadly.
M - Medium. Things start to get ugly here.
H - Hard. I hope you're proudly unemployed while you're doing this.

The following folders have already been completed, and should be used as references:
Audio/
Graphics/States/
SDL2/

The following folders are NOT to be touched. This is because we need to keep MonoGame compatibility, or because it will be dealt with in a separate project:
GamerServices/
Graphics/Effect/
Graphics/Shaders/
Net/
Properties/
Utilities/

If you decide to take a folder, please post here and let us know you're working on it. Because we're doing so much work on so much code, we need to be sure we're not conflicting with other branches. Be sure to check ALL [FNA] issues before taking on a folder!

Sorry to bother. I'm really desperate about this and I don't know how to proceed.

Keeping it short, it is simple: I can't (I even don't know how) to compile your fork of monogame which SEEMS to work using PreferredBackBuffer{Height|Width}.

I done the following:

git clone repo link
cd Monogame/
git submodule update --init

then I opened MonoGame.Framework.Linux.sln in monodevelop and tried to build, but there are 54 errors.

Am I losing something? Yes, I'm a noob on monogame programming and c# prograaming, but I want to learn it.

I hope you guys can help me.

And there are the errors:

/home/jordy/MonoGame/MonoGame.Framework/Graphics/Texture.cs(70,26): error CS0246: The type or namespace name TextureTarget' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/Texture.cs(71,18): error CS0246: The type or namespace nameTextureUnit' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/TextureCube.cs(49,17): error CS0246: The type or namespace name PixelInternalFormat' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/TextureCube.cs(50,17): error CS0246: The type or namespace namePixelFormat' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/TextureCube.cs(51,17): error CS0246: The type or namespace name PixelType' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/TextureCube.cs(291,25): error CS0246: The type or namespace nameTextureTarget' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/TextureCollection.cs(23,26): error CS0246: The type or namespace name TextureTarget' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/States/DepthStencilState.cs(209,24): error CS0246: The type or namespace nameGLStencilFunction' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/States/DepthStencilState.cs(235,24): error CS0246: The type or namespace name StencilOp' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/States/SamplerState.cs(70,23): error CS0246: The type or namespace nameGetPName' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/States/SamplerState.cs(71,23): error CS0246: The type or namespace name TextureParameterName' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/States/SamplerState.cs(292,28): error CS0246: The type or namespace nameTextureTarget' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/GamerServices/GamerProfile.cs(67,24): warning CS0628: Microsoft.Xna.Framework.GamerServices.GamerProfile.Dispose(bool)': new protected member declared in sealed class /home/jordy/MonoGame/MonoGame.Framework/Desktop/Audio/AudioLoader.cs(13,24): error CS0433: The imported typeOpenTK.Audio.OpenAL.ALFormat' is defined multiple times
/home/jordy/MonoGame/ThirdParty/Libs/OpenTK.dll (Location of the symbol related to previous error)
/home/jordy/MonoGame/MonoGame.Framework/bin/Linux/Release/SDL2#.dll (Location of the symbol related to previous error)
/home/jordy/MonoGame/MonoGame.Framework/Desktop/OpenTKGameWindow.cs(70,33): error CS0433: The imported type OpenTK.Graphics.GraphicsContext' is defined multiple times /home/jordy/MonoGame/ThirdParty/Libs/OpenTK.dll (Location of the symbol related to previous error) /home/jordy/MonoGame/MonoGame.Framework/bin/Linux/Release/SDL2#.dll (Location of the symbol related to previous error) /home/jordy/MonoGame/MonoGame.Framework/Desktop/Audio/OpenALSoundController.cs(20,17): error CS0433: The imported typeOpenTK.ContextHandle' is defined multiple times
/home/jordy/MonoGame/ThirdParty/Libs/OpenTK.dll (Location of the symbol related to previous error)
/home/jordy/MonoGame/MonoGame.Framework/bin/Linux/Release/SDL2#.dll (Location of the symbol related to previous error)
/home/jordy/MonoGame/MonoGame.Framework/Desktop/Audio/OpenALSoundController.cs(23,17): error CS0433: The imported type OpenTK.Audio.OpenAL.AlcError' is defined multiple times /home/jordy/MonoGame/ThirdParty/Libs/OpenTK.dll (Location of the symbol related to previous error) /home/jordy/MonoGame/MonoGame.Framework/bin/Linux/Release/SDL2#.dll (Location of the symbol related to previous error) /home/jordy/MonoGame/MonoGame.Framework/Audio/SoundEffect.cs(90,17): error CS0246: The type or namespace nameSound' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/Vertices/VertexDeclaration.cs(220,24): error CS0433: The imported type OpenTK.Graphics.ES20.VertexAttribPointerType' is defined multiple times /home/jordy/MonoGame/ThirdParty/Libs/OpenTK.dll (Location of the symbol related to previous error) /home/jordy/MonoGame/MonoGame.Framework/bin/Linux/Release/SDL2#.dll (Location of the symbol related to previous error) /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(233,23): error CS0246: The type or namespace nameFramebufferTarget' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(234,23): error CS0246: The type or namespace name RenderbufferTarget' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(235,23): error CS0246: The type or namespace nameFramebufferAttachment' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(236,23): error CS0246: The type or namespace name FramebufferAttachment' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(237,23): error CS0246: The type or namespace nameFramebufferAttachment' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(238,23): error CS0246: The type or namespace name GetPName' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(239,23): error CS0246: The type or namespace nameRenderbufferStorage' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(240,23): error CS0246: The type or namespace name RenderbufferStorage' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(241,23): error CS0246: The type or namespace nameRenderbufferStorage' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(242,23): error CS0246: The type or namespace name FramebufferErrorCode' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(117,25): error CS0246: The type or namespace nameDrawBuffersEnum' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(1858,24): error CS0246: The type or namespace name BeginMode' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.cs(1915,45): error CS0246: The type or namespace nameVertexBufferBinding' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(30,23): error CS0246: The type or namespace name All' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(87,23): error CS0246: The type or namespace nameVertexPointerType' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(131,31): error CS0246: The type or namespace name VertexAttribPointerType' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(201,23): error CS0246: The type or namespace nameColorPointerType' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(247,22): error CS0246: The type or namespace name NormalPointerType' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(293,22): error CS0246: The type or namespace nameTexCoordPointerType' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(340,31): error CS0246: The type or namespace name BlendEquationMode' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(366,31): error CS0246: The type or namespace nameBlendingFactorSrc' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(405,31): error CS0246: The type or namespace name BlendingFactorDest' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(438,54): error CS0246: The type or namespace namePixelInternalFormat' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(439,54): error CS0246: The type or namespace name PixelFormat' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/GraphicsExtensions.cs(440,54): error CS0246: The type or namespace namePixelType' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/Texture2D.cs(117,17): error CS0246: The type or namespace name PixelInternalFormat' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/Texture2D.cs(118,17): error CS0246: The type or namespace nameGLPixelFormat' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/Texture2D.cs(119,17): error CS0246: The type or namespace name PixelType' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/RenderTarget2D.cs(68,11): error CS0246: The type or namespace nameRenderbufferTarget' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/RenderTarget2D.cs(69,11): error CS0246: The type or namespace name RenderbufferStorage' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/RenderTarget2D.cs(70,11): error CS0246: The type or namespace nameRenderbufferStorage' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/RenderTarget2D.cs(71,11): error CS0246: The type or namespace name RenderbufferStorage' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/RenderTarget2D.cs(72,11): error CS0246: The type or namespace nameRenderbufferStorage' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/Texture3D.cs(29,17): error CS0246: The type or namespace name PixelInternalFormat' could not be found. Are you missing a using directive or an assembly reference? /home/jordy/MonoGame/MonoGame.Framework/Graphics/Texture3D.cs(30,17): error CS0246: The type or namespace namePixelFormat' could not be found. Are you missing a using directive or an assembly reference?
/home/jordy/MonoGame/MonoGame.Framework/Graphics/Texture3D.cs(31,17): error CS0246: The type or namespace name `PixelType' could not be found. Are you missing a using directive or an assembly reference?

Difficulty: This is considered an EASY task. If you're just looking to kill some time, this is the task for you.

In FNA we will be using a new license header. It looks like this:

#region License
/* FNA - XNA4 Reimplementation for Desktop Platforms
* Copyright 2009-2014 Ethan Lee and the MonoGame Team
*
* Released under the Microsoft Public License.
* See LICENSE for details.
*/
#endregion

Lots of files in MonoGame don't have a license. Lots of files in MonoGame have variations of the same license. Some files may even have separate licenses, due to being code pulled from other projects. In the latter situation, please add these licenses to the License region, placing them in separate /**/ blocks. Add a space between each license when there are multiple licenses.

Note that this is the ONLY change you are making to the files! Let others handle regions, line endings, etc. You are ONLY changing the license header!

Now, on to the files in question.

The following folders need work:
M - Content/ - Completed by @meklu 93fd738
M - Content/ContentReaders/ - Completed by @meklu 93fd738
H - Graphics/ - Completed by @3vi1 03b7fad
M - Graphics/PackedVector/ - Completed by @3vi1 4228d8d
M - Graphics/Vertices/ - Completed by @3vi1 03b7fad
E - Input/ - Completed by @khbecker 92e2c81
E - Input/Touch/ - Completed by @khbecker 92e2c81
E - Media/ - Completed by @khbecker f84404d
E - Storage/ - Completed by @3vi1 bf70df0
H - ./ - Completed by @khbecker 477f620

E - Easy. Probably still work, but nothing deadly.
M - Medium. Things start to get ugly here.
H - Hard. I hope you're proudly unemployed while you're doing this.

The following folders have already been completed, and should be used as references:
Audio/
Graphics/States/
SDL2/

The following folders are NOT to be touched. This is because we need to keep MonoGame compatibility, or because it will be dealt with in a separate project:
GamerServices/
Graphics/Effect/
Graphics/Shaders/
Net/
Properties/
Utilities/

If you decide to take a folder, please post here and let us know you're working on it. Because we're doing so much work on so much code, we need to be sure we're not conflicting with other branches. Be sure to check ALL [FNA] issues before taking on a folder!

The window Icon should be set to the icon of the running executable.

Difficulty: This is considered a MEDIUM task. This might take a bit of work, but it still doesn't require any real skills to do.

Ordering: This task should occur BEFORE adding regions or fixing code style! See those issues before taking a folder here.

You all knew this was coming.

MonoGame-SDL2 only ever has these defs: SDL2, OPENGL, and DEBUG. Additionally, there are some configurable flags that may exist in specific files. For instance. SDL2_GameWindow.cs has a WIIU_GAMEPAD def that can be toggled. Aside from this, there should be absolutely nothing else.

So now it's time to delete the unending interleaved #ifdef Dr. Seuss nightmare. Basically, you're going to dive into every file and rip out any code that does NOT fit in one of the above defs. What you're going to see is pretty hideous, I'm not going to lie.

99.999% of the time, you can just delete what's not MG-SDL2-related without even thinking. However, if you happen to come across some code that is def'd out, but might actually be useful for any platform without changing it, let me know. You can generally expect this to not happen, but some useful things like the Threading.cs ForceToMainThread operation came out of stealing from other platforms' code, so it's certainly possible.

I considered making this a HARD issue, because this DOES technically change code, but if you know what you're doing this should not actually change any code for MG-SDL2. Only the preprocessor is going to know the difference.

Note that this is the ONLY change you are making to the files! Let others handle regions, line endings, etc. You are ONLY removing dead code; you're not even changing the license header!

Now, on to the files in question.

The following folders need work:
M - Content/ - Completed by @meklu 93fd738
M - Content/ContentReaders/ - Completed by @meklu 93fd738
H - Graphics/ - Completed by @khbecker a678eba
M - Graphics/Vertices/ - Completed by @3vi1 e3ca0ee
E - Input/Touch/ - Completed by @extrahotchilipowder 2f5a598
E - Media/ - Completed by @extrahotchilipowder 2f5a598
E - Storage/ - Completed by @3vi1 e3ca0ee
H - ./ - Completed by @extrahotchilipowder 9901101 with one more commit by flibit 83d021f

E - Easy. Probably still work, but nothing deadly.
M - Medium. Things start to get ugly here.
H - Hard. I hope you're proudly unemployed while you're doing this.

The following folders were not relevant to this task:
Graphics/PackedVector/
Input/

The following folders have already been completed, and should be used as references:
Audio/
Graphics/States/
SDL2/

The following folders are NOT to be touched. This is because we need to keep MonoGame compatibility, or because it will be dealt with in a separate project:
GamerServices/
Graphics/Effect/
Graphics/Shaders/
Net/
Properties/
Utilities/

If you decide to take a folder, please post here and let us know you're working on it. Because we're doing so much work on so much code, we need to be sure we're not conflicting with other branches. Be sure to check ALL [FNA] issues before taking on a folder!

Difficulty: This task is considered a HARD task. If MEDIUM tasks separate the men from the boys, HARD tasks separate Dark Souls fans from actual serial killers that wear proper armor for reasons yet to be explained.

Ordering: This task should occur AFTER removing unused defs! See #145 before taking a folder here.

One of my favorite features of the MonoGame source is that the tabbing/formatting is fucked. I hesitate to blame any specific dev for this, not because of a mass of incompetent MonoGame devs, but because of a mass of incompetent IDE developers. I swear, I have yet to understand the black magic that decides how MonoDevelop tabs your files.

So while we're fixing this problem, we're going to establish a strict text format that should help make the source significantly more readable.

Here are the rules:

• Tabs: Actual '\t' tabs, NOT SPACES!
• Blank Lines: NO TRAILING SPACE! Blank lines should be, you know, blank.
• Characters per line: ~100. When a line gets too long, start splitting it up into multiple lines. The number should only be considered a maximum value; if you find that you're doing a lot of extensive left-to-right reading rather than top-to-bottom, start splitting the lines up.
• i++/i--: Do i += 1 and i -= 1 instead unless the increment is genuinely being used to its advantage. If it's that painful to do this, consider foreach instead.
• Do not use var! Use the actual type name!
• someMethod() rather than someMethod (), someArray[x] rather than someArray [x], etc.
• (Type) cast rather than (Type)cast.
• Use braces everywhere! I don't care if the if block is one line, braces! Use them!
• Single line comments: // This code is derp rather than //this code is derp.
• Multi-line comments: Use /* */ blocks, rather than multiple lines of //.

How I split up lines:

public static void StupidMethod(
    int with,
    int lots,
    int of,
    string stupid
    IntPtr parameters
) {
    if (    stupidCheck.HasLotsOfBools() &&
        (   theresNothingWe.CanDo() ||
            xnaIsJustThatDumb   )   )
    {
        UInt32 bitFlags = (
            0x000000FF |
            0x0000FF00 |
            0x00FF0000
        );
        throw new Exception(
            "People probably hate my style, I'm sure.\n" +
            "But y'all gotta do it or else this will get worse.\n" +
            "Seriously, have you seen this code?" +
            bitFlags
        );
    }
}

When in doubt, look at a folder that's been completed.

When tabs start getting crazy, you're likely going to want to check with git diff or various text editors to be sure that what you've got is correct. MonoDevelop in particular likes to be totally insane about '\t' tabbing sometimes, so while it might look like tabs are aligned in MonoDevelop, a sane text editor will probably tell you otherwise.

In addition to fixing the style, you're going to find that you're cleaning up a lot of extra stuff on the way... bizarre trailing whitespace will likely become your personal favorite, if interleaved tabbing styles does not win your heart. That said, try to keep the actual code the same. Only change the actual code when you're 100% sure that what you're changing is essentially a no-op change.

Remember, this is the hardest task on the FNA transition list. Assume the absolute worst before you start.

But, note that this is all that you have to change. Everyone else can deal with license headers, line endings, and all that other stuff, assuming you don't do this yourself.

Now, on to the files in question.

The following folders need work:
M - Content/ - Completed by @meklu 93fd738
M - Content/ContentReaders/ - Completed by @meklu 93fd738
H - Graphics/ - Completed by @extrahotchilipowder de44018 and flibit 9569acb 252b6b9
M - Graphics/PackedVector/ - Completed by flibit cb8157c
M - Graphics/Vertices/ - Completed by flibit c9ecd31
E - Input/ - Completed by @khbecker d42d412 and flibit 6d87b6d ea25e90
E - Input/Touch/ - Completed by @3vi1 09c633d with additions by flibit 3ecd0ad
E - Media/ - Completed by @3vi1 741baf3 with additions by flibit c740616
E - Storage/ - Completed by @3vi1 38edaa5 with additions by flibit bd7d2d2
H - ./ - Commits: 5e8b527 c902210 cb7fd61 c69880c 0a4ecb2 a671673 24f1eb3 37ba458 be42238 80b47e7 7aa9e27

E - Easy. Probably still work, but nothing deadly.
M - Medium. Things start to get ugly here.
H - Hard. I hope you're proudly unemployed while you're doing this.

The following folders have already been completed, and should be used as references:
Audio/
Graphics/States/
SDL2/

The following folders are NOT to be touched. This is because we need to keep MonoGame compatibility, or because it will be dealt with in a separate project:
GamerServices/
Graphics/Effect/
Graphics/Shaders/
Net/
Properties/
Utilities/

If you decide to take a folder, please post here and let us know you're working on it. Because we're doing so much work on so much code, we need to be sure we're not conflicting with other branches. Be sure to check ALL [FNA] issues before taking on a folder!

In SetData (line 209) I got this exception:

GL.GetError() returned InvalidValue

So a while back I was talking about MonoGameSDL using strange amounts of CPU. I decided to do some profiling and found some obscure results.

I dont know OpenGL, or anything that low-level in that matter, but from assumptions how is it possible that GetError() could be using so much CPU time? I notice that the clearing of the buffer each frame results in GetError() being called multiple times.

I assure you I'm only calling GraphicsDevice.Clear(); once every frame.

Very odd. What do you think?

After doing some research on this GetError method I have found that it is generally bad to call this function in an release build as it is an expensive call. I compile MonoGame.Framework.DLL and my project both in Release mode but I still get the same horrible CPU usage (25% on a 4 core/(8 core hyperthreaded) CPU).

Hi, Apologies but I desperately need some help.

I am trying to compile your branch mgsdl2-xact from the MonoGame.Framework.SDL2.sln and a couple of things are going wrong for me. I am new to the environment and would a appreciate a nudge in the right direction.

1. I am noticing that the SDL2#, Libs & TheoraPlay# folders are empty which cause errors when I open the solution.
2. in SoundEffects.cs I am getting an error 'OpenTK.Audio.OpenAL.AL' does not contain a definition for 'Buffer' on line 626

So I don't know if there are any depencies I am missing or what I am suppose to do to fix the problem?

I have previously compiled a version from your fork in order to get the gamepad and keybindings working on Mac OSX but since I started working with Audio it has been a bit of a nightmare - I have 16-bit / PCM .wav files I am trying to use in my game but the loading them using Content.Load("audiofile"); just throws a ContentLoadException.

Any help would be much appreciated.

When trying to run on ubuntu without a current audio device, a game build with this branch is crashing with the exception: "Could not open AL device - OpenAL Device Error: Invalid Value"

This is coming from Audio.OpenALDevice.CheckALCError()

If I understand the issue correctly, this might be the same issue that the main Monogame repo addressed in this issue: MonoGame#1376 basically their fix was to do some defensive-coding so that the system could init without an audio device & would survive future calls even if there was no audio device. Their patch was here: MonoGame@f44140d (the code is a bit different than this fork's code, so I'm not sure how straightforward it would be to integrate).

Hey, as I said on twitter some of the shaders in my game are getting mangled a bit. Early in I had some parsing errors through a bunch of shaders when working on a ported version of my game. But they were fairly easily solved by just doing something slightly different to get the same effect.

However it seems like a bunch of Semantics are being dropped MGFX, as it assumes they're not being used. I've noticed it tends to do this for parameters that are not used anywhere, which is fine. However, in a bunch of shaders used in my game it seems to be dropping legitimate ones. Check out this lighting include for instance:

// Lights
const float3 LightDirection = -float3(-0.5f, -1, -0.2f);

float LightCount;
float4 LightData[16];
float3 LightColours[16];

// Colour change gradient
float GradientPosition;
Texture Gradient;
sampler GradientSampler = sampler_state { texture = <Gradient>; magfilter = LINEAR; minfilter = LINEAR; mipfilter= LINEAR; AddressU = clamp; AddressV = clamp;};

// Fogging
float FogStart = 128.0f;
float FogEnd = 256.0f;
float3 FogColour;

float CalculateLightingFactor(float3 normal, float4x4 world)
{   
    return dot(normalize(mul(normal, world)), LightDirection);
}

float3 CalculateLighting(float3 worldPos)
{
    // Apply lights to colour
    float3 light = tex2D(GradientSampler, float2(GradientPosition, 0));
    float3 lightPos;
    float intensity;
    float range;

    for(int i = 0 ; i < LightCount; i++)
    {
        // Get range. Prevent range from being negative by clamping.
        range =  clamp(1 -  (distance(LightData[i].xyz, worldPos) / LightData[i].w), 0, 1);
        light += range * LightColours[i];
    }

    return light;
}

float3 VSCalculateLighting(float3 worldPos)
{
    // Apply lights to colour
    float3 light = float3(1,1,1);
    float3 lightPos;
    float intensity;
    float range;

    for(int i = 0 ; i < LightCount; i++)
    {
        // Get range. Prevent range from being negative by clamping.
        range =  clamp(1 -  (distance(LightData[i].xyz, worldPos) / LightData[i].w), 0, 1);
        light += range * LightColours[i];
    }

    return light;
}

float3 DayLighting()
{
    return tex2D(GradientSampler, float2(GradientPosition, 0));
}

float4 CalculateFogging(float depth, float4 color)
{
    float3 gradientColour = tex2D(GradientSampler, float2(GradientPosition, 0));

    float l = saturate((depth - FogStart) / (FogEnd - FogStart));
    color.rgb = lerp(color, gradientColour, l);

    return color;
}

float4 ApplyLighting(float4 color, float3 light, float lightFactor)
{
    color.rgb *= saturate(light * (0.6 + (lightFactor * 0.4)));
    return color;
}

It seems to be dropping LightCount and depending on what which shader it's included in it's also dropping LightData and LightColours. My evidence for this is basically that the parameters aren't available in the Effect once they're loaded into the game. I believe other semantics like the Fog ones are also being dropped or messed with in some way as Fogging appears to be happening at 0 near and 0 far.

As is it won't compile for me(this is vanilla straight from XNA version). I have to remove LightCount in the bottom function and replace it with a number. Though it seems to compile with the top one referencing LightCount just fine. But still doesn't appear in the Effects parameters at runtime.

I also believe the hardware skinning shader I wrote is also being mangled in the same way as characters appear with randomized scales on different bones. But I haven't looked into it yet.

There seems to be an issue where some cues will not play properly using monogame-sdl2 on Linux. I've created a small example project and uploaded it here:

www.eternaldusk.com/jl-misc/xact/xact-test.zip

The project should play the 'coins' cue that was created from the wav here: http://www.mediacollege.com/downloads/sound-effects/money/cash-register-01.wav

However, it appears to be playing it too fast or something... all that can be heard on my speedy system a high-pitched squeal. No effects or other modifications were made for this cue in the XACT project.

The same engine, soundbank, and wavebank files appear to work fine when I try them in a test project under a Windows VM (i.e. the coins cue sounds correct when played there).

The other cue in the file ('steps'), plays fine under both Linux and Windows.

Difficulty: This task contains many individual subtasks that vary in difficulty, ranging from EASY to HARD. Pick any task you want, based on what you think you can do correctly in a short period of time.

This is so overdue that it hurts.

We can think we're sooo cool for having a cleaned up version of the code, but that doesn't matter if the actual code doesn't work very well. We're down to 0 compiler warnings, but that doesn't mean a whole lot... especially when static analysis enters the ring!

This will act as the monolithic thread for bringing our static analysis warnings down to 0, for ALL possible analyzers. For starters, here are our current reports:

Gendarme: http://www.flibitijibibo.com/fna/gendarme.html
VS /analyze (includes third-party libs, ignore these warnings): Spreadsheet

The Utilities/ folder is the only folder that is NOT to be touched. This is because we need to keep MonoGame compatibility for these files in particular. In addition, we will NOT be touching the StockEffects since those came directly from Microsoft, so changing them would only be more inaccurate.

If you have other static analysis tools, please run FNA through them and send me the results. In particular, I'd love to have results from the Visual Studio /analyze tool.

For this task, simply take any task in the report you want (letting us know you're doing so), send me the PR to fix it, and I'll update the report.

Ideally we should be able to properly fix all of these defects, but some are by XNA4's design... for example, Microsoft.Xna.Framework.Input.Touch is a massive namespace, and Gendarme reports this, but we can't change this without breaking XNA4 compatibility. In these situations, add a line to suppress the warning and document why the suppression is needed.

As we get closer to resolving all the warnings I'll be lowering the threshold for warning level and certainty, so expect more defects to show up as the list gets smaller.

This is our current list of analyzers:

• Gendarme: http://mono-project.com/Gendarme
• Coverity: https://scan.coverity.com/projects/flibitijibibo-fna
• Visual Studio /analyze (NEEDS UPDATE) - Courtesy of @willxinc

If you've got a new tool, please let us know!

If you decide to take a task, please post here and let us know you're working on it. Because we're doing so much work on so much code, we need to be sure we're not conflicting with other branches. Be sure to check ALL [FNA] issues before taking on a task!

The window is not centered when starting. Not a big issue, but would be nicer if it did :).

Difficulty: This is considered a MEDIUM task. This might take a bit of work, but it still doesn't require any real skills to do.

So MonoGame-SDL2 has some comments. This is good! The problem is, a lot of them aren't very helpful, or are ancient artifacts from another universe (we're talking XnaTouch era).

We need to go through the source tree and clean these up. Sometimes this means rewriting them in English, sometimes this means just removing them. For now I wouldn't worry about adding comments... if something's just that baffling, we probably need to reconsider the actual code first.

Now, on to the files in question.

The following folders need work:
H - Audio/ - Completed by flibit 7d3f2a0
H - Content/ - Completed by @3vi1 9c3a1aa
H - Content/ContentReaders/ - Completed by @3vi1 a663708
H - Graphics/ - Completed by @3vi1 8dbe420
M - Graphics/PackedVector/ - Completed by @3vi1 78f4b08
E - Graphics/States/ - Verified as okay by flibit
M - Graphics/Vertices/ - Completed by flibit 657c082
M - Input/ - Completed by @3vi1 9dda689
M - Input/Touch/ - Completed by @3vi1 f9737ce
M - Media/ - Completed by @3vi1 f9737ce
E - Storage/ - Completed by @3vi1 49c4d1c
E - SDL2/ - Completed by @3vi1 300d965
E - SDL2/Input/ - Completed by @3vi1 300d965
E - SDL2/Media/ - Completed by @3vi1 300d965
H - ./ - Completed by @3vi1 e5793ed

E - Easy. Probably still work, but nothing deadly.
M - Medium. Things start to get ugly here.
H - Hard. I hope you're proudly unemployed while you're doing this.

The following folders are NOT to be touched. This is because we need to keep MonoGame compatibility, or because it will be dealt with in a separate project:
GamerServices/
Graphics/Effect/
Graphics/Shaders/
Net/
Properties/
Utilities/

If you decide to take a folder, please post here and let us know you're working on it. Because we're doing so much work on so much code, we need to be sure we're not conflicting with other branches. Be sure to check ALL [FNA] issues before taking on a folder!