Skip to content
This repository

Technical assessment of OpenTK revival vs. switching to SDL2 #1567

elisee opened this Issue March 19, 2013 · 177 comments

So I and others have been advocating reviving OpenTK several times and I'm happy to hear that the MonoGame core team is making good progress on that front (#1528).

Now I hear @flibitijibibo has been working on porting MonoGame to SDL2 with apparently good results. From what he says on Twitter (I hope I'm not misrepresenting what he meant), SDL2 is well maintained and works great on all desktop platforms.

Apparently he mentioned his fork a couple times around here but it wasn't seriously considered because it's a huge change and the perceived cost of merging seems high while the benefits haven't been made obvious

I'm opening this issue hoping that we can discuss the technical & community merits of switching to SDL2 vs. marching forward with the on-going revival on OpenTK.

@flibitijibibo care to point us to your fork, detail what state it's in and how it compares in terms of features/bugs to the current MonoGame?

cc @tomspilman @dellis1972 @CartBlanche

Ethan Lee

Ah yes, so here's what we have. CC'ing @sulix, since he did the bulk (read: pretty much all) of the SDL2 work.

Right now my branch is still on olde OpenTK, but sulix has been using my current HIB port as the experimental project to run under OpenTK running an SDL2 backend.

The OpenTK branch is here:

Last I heard there was only one bug left in fullscreen mode, but things are otherwise okay.

There are two roadblocks to using this, however:

  • Controller support. What we can do is implement the OpenTK GamePad, which is apparently entirely blank, to use the SDL_GameController API. This simultaneously upgrades our input from SDL 1.2 to SDL2 while also improving controller support immensely, with rumble support and Steam Big Picture support (via autoconfig'd controllers, at last!) being the two most significant new features.
  • SDL_mixer. This one in current MonoGame just applies to Linux, but I actually use the Linux Song player on OSX, since it's SDL anyway. As far as I know we can just bump this up to SDL2_mixer without any issues, though to open up platform support we might just be able to use CSVorbis and stream that to a common audio streaming system, which can then go to the native audio API. Knock out all the platforms in one go.

His branch for MonoGame that uses opentk-sdl2 is over here:

Controller support and Song playback are stubbed to prevent symbol clashing, but it works with Codename lolno and Blueberry splendidly (especially in the window management department!!).

EDIT: Also note that this gets rid of Tao entirely. It'd be neat to just use raw SDL2 and skip OpenTK, but if we get OpenTK working this way I wouldn't really object to using it.


This should be useful: compare view of sulix/MonoGame#opentk-sdl2 and mono/MonoGame#develop (thanks GitHub!)

It'd be great if @sulix or @flibitijibibo could give an overview of the architectural changes that have happened in this branch to accomodate OpenTK-SDL2. Some questions come to mind:

  1. Does the Mac port still use MonoMac or did you guys switch to use OpenTK-SDL2 too? (would be great to reduce the amount of code to maintain inside of MonoGame)
  2. Do we still need various folders / implementation files for each desktop platform or does switching to OpentK-SDL2 means we can get rid of most of those and have a unified implementation for Windows(GL?)/Linux/Mac?

The MonoGame project just recovered from a huge split & merge with the develop / develop3d branches and I can imagine the core devs might not be willing to start another huge transition unless the benefits are clear and the process as painless as possible so any information you can share about your changes, fixed bugs resulting from those changes and so on would probably go a long way towards pushing everyone to take a serious look at this.

I'll try to check out the branch myself later this week and see how well it works with CraftStudio.

Dean Ellis
Ethan Lee

Ah yeah, I should explain what's in that branch. But first, the questions:

  1. Right now my branch uses MonoMac, but it'd be great to move that stuff over to SDL2 if possible. sulix only has a Linux environment and I haven't been able to revisit the SDL2 port long enough to rip into the Mac project and try using the OpenTK stuff over MonoMac.
  2. I think we can actually get rid of all of it, as the one platform-specific thing was addressed in his MonoGame branch...

So here's what's in his branch. This is based on my branch, so I'll list those changes too:

  • Further XACT support. RPC tables are parsed, positional audio now works. Contains 1 hack in the RPC parsing.
  • SDL_mixer is commented out for Linux, but not OSX. OSX can comment this out because...
  • sulix wrote the CSVorbis implementation of Song! Didn't see that before, neato!
  • I created a cross-platform VideoPlayer that uses TheoraPlay. It currently requires OpenAL for audio, but there is an OpenGL-accelerated playback system as well as a software renderer for non-GL platforms (though other hardware-accelerated backends are possible). The API breaks at VideoPlayer(), because I needed the GraphicsDevice. The default file extension is ".ogv". Also, here's TheoraPlay-CS:
  • Implemented ActiveSongChanged in MediaPlayer, should work for all platforms.
  • sulix commented out SDL Joystick support. If we left it in, libSDL2 and libSDL would clash and cause a crash. However, with an OpenTK GamePad using SDL2, we'd need to rewrite Desktop/Input/GamePad.cs anyway (though with SDL_GameController as the backend, "rewrite" isn't much...).
  • There's a MonoGameJoystickConfig in there with the joystick support, but that can be thrown out. That was my way of getting customizable controls in the joystick support.
  • I updated OSX's input to ignore gestures, mostly to prevent inertial scrolling from making the mouse wheel go nuts.
  • Fixed a few general leaks and lock-ups, particularly for the MediaPlayer and GraphicsResource.
  • sulix seems to have made StorageDevice XDG-compliant for Linux, and possibly Application Support saves for OSX.

So yeah. It got a wee bit out of control in my branch. sulix's changes are limited to those with his name marked in that list above. Aside from that, the changes related to SDL2 display management are entirely in OpenTKGamePlatform and OpenTKGameWindow. Everything else is just silliness from my Blueberry/lolno ports.


@dellis1972 From my understanding, whether you're shipping OpenTK or shipping OpenTK-SDL2, you already have a dependency. Or rather, OpenTK-vanilla is just as much of a wrapper to the native APIs as OpenTK-SDL2 is. The only difference is that OpenTK-SDL2 is a shell for SDL2 which in turns uses the native API. Or I am missing something?

If this is right then I don't see what's the point of keeping both around. I think it'd be a burden to have to maintain and test the two, the point of the change being to have greater stability, less bugs and less code to maintain.

@flibitijibibo OK so most of those changes should probably be considered as separate issues/pull requests and don't have much weigh in choosing between OpenTK vs SDL2, am I right?

Merging everything at once is most likely not an option (we'd inherit a bunch of changes that we can't sort out, if a bunch of new bugs appear, we can't trace them back easily), so I think we'd need someone to champion a clean branch with the minimum required changes for the OpenTK to OpenTK-SDL2 transition. Makes sense?

OpenTK had a few annoying issues wrt. window sizing / positioning but I and others wrote some patches which should be merged in the new repository soon so:

What exactly do we gain from switching to SDL2? Better window management? Better input system? Less bugs? Which ones did you encounter that motivated you to switch? We need specifics otherwise we'd just be one codebase for another.

EDIT: One clear advantage I see is the fact that we can merge desktop code into a single implementation and push a lot of platform-specific bits down to SDL2. This is nice if we can trust it's well maintained. Development seems to be active at the very least:


From what I've read here so far the biggest issue is whether OpenTK can be gotten "up to code" or to drop it. On Linux OpenTK(through MonoGame) is totally unusable and I believe if Mono/MonoGame wants to be a solid multi-platform programming choice it needs a multi-platform API. If OpenTK can be successfully "converted" then I think this would be the best option but only if the OpenTK community is willing to help push it forward. Otherwise I think we are best to wipe all memories of OpenTK from MonoGame and start with a better maintained project (SDL) to make MG into what it truly could be and show multi-platform developers what's on the market that is helping the cause.

Rant aside, this would obviously be a huge jump and would take some real dedication but I think in something like this streamlining is some what needed for goal making/handling. I also see problems with multiple wrappers being used (correct me if I'm wrong) which can decrease performance in a developers project; something no one would want. I'm new here but under my current life circumstances I'm free to help at almost any time and whichever API is chosen I hope I'll be able to help out.

Ethan Lee

Yeah, those other changes can be ignored without any consequence. The OpenTKGame*cs files are where it's at.

When shipping a game with OpenTK-SDL2, you would just include libSDL2, and OpenTK's .config would point to the various libnames as you'd expect. OpenTK currently just goes straight to, say, X11, so you usually don't have to ship a libfile just for that. However, we already use SDL 1.2 for joystick support (and SDL_mixer for Song playback), so it'll look pretty much the same in the folder, but the benefits are different.

Here's what can be accomplished with an SDL2 backend:

  • Window management that actually works, and is consistent across all its target platforms. Right now there are a lot of inconsistencies between Windows OpenTK and Linux OpenTK here, and it causes a lot of clashing hacks that break the other platform, not because of developer incompetence, but because the platform inconsistency is just that bad. I've got OpenTK Linux working in my branch, but I guarantee that Windows is busted beyond belief, even though it's the same library and code on both. Also, SDL2 is feature-complete here. OpenTK-X11 doesn't even support non-resizable windows, ack!
  • SDL2 input for keyboard, mouse, and controllers. Controllers can be autoconfig'd around the 360 controller, XNA's default (read: only) configuration, via the SDL_GameController API. This also makes MonoGame titles compliant with the Steam Big Picture Mode.
  • Mac support (UNTESTED). I get the feeling that OpenTK-OSX is equally inconsistent, but with SDL2 doing all the dirty work this won't be an issue. There may be a couple OSX-specific things that need to be kept, but it's likely heaps smaller than having an entire OSX implementation of the window management and input.

I think @dellis1972 presents a good point; it might be easier to make an SDL2/ folder and implement an SDL2 platform that works with Windows/Mac/Linux (at the very least), then once that's proven stable we can phase the current desktop implementations out. It'd be a good way to get work done in this area while not smashing up everything that's currently available.


@darkling3100 "On Linux OpenTK(through MonoGame) is totally unusable" Not my experience. With the OpenTK windowing fixes I submitted recently, it works OK. If you have specifics (or even better, open bugs) you can point to that would be fixed by replacing OpenTK then please point to them, otherwise we're talking in a vacuum.

@flibitijibibo Ok this sounds more concrete! :) So there are actual benefits. Implementing an SDL2 MonoGame platform might be a good way to go about it indeed. If it works well then we could start pointing people at it and phase out other desktop platforms (or not) at a later date. I just think we need to be wary of adding more overall work if we can avoid it.

Tom Spilman

First trying to rally a mob...

... isn't an effective way to collaborate with me to make MonoGame better.

My position hasn't changed from the last time this came up. OpenTK is a single API that covers all our GL platforms... yes it has flaws (ref vs out stuff, windowing bugs, etc), but those can and will be fixed.

SDL2 seems to require a completely different code path thru MonoGame. So instead of maintaining one set of OpenGL code... we have to maintain two.

If you can show me how SDL2 can be the sole GL API we use for desktop and mobile then it would be worth considering, but I don't know how this is possible.

Also if you can point me somewhere that can explain to me the licensing and feature set of SDL2 i'd love to see it.


I didn't know we use OpenTK on mobile as I haven't touched these platforms. If we're going to have to keep OpenTK then better fix it everywhere indeed. On the other hand, the SDL2 wiki mentions it runs on Windows, Mac, Linux, iOS and Android.

Like I said earlier, with a couple of patches that have yet to be merged, I don't see that many outstanding issues on Linux with OpenTK. The windowing problems were pretty simple to fix (and were fixed months ago), the only problem was the lack of maintainer. I wish this situation had been fixed sooner but hey, what can you do.

Some more info on SDL2:

Ethan Lee

It may also be worth reading up on SDL2 from their Mercurial repositories, since they only recently finalized the SDL 2.0 ABI.

Steve 'Sly' Williams
David Gow
sulix commented March 19, 2013

Woah: I can't say I expected to wake up to this many emails! Quick stream-of-consciousness ramble follows:

  • My opentk-sdl2 branch is certainly not really something I can recommend merging as-is. It's a nice proof-of-concept, but there are a lot of hacks in place to get everything working. Things would need to be split up into separate pull requests for individual changes.
  • Personally, I think that dropping OpenTK altogether is the right solution long term. Any platforms or features that SDL2 doesn't support can probably be added to SDL. Of course, the C# bindings for SDL would need to include OpenGL bindings. At present there are no standard C# bindings for SDL as well (I hacked some together for opentk-sdl2, but they're incomplete and ugly, TBH). I do believe that maintaining such bindings would be significantly less work than continuing to maintain OpenTK, though.
  • The Song backend my MonoGame branch has is based on stb_vorbis and STBVorbis-CS, not CSVorbis. It's designed in a way that separates the decoding from the actual OpenAL streaming, though, so adding/changing the decoder (or adding support for other formats like opus or wav) should be easy. STBVorbis-CS is here, btw:
  • At the moment, the opentk-sdl2 branch needs a patch to SDL: Hopefully this will be merged into SDL2 soon.
  • The current design of MonoGame could do with a few tweaks. In particular, it'd be nice to actually have separate implementations for things that need to be different, and to merge things which don't. Frankly, the number of #if DIRECTX and #if WINDOWS_STOREAPP declarations around certainly turned me off the project a bit. This is a bit of a separate issue, but it'd be really nice to have a better structure for platform support before adding yet another platform.
  • Window management in particular seems way overcomplicated at the moment. A lot of stuff in my branch was just taking OpenTKGameWindow.cs and ripping out large chunks of code, a lot of which was there to work around OpenTK bugs. If we could get rid of a few "layers" in between the game calling applyChanges and the platform getting the message, that'd be great.
  • @tomspilman mentioned the need for Xamarin to approve third party libraries for MonoTouch or something in another thread. Is this so, and if so does it scuttle the prospects of using SDL2 for mobile platforms. (I still think the benefits of it for desktop platforms would outweigh the costs of having to maintain two backends, though).
  • Most importantly, SDL2 is actively maintained and backed by companies like Valve. That is, in my view, the thing that makes it a much better long-term bet than OpenTK.

So? What's the plan from here? If SDL2 is to be done, the first thing to do is to eliminate the use of SDL1.2. Things like the new Song implementation can be added in, and some work would need to be done to at least hide the existing joystick implementation behind an abstraction layer, if not stub it out totally. The other things that need doing before actually implementing an SDL2 backend (I agree that adding it as a new platform is probably the way to go) are refactoring platform/window management a bit and writing a c# binding for SDL2 (I'd suggest also copying over OpenTK's OpenGL bindings).

If an SDL2 backend goes ahead, I'd love to be involved. I'm a bit too busy to shoulder the responsibility of leading the charge right at the moment, but I'll keep maintaining the opentk-sdl2 branch in the short-term for those who want to use it. Even if nothing happens, I've plans to try to get some of the smaller, less controversial changes in the branch upstream. I'm not usually a C# developer, so there's probably a lot of sense in having someone with more experience with MonoGame and C# lead this if it gets off the ground.

-- David

Ethan Lee

As for SDL itself, it's pretty much what I, Ryan C. Gordan and Edward Rudd have used in every single port we've done for MacOS and Linux, and Valve is now probably the largest gaming corporation using it in their products.

I highly recommend looking for open source games using SDL. ioquake3, DarkPlaces and many more use this by default (dhewm3 uses SDL2 by default).

If you'd like any particular samples of something as it's done in SDL, let me know. When one of the most complex tasks in SDL is done via a single SDL_SetVideoMode, it's pretty easy to write up quick samples of things. :P

Steve 'Sly' Williams
Ethan Lee

You might be out of luck for mobile devices, but I wouldn't worry too much. It sounds like iOS and Android do pretty well on their own.

I mostly recommend this to unify the desktop environments, Windows (non-D3D) Mac and Linux. Mobile backends, being what they are, are probably going to need extra attention for their own SDKs anyway. SDL2 is capable of running on those platforms, but it's probably just out of reach for a Mono-centric project (SDL2 combined with Xamarin's mobile tools would probably be a complete train wreck, since everything needs to be in one executable on iOS).

Actually, I should ask about that too: We currently have WindowsGL, WindowsDX11 and Windows8 right? Was the idea to move Windows desktop to WindowsDX11 and phase out WindowsGL?

I worry about the multiple Windows backends, since they all seem to be there for the same-but-not-really purpose (Windows8 excluded). Would "SDL, Metro, iOS, Android/Ouya and Vita" cover all the bases? This would at least shrink "Windows desktop, Mac, Linux" down to one folder, which is nice.

What will really help identify what platform is using what libraries is creating an intermediate layer between the XNA implementation and the platform code. I very strongly suggest reading SDL's source code. If there's a way to do it right, it's done in that library. Even if the SDL2 backend is rejected, it'd be a good way to make it easier for new devs to hack at one platform without irreversibly breaking another.


// operation.c
void PLATFORM_PerformOperation();
void performOperation()

// Found in platform/platform_operation.c
void PLATFORM_PerformOperation()
    // Actual stuff

Is more readable than you might think.

David Gow
sulix commented March 19, 2013

I'd definitely check out the SDL wiki as well:
In particular, the Introduction and APIByCategory pages will give you a good handle on what the library is and what it offers. Also look at the include files, which are really well documented:

Officially SDL2 hasn't been released (which is why the webpage still talks about SDL1.2), but it's been in pretty heavy use recently, is very stable and is being prepared for a formal release now. The ABI is locked, as well, so changes won't break any C# bindings. Valve are recommending it as the library of choice and are using it in all future titles, and Double Fine have started porting their engine over to use it across all supported platforms (the Mac/Linux releases of The Cave already use it), amongst others.

There are (I believe) a couple of iPhone games that've been released with it, so I wouldn't totally discount using it for mobile, but I imagine you'd want Xamarin's support before making it the default. The great thing is, of course, is that having proper platform abstractions in place would make any changes really easy.

-- David

Tom Spilman

Frankly, the number of #if DIRECTX and #if WINDOWS_STOREAPP
declarations around certainly turned me off the project a bit.

Just so you know... that is by design.

There was a time when MonoGame development on a new platform was:

  1. Copy class into new platform folder.
  2. Modify class for new platform.

That lead to differences on every platform. Something would be fixed in platform A, but still broken in platform B. On platform A it throws and exception if null is passed .... on platform B it does an assert and crashes at runtime. On platform A the class has documentation... on platform B it does not. On platform A the class implements IDisposable on platform B they forgot to do it. On platform A DynamicIndexBuffer exists... but no one implemented it on platform B.

Moving to a single implementation with #ifs solved all these cases, made missing implementations more visible, removed a ton a duplicate code, and greatly reduced the size of the code base.

And while in most places #if is fine... i agree that the situation is disturbing in some more complex areas of MonoGame. These can be solved by restructuring the code a little and being a little smarter in our implementations... but this has been a pretty low priority compared to things like content pipeline and testing framework.

Tom Spilman

proper platform abstractions in place would make any changes really easy

MonoGame itself is a platform abstraction. A platform abstraction within a platform abstraction is not the right path.

Ethan Lee

That's probably why the code is such a mess for people looking to add platforms. I say this mostly from experience as a multiplatform porter, rather than just a software developer in general.

MonoGame would best be looked at as a high-quality XNA framework implementation first, with easy-to-add platform support acting as one of its features. MonoGame is implementing a library used at a very high level, trying to jump right into the low-level stuff from the start gets ugly fast.

Compare my XACT code in the branch diffs above to, say, writing pure OpenAL in those areas. There's a reason it was written that way.

I guarantee you that there are two types of enthusiasts looking at a project like this one: people who just like the XNA framework, and people who want to get the XNA framework on more platforms. Letting these two parties work freely without the burden of the other party's activity is advisable. Those participating in both parties should, by design, be considered the exception rather than the rule.

Otherwise, you'll keep bumping into folks like me... ;P

Andy Korth

Two brief notes: while there are loads of problems with OpenTK windowing (and in my experience mouse and keyboard input also), many projects like MonoGame already have workarounds for all of those. (which is how I realized that most projects that are using openTK aren't using it on the Mac for input, at a minimum.)

However, the fancy typesafe opengl bindings that OpenTK provides are easily separable from the rest of the project. I get a vague sense that these are the most valued parts. If most of what you need is just the ./Source/OpenTK/Graphics/* stuff, grab that and drop the rest.

OpenTK also provides Windows Forms and GLControl stuff, it's completely unclear to me how that's used. The OpenTK forum gets a lot of questions about that part.

And finally, OpenTK has a bunch of math libraries. It looks like MonoGame doesn't use them.

A (very) quick scan of MonoGame suggests only the following parts are used: OpenAL, OpenGL Bindings, GameWindow (only within OpenTKGameWindow.cs), some of the stuff around listing display modes, and the OpenTK list of keys on the keyboard (for windows and linux only). So the good news is that most of OpenTK would not need to be replicated, just a few specific parts.

I'm pretty sure there isn't any mobile support in OpenTK other than a single define that sets it basically in Minimal mode for iPhone. That just provides some basic System classes for targets like MonoTouch. I think OpenTK covers any bases that other libraries don't.

And finally, I've had great experiences with GLFW. Just to throw that in for consideration.. I'll let you guys compare it to SDL2.

Steve 'Sly' Williams
Tom Spilman

Compare my XACT code in the branch diffs above to

I couldn't find the specific case you mention, but I suspect you mean abstraction via interfaces.

The core problem i have with interface based abstractions is that they are inherently slower. Calling an interface method requires a double pointer dereference.

             MyClass.Bar(); // A method call on a class.
00000032  mov         rax,qword ptr [rsp+20h] 
00000037  mov         rax,qword ptr [rax] 
0000003a  mov         rcx,qword ptr [rsp+20h] 
0000003f  call        qword ptr [rax+60h] 

            IMyClass.Bar(); // a method call thru an interface.
00000042  mov         r11,7FF000400A0h 
0000004c  mov         qword ptr [rsp+38h],r11 
00000051  mov         rax,qword ptr [rsp+28h] 
00000056  cmp         byte ptr [rax],0 
00000059  mov         rcx,qword ptr [rsp+28h] 
0000005e  mov         r11,qword ptr [rsp+38h] 
00000063  mov         rax,qword ptr [rsp+38h] 
00000068  call        qword ptr [rax] 

So you are trading easy of adding platforms for you and I... for lower performance for every user of MonoGame. I just don't find that trade off conceptually appealing... "lets make this easy for me and just a little slower for everyone else"... I just don't think that is the right way to approach things.

Now we could maybe find just the right place to put an interface to minimize this overhead. The impact could be fairly small and only noticeable in the most demanding games... yet the overhead is there.

with easy-to-add platform support acting as one of its features

That would be a nice goal to add... but it has never been on any roadmap. Mostly because it is pretty simple to add a platform right now and few people have every needed to do it.

Still i think we can make it easier to add platforms without compromising performance at all.

Ethan Lee

Hm... Maybe make the platform interface static? Not sure how that'd look, and this is also coming from someone whose library work is primarily in C where that's the only option anyway.

David Gow
sulix commented March 21, 2013

Okay, so what's the plan?

As I see it, there are really two issues here:
1. Cleaning up the MonoGame codebase and making it easier to add platform support, and
2. Investigating and (if feasible) implementing an SDL2 backend.

These are fairly orthogonal, even if it's decided not to use SDL2, having a cleaner codebase can only help MonoGame. It'd be ideal to have things looking nice before adding SDL2 if possible; it'd be annoying to write code only to refactor it immediately.

The obvious things to to then are to:

  • Start refactoring MonoGame, especially the problem areas like window management.

Normally, I'm a sucker for cache coherency and minimizing pointer dereferences, but personally, I don't think that the performance hit taken by using interfaces is significant to a project like MonoGame. There are other things that can cause much bigger performance problems: ensuring that we don't (for example) create and destroy lots of objects per-frame makes much more of a difference, especially with mono's garbage collector. #if statements are really a sub-par solution and the productivity gain from using interfaces would mean people would have more time to add features and fix bugs (including performance issues) where it really counts.

  • Start work on SDL2 bindings for C#.

The ABI for SDL2 is locked, so once they're done, they'll be very low maintenance. We can steal the GL bindings from OpenTK, and then none of the OpenGL code would need rewriting.

The opentk-sdl2 branch has some (very hacky) bindings, but parts of them (like the enum and struct declarations) should be useful if people want a head start.

  • So? What will I be doing?

I'm going to be maintaining the opentk-sdl2 branch for now (though I'll also throw some code for the above things when I can, too). There are some projects using opentk-sdl2 and I don't want to leave them stranded. It's also a good example of what SDL2 is (you can have a look at the code to see roughly how opentk and SDL2 differ) and how it works. Perhaps try building a project against it (and its companion MonoGame branch) and see if things work. There's also a (slightly buggy) OpenAL streaming implementation of Song in the opentk-sdl2 MonoGame branch, which could be a bit of an inspiration for a generic streaming interface within MonoGame (it's about a whisker's width away from having pluggable decoding backends).

I'm going to be keeping a close eye on this thread, and might even drop by the MonoGame IRC if I get some time, because I'd love to see the things we're discussing go ahead. I just wish I had more time (and C# expertise) to be more involved than I am.

-- David

Tom Spilman

having a cleaner codebase can only help MonoGame

I agree... but it is pretty low priority right now.

There are other things that can cause much bigger
performance problems:

Yes... and we work hard to solve those as well.

the productivity gain from using interfaces would mean people
would have more time to add features and fix bugs (including
performance issues) where it really counts.

I think the productivity gain you mention here is greatly exaggerated.

using interfaces

If you have the time can you take like one class... lets say VertexBuffer.... and show me specifically what you mean by using interfaces?

Dominique Louis

Just on the point about Interfaces....

I have to agree with Tom on the speed of interfaces. I realise that interfaces are very fashionable, particularly in IoC and other design pattern circles and I think for business apps they are great. But ( isn't there always ) we are already taking a hit because we are using C#, but right now that is a relatively thin layer to what is underneath it and the flexibility of using the language make up for the slight hit. Adding Interfaces to the mix will slow things down further. Please remember that we are targeting mobile devices as well with this codebase, not just desktops, so any extra overhead may limit MonoGame's appeal.

I would be in favour of making what we have performant first, across all platforms, then if we have clock cycles to burn, look at where in the code base we can make use of interfaces, without impacting overall performance.

My thrupence worth.

Ethan Lee

Writing this first...

... then an SDL2/ backend that will likely be separate from Desktop/, Windows/, Linux/ and MacOS/. Help with SDL2# is appreciated, as there's a lot of stuff to write there... not difficult, just very tedious.

Ethan Lee

We've almost finished the first draft of SDL2#. Everything's been written except for SDL2_net, which we may just drop since Lidgren.Network exists, and some bits and pieces of SDL2 input. We could use some testers though, so if you're familiar with SDL2, definitely try it out and post the results on the issue page:

Ethan Lee

Here's SDL2# in action, our first official screenshot:

We dropped SDL2_net because Lidgren exists, so input is all that's left before we hit Alpha. Beta will be adding OpenGL/OpenAL support, probably adapted from OpenTK for MonoGame compatibility (I would, however, like to make the API similar to the LWJGL bindings after 1.0 hits and MonoGame's working on SDL2#).

Ethan Lee

SDL2# Alpha 1 is out:

Alpha marks the completion of the SDL2 bindings, Beta will mark the completion of OpenGL/OpenAL bindings. We plan to use OpenTK's bindings to make the MonoGame port easier.

OpenGL Issue: flibitijibibo/SDL2-CS#6
OpenAL Issue: flibitijibibo/SDL2-CS#7

There may be some bugs in Alpha 1, so definitely report any you find. It's not particularly useful for MonoGame yet without the GL/AL bindings, but it's never too late to learn your way around SDL2... :P

Ethan Lee

Actually, that's a lie (and this is a double post, apologies): If anyone wants to experiment with using this over Tao.Sdl, definitely give it a go. You could in theory replace the Tao SDL joystick support with SDL_GameController now, if you wanted to get Big Picture support in ASAP. For Linux, You can replace Tao.Sdl.Mixer with SDL2.SDL_mixer without any fuss.

Steve 'Sly' Williams
Ethan Lee

Consistency with the C headers. Basically going the Tao route.

Steve 'Sly' Williams
Ethan Lee

The OpenTK adaption is a short-term strategy. I'd like to move the GL/AL bindings to the C style later on (again, like Tao), but this will allow us to keep the not-broken code in MG while getting the actual platform backend working with SDL2.

Of course, as the only developer/maintainer of the SDL2 backend for MonoGame, I suppose it would make sense for me to just do it the way I'd like to, so as to get it done faster, right? I do have three games waiting on this, after all...

For the express purpose of experimentation, I'm only going to let SDL2# devs make decisions on SDL2# matters.

Ethan Lee

Turns out the OpenAL implementation OpenTK had was pretty self-reliant, already happy and working in SDL2#:


Getting their OpenGL bindings working with SDL2 is definitely going to take a bit more effort, though. Once that's done, a MonoGame backend can finally start. The initial MonoGame-SDL2 development will be using the SDL2# Beta, but I suspect that this work will find a couple issues we've missed in our test apps.

Also noteworthy is that the SDL2# backend will be in my production branch first, which has a number of fixes you can read up on by simulating a pull request with my "monobroken" branch:

Unlike my shipping branch, however, I'm keeping this updated with upstream, since the things upstream broke are all in parts that I intend to make obsolete.

I'll make a pull request with this work isolated eventually, but only when it's really done.

Ethan Lee

flibitijibibo/SDL2-CS#6 (comment)

OpenGL bindings are there, no idea how stable it is.

Ethan Lee

Probably feels a bit early, but SDL2# Beta 1 is tagged: flibitijibibo/SDL2-CS@2a2bdc2

Beta really marks feature-completeness rather than stability (RC1 will mark that), but it should now be possible to port MonoGame to SDL2#. Once I get this port going I'll likely make a very early pull request, as this will be replacing four platform folders with one, and replacing two libraries (three if you count OSX-specific MonoMac stuff) with one. I'm guessing many of you will want to try this on WindowsGL, if not OSX/Linux.

Steve 'Sly' Williams
Ethan Lee

I refer you to the previous statement regarding SDL2# management.

Here's some stuff I need done:


Won't be starting the MonoGame backend until the weekend, so you've got a 2 day head start if you pick that one. The test suite's unassigned at the moment.


Naming, coding style & the like are often a sensitive subject among developers and although I hope to be wrong, I'm foreshadowing some conflicts here so I thought I'd jump in. I hope nobody minds, I'm just trying to help in my own small way.

My understanding is that @flibitijibibo is writing SDL2# as his own project, not exclusively for MonoGame (there are other use cases), but with a clear interest in getting it used in MonoGame. He decided to not play nice with .NET coding conventions but rather stick to SDL's naming. This is explicitely stated in the README:

SDL2# is a pure port of the C headers. The naming schemes for this library will
be exactly as they are done in the C library, with little-to-no concern for
"appropriate" C# style.

@flibitijibibo: My guess is this is probably more comfortable for you, maybe you're more versed into C naming standards and feel like going back and forth between the same API exposed differently in C/C# would be cumbersome / less productive for you?

@slygamer: Obviously you're very much entitled to your opinion on the matter (and even, I guess, to vetoing the integration into MonoGame, seeing as you're a core team member). The way I see it, SDL2# is still an external library written by someone else who put a lot of effort into it, so considering it as an external project, I don't think you'd go tell the OpenTK devs (if it were still maintained) or the Lidgren.Network maintainer how their library should be built / what conventions they should use and so on.

What I'm saying is: maybe it's worth voicing your concerns regarding naming on more technical grounds (why you think it's important and how it's going to help with productivity / maintainability / extensibility, whatever) rather than simply stating that using .NET naming standards is what MonoGame does.

Now to give my own opinion on the matter: I think if @flibitijibibo is going to maintain the SDL2# bindings, he should be the one making the final call as to the project's coding style. I think it's really important to have consistent naming / coding style in a particular project but across projects, concessions can be made.

That said, I think making SDL2# an idiomatic .NET port would be more beneficial to the .NET community at large and would make it integrate more seamlessly into MonoGame. It might be a simple matter of using .NET naming conventions (or it might involve some deeper changes in the API but probably not).

The question becomes: is SDL2# meant to be a nice bridge to the .NET world for C developers, or a nice bridge to the C world for .NET developers? I can certainly understand why MonoGame devs would rather work with a library that feels .NET-y, but if it isn't, isn't it still very much worth integrating for all the stability improvements/fixes we get from SDL2's battle-tested codebase?

Ethan Lee

Finally getting to this port: flibitijibibo@3ebe185

Reason for the delay: Added another MonoGame port to my list. I've now got 4 games using my develop branch (possibly more, still looking for XNA4 ports to fund this with)... here's hoping SDL2# doesn't shake things up too much.

Ethan Lee


The commit message probably says it all, but feel free to read the changes too...

Is there any documentation on adding a platform, because I gave up on trying to rework the OpenTKGameWindow/Platform a while ago, but I have no idea what's supposed to be called when, how the GamePlatform interacts with anything, or... yeah, commit message.

Ethan Lee

Still need to handle the event loop, but MonoGame itself seems to be working. And, would you look at that, ApplyChanges actually does its job right out of the box, without any hacky crap!

Really, the event loop is for anything that's not Mouse input or Joysticks, as those two are already working. Keyboard, TextInputEvents, etc... we'll see how this goes.

Dean Ellis
Ethan Lee

Yes, I am basically making an SDL2 platform that is self-sustaining; no files from Desktop/, Linux/, MacOS/ or Windows/ are used. This will make it much easier to transition those platforms to SDL2/, then those 4 folders can be eliminated in an entirely different commit.

I highly recommend not wasting your time with OpenTK any further, since I'm set on making OpenTK obsolete in one blow.

Let me make that clear: OpenTK will be entirely unnecessary when SDL2# is being used. There will be zero benefits to the OpenTK backend other than "it existed for slightly longer". Tao is in the same boat, and I'm also making the MonoMac backend unnecessary as well.

Native SDL2 binaries currently need to be built from Mercurial, unless you are using the Steam runtime on Linux, where you'll be using Valve's libraries (if you desire). Sam Lantinga and Valve are aiming to release SDL2 2.0 in May, where you will be able to download SDL2 from

As a sidenote: For Linux, you should NOT depend on distro dependencies unless you plan to distribute your application as a source package. Bundle your own libs with your application; MonoKickstart is actually designed to have the libs in lib/ and lib64/, and for a very good reason.

Dean Ellis
Ethan Lee

Xamarin's attempt to scam people out of exorbitant amounts of money for bundling libmono as a shared object is totally bogus, just FYI. I'm still very annoyed by their recent DRM addition to MonoDevelop OSX...

For MonoKickstart, you basically just take the Kick.bin files, rename them to the name of the main exe, then it will run that Mono application and use the native libs found in lib/ and lib64/. If you want, you can take Edward's precompiled binaries and include precompiled libraries in lib/ and lib64/; I typically do this when giving clients MojoSetup packages and Mac app bundles. You can also see this in my Chasm Linux patch, found here:

That bundle should work with any MonoGame Linux title, as long as you rename the bin files and edit the launcher script (./Chasm) according to your game name. You could probably automate this, if you wanted to.

You can keep OpenTK.dll for iOS/Android if you want, but for the desktops it won't be necessary. This backend is purely for desktops, though I don't doubt the possibility of using it in other places as well.

If Xamarin have broken compatibility with TK GL/AL, I'll probably need to update my MiniTK component of SDL2# to their bindings (where is their repo, anyway?), but otherwise I should be able to stay compliant pretty easily. I would actually be really interested in Xamarin having a look at SDL2#, since the SDL2 license probably fits with their business model and target platforms a little bit better than SDL 1.2 did.

For the SDL2 binaries, I'd hold off on that until SDL2 2.0, when the official binaries will be posted. Otherwise you're going to put a lot of unnecessary bulk into the Git history.

Ethan Lee

Just added a new perk to the SDL2 window: Fullscreen resolutions are all done in an FBO, the desktop resolution never changes from the original:


Prevents a lot of pain when dealing with various window managers. Windowed mode is still its usual self.


Let me make that clear: OpenTK will be entirely unnecessary when SDL2# is being used. There will be zero benefits to the OpenTK backend other than "it existed for slightly longer". Tao is in the same boat, and I'm also making the MonoMac backend unnecessary as well.

I have been following this thread on and off thinking this could be an interesting idea as a separate "platform" in order for MonoGame to get more contributors who might be more familiar with SDL.
The primary goal for OpenTK in MonoGame is to provide OpenGL bindings. If you look at the develop branch, the window management part is almost entirely custom and only tries to mimic XNA 4.0 behavior; granted this is not yet the case on all platforms (Android still uses OpenTK's helper classes) but this is definitely something I would encourage in order for MonoGame to grow independently of any other API restriction or maintainer's will.
My humble, yet slightly educated recommendation would be to direct our efforts into encouraging "official" OpenGL C# bindings (as well as other Khronos APIs or any native API we need) and keep XNA as our "design guideline" since this is how MonoGame came to life; this doesn't prevent it from being extended in the future and maybe take some design cues from SDL 2.0, but from my point of view it seems like we would be trading the quirks and restrictions of one API for the quirks and restrictions of another.

Ethan Lee

So I've currently got all my Mac/Linux games running on monogame-sdl2 now... that branch is now worth testing if you have those platforms on your roadmap. If you want to try this on WindowsGL, definitely send a pull request with the fixed csproj file.

Also, something I appear to have accidentally added during this port: retina display support. So there's another bonus.

Ethan Lee

Modified the WindowsGL project to use the SDL2/ folder. It has not been tested, but it should at least build.

Ethan Lee


I believe rumble support works in MG-SDL2 now, but it doesn't have left/right motor compatibility at the moment.

Dean Ellis
Ethan Lee

The "official" pull request will probably have them set up as SDL2.Windows, SDL2.MacOS and SDL2.Linux, since there are still a few platform defs left in the project (save locations, Threading.cs, etc). I would ideally like to eliminate all WindowsGL/Mac/Linux defs, but I haven't quite found a way to do that yet.

Dean Ellis
Ethan Lee

Ah, now that would definitely clean things up a bit.

I'll probably poke at this in a few spots, thanks for pointing this out.

For the Threading issue, On SDL2 we'd like to just use SDL_GL_MakeCurrent, but apparently OSX isn't entirely happy with this, as we get a few missing textures on output. It seems to be more stable when we use the current MonoMac solution of performing the action() on the main thread.

Here's the SDL_GL_MakeCurrent spot, the Mac platform def is pretty much the same:

Ethan Lee

So with that new info I tried to eradicate pretty much every LINUX and MONOMAC def check I could find. At this point, there's only three left:

  • Threading.cs. As mentioned earlier, MonoMac's struggling with SDL_GL_MakeCurrent for some reason.
  • TitleContainer.cs. This one I'm unsure of, since we kind of need the NSBundle.MainBundle.ResourcePath, but I think app bundles already put us in Resources/? At least, that's what I've seen, I haven't thought about this very much.
  • Graphics/Texture2D.cs. For SDL2 we can just save these with SDL_Surfaces and System.Drawing.Bitmap, but I've not taken the time to reimplement that stuff for SDL2.

If we knocked these three out, we could definitely have a single MonoGame.Framework.SDL2.csproj that works on Windows, Mac and Linux without a problem.

Ethan Lee

Threading.cs and Graphics/Texture2D.cs have been taken care of. TitleContainer.cs is all that's left before you can build MonoGame for OSX SDL2 without MonoMac as a dependency. If anyone has an idea of how to fix it gracefully, let me know.

Tom Spilman

TitleContainer.cs. This one I'm unsure of

The goal of using NSBundle.MainBundle.ResourcePath in TitleContainer is to form a full path to the requested file as we cannot depend on the "current working directory" to be correct.

As long as any change there continues to form a full path (most of the times this is an absolute path) then it should be fine.

Ethan Lee

Somewhat off-topic, but a fun thing I did this morning: ported Fez to the MG-SDL2 backend:

There are problems for sure, since it's a hacked up mix of my branch and his, but it's a neat little thing to show off bits and pieces of the SDL2 backend a bit.

elisee commented May 01, 2013

Very excited to see all the progress you're making @flibitijibibo :). Keep up the great work!

Ethan Lee

I'm starting to make a MonoGame.Framework.SDL2 solution in my branch, it seems happy on both Linux and Mac, not sure about Windows yet. If someone wants to look at it, that'd be awesome.

Also added GameController support, so if you load your game up through Steam it should pick up Big Picture configurations now.

elisee commented May 02, 2013

Cloning now, I'll try it out on CraftStudio for Windows

elisee commented May 02, 2013

Is there any place I can find SDL2 Windows nightly builds? or do I have to compile it myself?

I was about to do so but SDL_xaudio2.c fails to compile without dxsdkver.h and if I can, I'd rather avoid installing the DirectX SDK.

Ethan Lee
elisee commented May 02, 2013

Thanks, now it's complaining about SDL2_mixer.dll missing.

Ethan Lee

If you want to skip the SDL2_mixer bits, you can actually comment out the SDL_mixer.* calls in SDL2_GamePlatform.cs; as long as you don't use Songs it should be okay. I was considering moving that to CSVorbis, but considering the VideoPlayer already uses the native Vorbis libs... eh.

Those parts probably won't be in the SDL2 pull request, by the way. Those are just features I have for my ports; I'll probably submit those at another time.

Ethan Lee

Right, so all of the parts I used in my current 5 games have all been redone with MonoGame-SDL2. At this point I'd like to also implement the things that I might be missing from the old WindowsGL/MacOS/Linux implementations, so if you find something missing from my backend that you need, let me know if you don't want to write it in yourself.

Ethan Lee

10 days without an update! Nonsense!

Well, not really. Most of my work has just been in irrelevant parts, like the VideoPlayer.

I would like to share this little tidbit, related to the MonoMac part. Namely, the fact that it's no longer required for an XNA game on Mac.

I updated MonoKickstart to run on OSX, so if you have a project running on MG-SDL2 you can just poke it into a Mac app bundle with the MonoKickstart stuff prepared, no special Mac attention needed.

Since the game itself no longer needs MonoMac material, we can do neat things like this:

Those are the GOG bins running with my MG-SDL2 backend.

If you wanted to distribute on the App Store you would still need to buy the rights to Mono from Xamarin, but if you're like me and don't care even slightly about the App Store you can compile once and run your game on Windows/Mac/Linux without any problems.

"Write Once Play Anywhere" is lame, "Compile Once Play Anywhere" is where it's at. :P

Morrison Cole

@flibitijibibo It's been a while since I touched MonoGame (exams, y'know), but I have to commend your progress on SDL2. Awesome.

I'll test Parapraxis with this as soon as I get the chance.

Edit: SDL2 nightly isn't available pre-compiled, you can build it from source at

K900 commented May 21, 2013

I just wanted to chime in and give some input from a new user perspective. Feel free to ignore.

So, I'm working on a little physics simulation thing. Not really a game, but close enough - 3D graphics, controllable camera, input etc. I wanted to try MonoGame, because I've heard good things about XNA, and MonoGame was supposedly a portable version of that. I heard some bad things about Linux portability, too, but decided to go the official way first. Get MonoGame from this very repo, write some code, run on Windows - woo, it works. Switch to Linux... OH GOD NO. No joystick input, the window does weird things to KWin, no nothing. This was about a month ago, though. Maybe things have gotten better, I don't know. Meanwhile, @flibitijibibo's MonoGame branch became usable, so I decided to try that. Clone, build, magic. It just worked. This alone is a great reason to support SDL2 in my opinion, especially for a framework that has a reputation for being beginner friendly. F***ing around with OpenTK is anything but beginner friendly.

Jordan S

Interesting, i might try my game on @flibitijibibo's MonoGame SDL2 linux aswell and report findings here, I had some problems with the OpenTK version aswell.

John Colgrove

First off, I just want to apologize if this has already been discussed. I don't really want to read over 70 comments if my concern was already addressed.

The only concern, as a new user, to me would be if I start a project with OpenTK and have to make the switch to SDL2, will my code easily port over? If I were much more experienced than I already am I might not be as concerned, but either way my concern is still valid. After all, I don't want to spend more time porting than I have to at the moment.

Ethan Lee

It should work without modification, assuming you've not broken your XNA code for MonoGame upstream.

If your project is XNA compliant, you should expect MG-SDL2 to, as K900 put it, just work.

I would definitely like people to try this branch out and post what they find. I suspect a lot of you are using things I didn't implement (TextInput, things like that), so if there's something missing, let me know and I'll try to add it (or you can send a pull request my way, you'll probably want to test the addition anyway...).

I currently have 5 games running on MG-SDL2 (adding a sixth soon), so I think this is pretty solid, but I didn't check to see what the OpenTK/MonoMac backends offered when I made the SDL2 backend.

Ethan Lee

Related topic: MG-SDL2 currently uses SDL2_mixer for Songs (Vorbis format). For me this isn't that big of a deal, since I just self-build all of the libs for Mac/Linux, but for Windows users in particular it's probably a big pain to have to carry this lib around, possibly for nothing.

I thought about just using csvorbis and OpenAL, but my VideoPlayer requires TheoraPlay, which means that we're carrying the native Ogg Vorbis libs in our package... having two VorbisFile implementations seems goofy (again, for me this works out since SDL2_mixer uses these libs as well).

Looked around this morning, found this decoder that uses the native libs:

I don't think I'll be able to write this in, but if someone's particularly annoyed by the SDL2_mixer dependency, this is probably a good replacement (you'll want to change how they do the DllImport library names though, yuck). I think @sulix still has his Song decoder thread that uses stb_vorbis, so if you want to just take his Song and rework it to use OggVorbisDecoder (I kinda wish it was called VorbisFile#) it should be a pretty easy port.

Steve 'Sly' Williams
David Gow
sulix commented May 21, 2013

The OggVorbisDecoder project does mention a commercial use exception to the GPL (which seems to be a dodgy way of getting someting LGPL-like?), so it's probably okay to use it, though there might be issues on mobile. I'm a little bit sceptical about it, though.

The Song implementation I have in the opentk-sdl2 branch of my MonoGame repository (under Linux/Media) should be pretty portable, though it could certainly do with some polish. It actually is separated into two parts: the Song class, which handles OpenAL/streaming and the VorbisSong class, which decodes ogg vorbis files using stb_vorbis/STBVorbis-CS. It shouldn't be too difficult to add/modify the backends to decode more or different types of files with different libraries. Let me know if you're going to try to use it: I'd be happy to help clean it up for you.

What (I think) is the best long-term goal "Song" wise is to implement a generic streaming mechanism which can be used by Song, Video and XACT if needed. Code reuse: it's cool! Using OpenAL instead of SDL2_mixer would stop the game from making two separate connections to the sound server/soundcard and fix the problem of having the game show up twice in the mixer.

Just some thoughts. :)
-- David

Steve 'Sly' Williams
Ethan Lee

Well, as long as you guys don't mind building SDL2_mixer I don't really care what you do.

It's also worth noting that the license info on the page appears to be either out of date or just incorrect, as the headers of the source use the BSD license.

Ethan Lee

Also, my issue with the DllImport libnames was simply that he was using "Externals/libName.dll" rather than just a "libname.dll" with a dll.config for his dedicated folder. Even I know how wrong that is... or rather, how irritating that is.

Ethan Lee

Here's a "fork" of OggVorbisDecoder that removes any parts not explicitly under the BSD license and replaces them with files I wrote from scratch, so we can be sure that the whole library is free to use in MonoGame-SDL2. It also fixes the little things like the native lib names, and includes a Makefile.

If you do this port, be sure to add this as a submodule in ThirdParty/ like I did with SDL2# and TheoraPlay#, and add it as one of the projects in MonoGame.Framework.SDL2.sln.

Ethan Lee

SDL2 is in RC1:

Downloads to the runtime libraries are included, here's the directory:

Linux can self-compile, and while they do have a prepared OSX build, I recommend self-building on OSX as well.

Not sure if SDL2_mixer will get the same treatment right away, but I'll let you know if it does.

Ethan Lee

Capsized has just shipped in Humble Indie Bundle 8 with MonoGame-SDL2 on Linux and Mac:

No OpenTK, MonoMac or Tao. All SDL2#. Aww yeah.

This is the first of many MG-SDL2 titles I plan to ship this summer, so keep an eye out for them! :)

Alisson Cavalcante Agiani

OMG this is amazing!

Jordan S

How well does SDL2# support 64-bit? anything I should know about?

David Gow
sulix commented May 28, 2013

SDL2# supports 64-bit fine. Capsized for Linux includes both 32-bit and 64-bit builds!

If you're developing yourself, you should just need to make sure that the version of mono you're using is the same bitness as the SDL2 libraries you use.

-- David

Jordan S

Ok, thanks :)

Yannick Comte

I've pulled the SDL2 branch of @flibitijibibo and ported my game engine on it. It's great because it work very well on Linux or Windows with the same solution (no needs to have 2 solutions for Linux and Windows). I hope that it can be integrated in MonoGame official branch :)

Ethan Lee

SDL2_mixer hit RC1 on Sunday:

Now that this is out, you should be able to use precompiled SDL2/SDL2_mixer DLLs on Windows MG-SDL2. OSX has precompiled bins, but I still recommend self-building (or just taking from one of my games, like Capsized... I don't mind!). No excuses at this point, I hope! :P

Hoping to announce a whole batch of MG-SDL2 games in the month of June... I'm still interested in seeing other people give this branch a try! I've still got my issues page open; I encourage you to file a bug report first before changing any code in the branch. A major goal for MG-SDL2 was to avoid excessive forking; one branch working for every game is the way it needs to be.

So far Capsized has gotten only a couple bug reports that were related to MG-SDL2 (all of these issues have been fixed), so it's looking pretty good!

Ethan Lee

New port announced: Gateways Mac/Linux is coming out on July 16:

... And I'm still using MG-SDL2. This was actually the first game to run it, but it ended up working so soon that Capsized got to debut with it instead.

K900 commented June 05, 2013
Ethan Lee


Since it was bothering a lot of people, I pushed the SDL2_mixer dependency as far back as I could. If you do not use Song, you no longer need SDL2_mixer. If you use Song and still don't want SDL2_mixer, I'd love a libvorbisfile/OpenAL port.

This means that the minimum required native dependencies with MonoGame-SDL2 should now be SDL2 and OpenAL. Hopefully that's a short enough list for everyone. :P

Ethan Lee

TextInput for MG-SDL2 is a thing, courtesy of @xanather. A bunch of stupid things I did in MG-SDL2 were also fixed in the process, so try it again if you were having problems with, say, exiting your game.

Ethan Lee


Since it seems to be on every driver/card now, MG-SDL2 defaults to smart vsync when available.

More on EXT_swap_control_tear:

(Not sure where Apple's doc is on this, but it does work on OSX.)

Ethan Lee

Something I learned this weekend: as long as you're smart and stay away from MonoMac and System.Windows.Forms, you can actually use a 64-bit Mono runtime on OSX. So, I'm updating Capsized and all my other games with Universal Binaries for all the native bins/libs, since all of the libs MG-SDL2 uses are available in 64-bit form.

As far as I know, this makes Capsized the first 64-bit OSX MonoGame title. Pretty neat, I guess.

Alisson Cavalcante Agiani

Dude, these games should be highlighted on the official Monogame site!

Ethan Lee

Minor change, but since MonoKickstart is now a pretty important part of MG-SDL2 for more than just Linux, I'm now using my repository over Edward's in the ThirdParty directory:


My repo has a couple other updates, but nothing major. The OSX bins are what's important.

Ethan Lee

Here's something I've not done since I started the MG-SDL2 port: publish the comparison between MG-SDL2 and the current develop snapshot:


As you can see, it's gotten pretty insane how different things are, despite it keeping up with upstream the whole way through.

However, MG-SDL2 is now at the point where all 8 of my active projects are happy with this code (and the other 2 won't be seeing MonoGame at all for some time), so it's probably time to look at making a nice pull request with what I've got.

As bad as it looks, there are a ton of things in there that are not strictly related to MG-SDL2, and can either be ignored or submitted as separate pull requests. I'll list them here, as a sort-of-issue-tracker-thing:

Should Be Pulled

  • Content/ContentReaders/SoundEffectReader.cs has MSADPCM support. This should probably be pulled, with the same platform conditions as the WaveBank MSADPCM support. MERGED: #1802.
  • Graphics/DisplayMode.cs includes a bugfix for comparing null DisplayModes. This should probably be pulled for XNA4 compliance. MERGED: #1801.
  • Media/MediaPlayer.cs adds ActiveSongChanged. This can be pulled if the parameters make sense. MERGED: #1800.

Might Be Pulled?

  • 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. ADDED JUNE 18, 05:30 EDT
  • 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. ADDED JUNE 18, 06:10 EDT
  • Content/ContentReaders/Texture2DReader.cs and Graphics/Texture2D.cs add a GenerateMipMaps() call for S3TC textures. Somewhat related to #1783. It's a crap solution though, I'd like something better if it's available.
  • 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?
  • Graphics/GraphicsDevice.cs adds an "Adapter" property. I have no idea what this actually does, I just added this in quickly for quick-but-possibly-incorrect XNA4 compliance. This could be pulled if it makes sense?
  • 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?
  • GraphicsDeviceManager.cs has a ToggleFullscreen FIXME that I actually wanted to ask about... I thought this immediately toggled fullscreen, am I wrong on this?
  • Threading.cs by default does NOT use multiple GL contexts to perform multithreaded rendering. Real talk: doing this is a terrible idea if you don't need to use it. Even the MonoMac solution kind of sucks (read: terminal gets flooded with "leaked resource" warnings). We offer the option to do this with THREADED_GL, but as it states in the source, you should feel bad for using it. This would affect Threading.cs and any GameWindow implementation. Right now this is only implemented for MG-SDL2; I will elaborate on this shortly. DEMOTED FROM Should Be Pulled. MG-SDL2 can have this alone.

Definitely Ignore

  • 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.
  • 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.

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 an MG-SDL2 goal that I will explain in a moment. 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.
  • I also moved Desktop/Input/ and Desktop/GamerServices/ to SDL2/. GamerServices went untouched, and Input stayed pretty much the same except for the files prefixed with "SDL2_". If anything in there used OpenTK input or Tao, it uses SDL2# now. A lot of those files, however, were not touched... kind of surprised some of them are not just in Input/.
  • SDL2/Media/Video.cs and SDL2/Media/VideoPlayer.cs are my Video support implementations that use TheoraPlay#. This is why you have to include this project in your MG-SDL2 solution... for the main MG-SDL2 pull request, this probably isn't necessary.

The Elephant in the Room

I totally annihilated anything that had (WINDOWS && OPENGL), MONOMAC or LINUX even near it. While the main MG-SDL2 pull request will probably not have this change, I am still very interested in seeing the deprecation of the WindowsGL, MacOS and Linux solutions, and the eventual removal of the Desktop/, Windows/, MacOS/ and Linux/ folders. As far as I know, the only other solution that depends on these folders is iOS, and that's just an Audio file that can be found in SDL2/Audio/.

One of the goals for MG-SDL2 was to remove platform defs, and anything that genuinely needed its own code would use Environment.OSVersion.Platform at runtime. This ended up removing a LOT of code, eliminated the need for several platform defs and I was successfully able to make MG-SDL2 a "compile once, run anywhere" solution. Since we can't have a good internal platform API, the best solution is to just not have platform code wherever possible. SDL2 handles that stuff better anyway (especially on OSX, as it turns out). Considering all three desktop platforms already depend on SDL 1.2 anyway, we pretty much keep the same number of native libs while trashing a ton of crap in exchange for one single, consistent backend.

Making this PR is going to be quite a bit of work, so before I even begin to put this together I want to be 100% sure that the core team wants this platform. Otherwise, I'd rather not waste anyone's time, since MG-SDL2 works either way. I've spoken to @dellis1972 about this very briefly, but I'd like input from the whole team.

CC: @KonajuGames @CartBlanche @totallyeviljake @tomspilman @Aranda

Steve 'Sly' Williams
Ethan Lee

I very highly recommend treating resource loading as a rendering call in OpenGL. Not every driver supports this as well as you might think. (In fact, there's a good chance that the supported drivers are a minority.)

Will look at the Adapter property a bit more closely.

Apparently the S3TC loading has problems either way, so I suppose I'll look at that too.

We already do this in the WaveBank in upstream, so like I said, same conditions as that use of the decoder.

Starting an app in fullscreen by default, without the user explicitly asking for it (either by an arg or by their user config), is something that irritates gamers, especially multimonitor users. On top of giving a bad service to customers, it can also trash display setups on Linux X11 and OSX retina displays if the game is not set up at the desktop resolution. Even with SDL_WINDOW_FULLSCREEN_DESKTOP, this can be a serious problem.

I am thrilled that the worst thing that can be said about my backend so far is that the backing library uses a C API for the C library it interacts with. If you want to avoid seeing this stuff in MonoGame's XNA work, a platform API would be a fantastic way to keep it in the platform backend!

Steve 'Sly' Williams
Ethan Lee

If you happen to have Gateways on Steam, I think you should be able to access the Mac/Linux betas, and those use the current MG-SDL2 if you want to poke around with those assets and check out the texture loading. The texture content files came from the XNA4 content builder, so that's what had me wondering. If the beta's not accessible, I'll see if I can get David to open it up a bit.

Jacob Anderson

For the record, Microsoft is retiring support for full-screen-mode in games. I don't have my reference handy, but I read about that last year. A full-screen game in Microsoft means something different than a "max resolution" game on Linux/iOS.

Tom Spilman

there are a ton of things in there that are not strictly
related to MG-SDL2, and can either be ignored or
submitted as separate pull requests

If there are good features that are independent of the SDL2 stuff then you should absolutely make one PR per-feature and submit them separately. If you submit one massive PR you can pretty much assure that it won't get merged quickly or at all.

If you think there are good fixes and improvements there then submit them to the develop branch.

the best solution is to just not have platform
code wherever possible.

Right... avoiding platform specific code is always the best policy.

that genuinely needed its own code would use
Environment.OSVersion.Platform at runtime

I'd like to see an example of that in your code.

This really only would work when the platform specific code can be compiled for both target platforms. So #ifs are still needed for other cases.

I want to be 100% sure that the core team wants this platform

If you're saying we can remove the following projects:

  • MonoGame.Framework.WindowsGL
  • MonoGame.Framework.MacOS
  • MonoGame.Framework.Linux

.... with a single GL desktop project that is a win i would love to have. Less platform specific code... less potential MonoGame bugs... sounds like a win to me.

My original issues have been largely solved.

  • SDL2 is now in release candidate status
  • Games are shipping with SDL2 now.
  • Your MiniTK facade means we can share more code with the GL mobile platforms.

With OpenTK we've been in a "waiting for Xamarin" state for months... i'm pretty much giving up on that.

So as long as your attitude is better than it was when this all started, I don't see why a PR for SDL2 couldn't be merged.

Since we're looking to release a new version of MonoGame around the end of the month, I suggest we setup a develop-SDL2 branch that we can merge your PRs into. This also gives us a place to test it all before we make the call to remove the old Linux/Mac/WindowsGL projects.

Ethan Lee

The platform detection at runtime so far has only been used in two places:

  • StorageContainer/StorageDevice, where we save to 'Documents/SavedGames/' on Windows, '~/Library/Application Support/' on OSX, and XDG_DATA_HOME for Linux.
  • Whoever wrote the XInput Haptic support in SDL2 forgot to make it work with SDL_HapticOpenFromJoystick, so we make a special case on Windows to use the device index over the joystick handle, the latter being more correct. I've opened this issue on the SDL2 end of things, may fix it along with the left/right motor support in SDL 2.1:

We did originally have that one case where MonoMac's starting directory made it hard to compile once for all targets, so that does come up... but finding ways around that hasn't been too bad yet; porting MonoKickstart to OSX ended up providing a lot of additional benefits in the long run (namely, not having to use MonoDevelop's still-pretty-borked app bundler, and the OSX toolbar looks a lot better too!).

Those three projects are the very ones I'd like to see removed! :D

Over the next couple weeks I'll start submitting the "Should Be Pulled" things, and I'll try to make the "Might Be Pulled" work more certain. The MG-SDL2 PR will likely be submitted after all of those things are in, since I can really only test all of this once the little things are in and there's less to compare (or stub out in my test cases).

Tom Spilman

porting MonoKickstart to OSX ended up providing a
lot of additional benefits in the long run

I'm not familiar with how that works on OSX, but if it is indeed better than what Xamarin provides then great.

I can really only test all of this once the
little things are in and there's less to compare

Right... github is great, but big comparisions/diffs/PRs are not fun.

Breaking things up how you suggest makes the most sense.

Ethan Lee

@KonajuGames I'm just checked out the Gateways Steam beta, needs to be opened up first... Once I fix that I'll let you know so you can poke at it. if you need a Gateways Steam key, throw an e-mail at me and I can send you one.

(Actually, that goes for anyone wants to look at the mipmaps issue with Gateways... Capsized was the game with the DXT1/DXT1a issue, hopefully everyone was able to grab HIB8 for that one.)

Dean Ellis
Andy Korth

I might take some of these ideas and rework the MacOS, Linux and Windows OpenTK platforms to merge them all into one (which is possible).

I, for one, would greatly welcome any such improvements to the OpenTK platform!

Ethan Lee

So merging that last XACT patch that @dellis1972 sent in ended up making the MG-SDL2 XACT work a whole lot more appealing. I dunno if it's just that the diff is smaller and it looks less terrible that way, but it now seems a bit more realistic to make that into something worth pulling. There are definitely still a lot of FIXMEs left in there, but a lot of them are more about missing features than actual bugs. If I can resolve all the "bug" FIXMEs, I'll add this to Should Pull later on.

In the meantime, I'll be sending the current Should Be Pulled stuff this week. Might Be Pulled is still uncertain, though Game.cs and GraphicsDeviceManager.cs only need to be verified by someone who's more familiar with XNA4 in those spots. Once all items in both categories have been resolved, I'll begin to make the primary SDL2 platform Pull Request, which will add MonoGame.Framework.SDL2 without affecting WindowsGL/MacOS/Linux. Those will be dealt with later on (though it sounds like someone wants to merge WindowsGL/Linux into MonoGame.Framework.OpenTK, and add Mac support to that backend? OpenTK.MacOS and MonoMac both use Carbon though, blech EDIT: Apparently MonoMac is Cocoa, it just looks like Carbon, nnnwoops).

Ethan Lee

I have submitted pull requests for all of the Should Be Pulled items. Pull requests #1800, #1801 and #1802.

I demoted the Threading.cs change, as this may just limit itself to MG-SDL2 depending on where the other projects go.

Ethan Lee

Added two new Might Be Pulled items:

  • 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.
  • 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/memory for nothing. Took it out, seems a bit faster, but I've not actually measured it.

These both struck me as odd, since they are really weird bits of code on their own, but I get the feeling that someone had something in mind for them. Were these just quick additions to get it working, or did someone mean to do something with it over time?

Unused parts related to bullet one:

Weird audio loading related to bullet two:, which uses

The commit to fix bullet one: flibitijibibo@0af8c29

The commits to fix bullet two: flibitijibibo@1b12851 flibitijibibo@a484397

The latter issue actually seems pretty widespread; there are lots of places where we're writing PCM data to a wav just to parse it back out later on.

This could probably be a whole issue in itself, but it's largely fixed in MG-SDL2 already.

Morrison Cole

Slightly off-topic, but I do think we should move this conversation to a new issue; it's getting ridiculously lengthy and many of the older posts are no longer relevant.

Jordan S

I'm very excited that MonoGame-SDL may be coming to the official monogame repository! :)

Ethan Lee

I agree with @MorrisonCole on the new issue bit. I've made a new issue on the MonoGame-SDL2 repository to track the various MG-SDL2 -> Upstream changes:


Developers interested in getting the MG-SDL2 changes (and the SDL2 platform itself) back into the main repository should subscribe to that issue.

I think we're pretty much in agreement on the OpenTK v. SDL2 deal. We can add SDL2 separately, then let them fight to the death on the user end.

Ethan Lee

New MG-SDL2 port, A Virus Named TOM:

Coming "soon" to a thing near a person

Also, progress on the MG-SDL2 merge may slow down a bit, since most of my work at the moment is unrelated (currently working on Steamworks#, for instance). The issue tracker is still here if anyone wants to poke at it themselves: flibitijibibo#105

Ethan Lee

Outlined the plan for next week in the MG-SDL2 merge tracker:

flibitijibibo#105 (comment)

TL;DR: I'll be looking at merging/reporting the MonoGame-specific things; if someone is familiar with XNA4 behavior, I'd appreciate some help verifying the XNA4 compliance fixes. It's just those two files, both of which are only a few lines a piece, but they may make a big difference when porting to MonoGame on any platform.

Ethan Lee

Gateways just shipped with MG-SDL2:

This is the game that spawned this change in MG-SDL2:

So if anyone's familiar with the DXT Texture2D stuff in MonoGame, this game's worth looking at. The quickest test is to look at the Help menu, which should look like this...

... but looks more like this...

There used to be an issue related to this on DirectX, but it affected OpenGL as well.

Capsized was also updated today to the latest MG-SDL2 library. It's been out for a while, but since I'm bringing up that texture bug I may as well bring this one up:



The current revision of MG-SDL2 should work with both titles, so feel free to mash up a custom version against both games.

Steve 'Sly' Williams
Ethan Lee

Aiming for SDL 2.0 Release to be this month. Once that's released, you can expect SDL2# and MG-SDL2 to remain compatible with the prebuilt binaries provided by the libSDL site. Any API changes after that release will be in a separate SDL2# branch, and additional features from SDL2 2.1 Hg will be def'd out with a preprocessor variable in MG-SDL2 (SDL_HapticRumble for left/right motor support, for instance).

Ethan Lee

New batch of MG-SDL2 ports: The MagicalTimeBean catalogue! That's Escape Goat, Soulcaster and Soulcaster II:

They'll be up on IndieGameStand tomorrow:

These games sparked the MSADPCM SoundEffectReader support, everything else was pretty happy out of the box. They did use System.Windows.Forms though, so I replaced that with pure SDL2# to avoid libgdiplus.

Dean Ellis
Ethan Lee

Additional feature for MG-SDL2: left/right motor support for GamePad.SetVibration:


We previously had haptic support, but today we added SDL_HapticLeftRight to SDL2, so we can specifically access the left/right motors for Windows/Linux now. (OSX does not support this, but we still have SDL_HapticRumblePlay as a fallback for controllers without leftright support.)

Ethan Lee

SDL 2.0 released this week:

I will likely be making the MG-SDL2 pull request in late September. There are a few more games I'd like to ship first, then I will make the final pull request. There are still two XNA4 compliance issues I'd like to resolve...


... but, if all else fails, I will probably just submit those in the MG-SDL2 request, def'd for SDL2. I'm also waiting on this pull request:


And then we can move the Desktop/Audio/ folder too (I think?), as I'm still hoping to eliminate the Desktop/ directory from MonoGame altogether.

Jacob Anderson

What I understand of my limited experience changing the dimensions of the XNA game is that every time you changes the size of the backbuffer the device would reset.

These changes:

        manager.GraphicsDevice.PresentationParameters.BackBufferFormat =
        manager.GraphicsDevice.PresentationParameters.BackBufferWidth =
        manager.GraphicsDevice.PresentationParameters.BackBufferHeight =
        manager.GraphicsDevice.PresentationParameters.DepthStencilFormat =
        manager.GraphicsDevice.PresentationParameters.IsFullScreen =

Would require a new device binding. In the OpenTK world, getting a new depth stencil buffer on the main game window after you allocated the fb would appear to be impossible.

So then in ApplyChanges, if the back buffer dimensions change, maybe a DeviceReset() should happen instead, which would then get a new display fb, new windows, new graphics device, and reset the world as if the game had just been initialized.

Ethan Lee

We actually have a similar concern with MG-SDL2 when setting the SDL_GLattributes, but the solution was actually one that coincided with my use of SDL_WINDOW_FULLSCREEN_DESKTOP:

I would recommend this for the OpenTK backend as well, but since I'm out to remove that anyway... you get the idea.

So I'll probably just def that particular issue for SDL2 then.

Jacob Anderson

Wow, that SDL_GameWindow really makes a bunch of assumptions about the fb characteristics. If you're trying to get rid of OpenTK, then why does that ctor reference OpenTK APIs ???

You should not just 'ifdef' that section of code for SDL2. For this to fit into MonoGame, we need to figure out how the device reset should work so that existing XNA games can port properly to SDL2. We can't just wedge it in there and leave it for later.

It's great work Ethan, but it needs to fit into the XNA framework's idiosyncrasies.... Since we have to reverse engineer those, this process is very lengthy and prone to catastrophic failure at times (see my feeble attempt at changing the GraphicsDevice class once).

Ethan Lee

We keep the TK GL/AL bindings in order to maintain compatibility with the MG GL/AL work. Having an OpenGL# and OpenAL# would be preferred, but MiniTK was the more diplomatic approach.

I wouldn't be too surprised at incompatibilities with non-desktop platforms right now, but the FULLSCREEN_DESKTOP FBO currently works on all desktop platforms with all of my games (5 currently out, 3+ on the way). Changes will happen in this particular area as needed, of course.

Ethan Lee

Official SDL 2.0.0 annoucement:

Includes links to SDL2 as well as official extensions, such as SDL2_mixer (which we still use for Song).

Dean Ellis
David Jeske

I think we're pretty much in agreement on the OpenTK v. SDL2 deal. We can add SDL2 separately, then let them fight to the death on the user end.

What does this mean exactly? It sounds like this means adding SDL2 to MG while keeping OpenTK in monoGame and letting users decide which of the overlapping components to use (input, window handling, audio). Is that right?

Does it help if OpenTK splits out the "platform layer" (input, gamewindow) into a separate assembly from OpenGL support, and tries to make OpenTK-GL more agnostic to display surface choice (aka SDL2#, or OpenTK.Display, GTK#, or raw-native platform code)?

It's hard for me to tell from this discussion what parts of OpenTK MG would like to preserve (if any). If anyone in the know would like to enlighten us, there are some of us trying to update OpenTK here..!forum/opentkr-dev

If the MG plan is to only expose XNA and hide OpenTK/GL support, switching to MiniGL or some other light binding underneath, that's also understandable and would be helpful to know about.

Andy Korth

I think splitting out the windowing/input/etc from the OpenGL bindings would be a fantastic idea. Other projects and engines are mostly interested in the OpenGL support- monogame, pencil2d, and undoubtably others use the Opengl bindings. However, many of these projects ignore the platform section.

I think the OpenGL bindings are in great shape, but the platform area is missing a lot. Some of the other projects have even done the hard work of supporting mobile and touchscreen devices. Getting the platform section of opentk to that point would be tough.

Dean Ellis
Ethan Lee

For the moment, you might get mileage out of taking MiniTK in SDL2# and making them individual assemblies, though there is a lot in the bindings that depends on other stuff, so when I was thinking about OpenGL# and OpenAL#, I was mostly thinking of doing them from scratch to get my way with the API style as well as scrapping all the additional components that MiniTK is still stuck with.

That said, having it set up to where I don't have to maintain MiniTK would be pretty nice. Takes forever to compile SDL2# with MiniTK inside... bleh. (Plus, I'm starting to forget what I did change inside that part...)

Steve 'Sly' Williams
Ethan Lee

You've got time to write the new bindings before I can start OpenGL#/OpenAL#. Use it wisely!

David Jeske

@dellis1972 - Thanks for the feedback. Splitting the OpenTK-Platform from OpenTK-OpenGL and supporting SDL2# seems very sane. So far I think it may be worth keeping OpenTK-platform alive and updating it, since it offers a working win/mac/linux platform layer without native code installs.

It's less clear what to do with mono/opentk vs andykorth/opentk. They have the same history before Dec 6, 2011, but the hashes don't match. Is monogame using that frozen-in-time OpenTK, or one of the other forks?


I previously suggested adding OpenGL DllImport directly where they are used so it would be a breeze to contribute and update support as new versions / extensions become available. This, plus partial class implementation, and you have a clean code base that is very easy to debug and maintain.

The less choking point (external dependencies) MonoGame has, the easier it will be to quickly iterate and get quality contributions.

Andy Korth

It's less clear what to do with mono/opentk vs andykorth/opentk. They have the same history before Dec 6, 2011, but the hashes don't match. Is monogame using that frozen-in-time OpenTK, or one of the other forks?

I don't actually remember for sure, but I think I made my branch by importing the svn repository into github, so there's no shared history with the mono/opentk branch. There were some changes in SVN after the mono version froze in time.

Master on mono/opentk appears to be an untouched old svn copy. But has changes to consider for the main opentk project.


I previously suggested adding OpenGL DllImport directly

One of the points we've been discussing in the opentkr group is getting rid of DllImport and using calli instructions instead (like SharpDX), it should be faster albeit more work to set up and maintain. Better to leave the low level binding stuff to OpenTK and MonoGame concentrates on more high level game things (like the content pipeline).

OpenTK is still an important project that needs help and support. Splitting out the API's from the Platform would be a great move for the project.
Please don't. I have given in to the style of SDL2 bindings (not worth fighting that any more), but I will not back down on changing the OpenGL or OpenAL bindings. Won't allow that in MonoGame, sorry.

Would it be beneficial to split OpenTK into multiple assemblies for each part? So you'd have OpenTK.OpenGL, OpenTK.OpenAL and a base OpenTK for parts shared?

It's less clear what to do with mono/opentk vs andykorth/opentk. They have the same history before Dec 6, 2011, but the hashes don't match. Is monogame using that frozen-in-time OpenTK, or one of the other forks?

I'm going to continue treating andy's repo as trunk, but it would be good if this reboot effort was recognized by mono and given some space.


using calli instructions instead (like SharpDX), it should be faster albeit more work to set up and maintain

I wasn't familiar with this method (thank you for the pointer) but does it work on all platforms ? DLLImport might be slower (to be fair the functions requiring heavy marshaling shouldn't be called that often anyway) but as you mentioned indirectly, it is easier to implement and maintain.

MonoGame is what OpenTK tried to become. The intention was to be an alternative to XNA, a low to mid-level game API that can be used on the ever growing number of platforms out there. What I don't understand is why the MonoGame Team doesn't want it to be its own thing. I understand that other ppl might benefit from a generic OpenGL# bindings (if someone want to do it then it is great) but if they are not going to use MonoGame anyway, then why waste time on project politics ? Let us use DLLImport where we need it directly in the MonoGame code (MonoGame doesn't need all of OpenGL) and let's move forward. New features and optimal extension usage based on the device would be a breathe if it is done this way.

I only hope that the people making the final decision have experience with releasing games on more than just desktop / WinRT because when you start releasing for iOS and Android for example, you are in for a fun ride if you don't have full control of your OpenGL bindings in order to deal with poorly implemented extensions and buggy drivers :)

David Jeske

MonoGame is what OpenTK tried to become.

Not for all of us.

I'm using OpenTK for cross-platform desktop-OpenGL. With OpenTK, right now I have a single compiled App.EXE and OpenTK.DLL which I can unzip and run on Mac and Windows. (more akin to Java + Java3D)

MonoGame/XNA seems game-focused and XNA is not full OpenGL/DX. It also seems to expose platform-window/init issues. Though maybe this is old stuff...

Using SDL2# as a platform layer instead of OpenTK.Platform might be interesting for my use case, because it could provide more-robust cross-platform, multi-display, multi-window. However, it would come with the need to include the native SDL2 library. I think larger projects will eventually end up with other native libs and deal with this anyhow, but for small desktop projects it's nice to avoid native platform dependencies and builds.

From a monogameteam perspective, we need to keep the OpenTK style interface
so our opengl platforms have a consistent api.

Is this about MonoGame having a consistent API to the platform OpenGL, or is OpenTK exposed to apps?

What I don't understand is why the MonoGame Team doesn't want it to be its own thing. I understand that other ppl might benefit from a generic OpenGL# bindings (if someone want to do it then it is great) but if they are not going to use MonoGame anyway, then why waste time on project politics ?

If MonoGame doesn't expose OpenGL to app developers, I agree. If it does, it's kind of a pain to have all these different C# OpenGL implementations out there. (OpenTK, SharpGL, Tao, TaoClassic, etc. etc. )


What I don't understand is why the MonoGame Team doesn't want it to be its own thing.

I don't understand why it would want to be it's own thing. Let OpenTK worry about low level bindings and the work required to make them good, let MonoGame worry about using those bindings to make an easy to use, game framework.

New features and optimal extension usage based on the device would be a breathe if it is done this way.

If this reboot goes well then new features and extensions will be easy because OpenTK will be exposing them. And if OpenTK aren't exposing them then nudge or submit a patch, then MonoGame and everyone else using OpenTK can benefit from that extension.

I wasn't familiar with this method (thank you for the pointer) but does it work on all platforms ? DLLImport might be slower (to be fair the functions requiring heavy marshaling shouldn't be called that often anyway) but as you mentioned indirectly, it is easier to implement and maintain.

As far as I'm aware it should. calli is a standard CLR instruction, we aren't do anything fancy it just isn't exposed by C# be default. As for implementation and maintenance, like I said doing a good binding implementation is OpenTK's role. The end user (MonoGame) shouldn't be concerned about how we do the bindings, just that they work well.

Fancy bindings are at any rate a future prospect. Short terms goals are making sure OpenTK is working well, fixing any lingering bugs (pointers from MonoGame on this would be really appreciated!) and then working on making things better by splitting up APIs, adding data streams and calli bindings, adding more bindings and anything else deemed useful.

Dean Ellis

Xamarin just made an announcement about the future of opentk

Ethan Lee

Here's something I've not done in a while: new game time!

FEZ Mac/Linux has just shipped in Humble Indie Bundle 9, and they use the MG-SDL2 platform backend:

Dean Ellis
Ethan Lee

Another new port: A Virus Named TOM just shipped in the next batch of games for HIB9:

This was the last port I wanted to ship before submitting MG-SDL2 to upstream. I'm-a make sure these games are stable for the bundle, and I'll start making the final branch at the end of this month.

Ethan Lee

I have just made the MonoGame-SDL2 pull request:


Some things from the MG-SDL2 PR tracker did not make the final cut, but those are general MonoGame issues that can be sorted out later.


In case anyone is interested, the master branch of OpenTK will now use SDL2, if available, and revert to the native platform drivers if not.

Found here:

Ethan Lee

Hm, noticing a lot of stubs in there. Feel free to pull from David's take on opentk-sdl2 if you want:

It predates our SDL2# work, but it sortakinda worked in one or two places.


Thanks, I will take a look.

Pretty much everything bar the joystick and the mode selection API is done: Windows/Linux/Mac OS X support, windowing, mouse, keyboard, context profiles (core, compatilibity, es). I am dogfooding this and, minor oddities aside, it is working as it should.

I'm currently investigating some issues in SDL2 itself, hopefully everything will be sorted out by the time SDL 2.0.1 rolls out.

Kinda curious how well this would work with MonoGame.

Dominique Louis
Ethan Lee

I'm actually not sure; SDL2 can't openly host backends for most consoles due to licensing issues, but developers can make SDL2 backends for consoles if they want to (zlib license). The only console I can imagine being a super quick port is the PS4, but only because of the Orbis/OpenBSD OS underneath. A Vita version of SDL2 has also come up a few times, but I don't know who will be involved with that if it does happen.

So, if you want to port your MG-SDL2 title to a console, you'll need a Mono runtime as well as an SDL2 port. But, making an SDL2 backend should be simple, as outlined here:

Ethan Lee

Heh, forgot about the Ouya! If that counts, we can add Steam Machines to that list as well, and we've already got MG-SDL2 compliant with Big Picture.

Steve 'Sly' Williams
David Gow

As @flibitijibibo said, the opentk-sdl2 stuff I did is up for grabs if you want to use it, though it has its own issues. I've stuck a readme up with some of them.

One of the things learnt from it was that there were quite a few times when the extra layer of the OpenTK API between MonoGame and SDL2 was getting in the way and making things more complicated for no real benefit. The SDL2 API, as I'm sure you're finding out, doesn't match the OpenTK API perfectly, so the MonoGame-SDL2 work was much cleaner and nicer without that friction.

I still think that having an SDL2 backend for OpenTK is a good thing, but I suspect MonoGame is better off using SDL2 more directly, and leaving OpenTK to be used by projects which don't have the level of platform abstraction MonoGame has.

-- David

Steve 'Sly' Williams
Justin Aquadro

Just want to bring some attention to something: Right now OpenTK is an important component of WinForms- and WPF-based tooling since it's straightforward to embed into external controls. I've tried playing with the SDL branch to see if that could also be pulled off, but didn't make much progress. SDL looks more tightly protected. The GraphicsDevice API needed for a DX-based backend was never implemented.

This should at least be looked at in more depth before OpenTK is fully removed as a backend, if that is the plan.

Steve 'Sly' Williams
Ethan Lee

Escape Goat, one of my ports from earlier this year, just hit Steam:

This game has the proud honor of being the first game on Steam to use MG-SDL2 on Windows! This has allowed us to use the exact same C# assemblies and game content on all three platforms. The only data in the Mac/Linux depots is the MonoKickstart environment, everything else is shared from a single depot.

Dean Ellis

I don't know if you noticed the announcement by Xamarin to get the mono/opentk uptodate (
It would be really great if the OpenTK community could get behind that effort to bring it into one place. Having loads of different forks of OpenTK is not good, and projects like MonoGame could really use a central place to get this stuff from.

They are also open sourcing the Android/iOS changes so from MonoGame's point of view that is where we will get our builds/source from, we won't be getting it from any other place.

Tom Spilman

IMO... we have to pick one path.

Either we support the MonoGame OpenTK backend on the desktop platforms or we support the new SDL2 backend... we shouldn't do both.

Ethan Lee

New MG-SDL2 port: Rogue Legacy:

Ethan Lee

Been a while since I posted here, hm?

Dust: An Elysian Tail will ship on Mac/Linux with MG-SDL2 soon:

This is boasting some other features like the XACT rewrite, but the SDL2 platform is still in there!

Ethan Lee

Wayland support should be in the next SDL2 release:

This prepares SDL2 titles for the upcoming transition from X11 to Wayland for Linux desktops. No code changes will be necessary.

Jonas Kulla

This prepares SDL2 titles for the upcoming transition from X11 to Wayland for Linux desktops. No code changes will be necessary.

I'm a bit interested to see how things like setting the mouse pointer position will be handled under Wayland. Are there games that make use of this?


The following PR updates OpenTK.dll from 1.1-prealpha (svn r3127, currently used in MonoGame) to 1.1-beta3 (equiv. to r5363): kungfubanana/MonoGame-Dependencies#43

This covers roughly three years worth of updates, including:

  • Support for SDL2
  • Support for OpenGL 4.4
  • Support for OpenGL ES 3.0
  • New, faster interop mechanism similar to SharpDX
  • Between 3x and 10x faster startup times
  • Reduced memory consumption (680KB vs 2800KB)
  • Significant stability and compatibility improvements (should fix TypeLoadException reported in #2164)

Note that this PR is fully compatible with MonoGame/develop and does not require any code changes to MonoGame itself.

SDL2 will be used automatically when available: testing the SDL2 backend is as simple as dropping SDL2.dll from to your project directory. When SDL2 is not available, the native backend (WGL, GLX, AGL) will be used instead. This maintains compatibility with platforms that do not offer SDL2, such as Ubuntu 12.04.

Edit: please note that the OpenTK repository is now hosted at

Ethan Lee

Symbol conflicts for the Tao code in Desktop/?

Also, Dust Mac/Linux is out today, debuts on the Humble Store:


Both managed and unmanaged sides are clear, plus the libraries use late binding so no symbol conflicts in the C sense. Updating OpenTK does not affect this.

I'll be spinning a patch to clear the Tao / SDL1 dependency shortly.

Ethan Lee

Not really an SDL2-specific thing, but it does show off the MG-SDL2 code a bit.

MG-SDL2 now supports video/input support for the Wii U GamePad:


Again, not entirely useful, and libdrc is Linux-only for the moment, but it works!

Ethan Lee

Reus Mac/Linux uses MG-SDL2, and Windows will soon as well! Currently for sale in Humble Indie Bundle X:

Flexes OpenGL hardware instancing support, and Reus itself now uses SDL2 hardware cursor support over GDI+.

Ethan Lee

A more quiet release than usual: Blueberry Garden's out (for some, at the moment) on Mac/Linux:

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.