SDL.NET

I think it might be because many C# users probably just go down the XNA route, plenty of tutorials already there.

No reason why you can't use SDL.net if you want to though

For Windows development, XNA is probably a much more viable alternative (very active community, well supported, etc.). For Linux development, I'm not sure, but I'll share my own experience:

Several years ago I was considering developing for Linux using C#, but it seemed like there was a strange resistance in the community to use of Mono, mostly centered around patent scares and anti-Microsoft propaganda. Perhaps it was just the communities I visited, and I'm not saying it was indicative of Linux users in general, but the experience left a somewhat sour taste in my mouth and I abandoned my ideas for the time being.

I also found the lack of activity around SDL.NET, OpenTK, GTK#, etc. disheartening. Of course, things may have changed, as I said this was years ago.

Well a linux option thats taking off with C# is monogame which literally seems to be a near identical clone of XNA using openGL as a backend instead of directx.

Well a linux option thats taking off with C# is monogame which literally seems to be a near identical clone of XNA using openGL as a backend instead of directx.

Good point, I had seen that recently, haven't used it but it does look promising. At the time I was looking into Linux development, either that project wasn't around or I wasn't aware of its existance.

Either way, perhaps the stigma of C#/Mono has worn off lately (which would be a good thing for Linux developers, IMO).

Hmmm all good points. Thanks for your feedback. I guess when C# devs think game development they think XNA, and so that's what they go and do. For me personally, something like SDL.NET is far more exciting because nothing is done for you, you've basically got a blank canvas. It's just like writing a game in C++ but with all of the productivity and simplicity of C# and .NET.

Monogame looks interesting ... although I'm still not convinced using a framework like XNA is for me. Maybe it's just they way I like to do things, but personally I like to learn something from the ground up, understanding the inner workings of a system before moving on to the higher level concepts. Thats why I choose to write all my own code for my game projects, and I believe I'll be a better game developer as a result.

XNA seems fine if you're an experienced developer or team trying to make actual published games, but personally I think it is more beneficial at the early stages to understand how to implement your own systems (not by focussing on the systems themselves, but by making simple games from scratch yourself), and surely this results in a more complete understanding of how game engines work.

I know, I know ... "make games not engines" ... but seriously, that advice is always taken out of context IMO, and often thrown around as an off-the-cuff answer to any new game developer asking how to do [insert_game_engine_feature_here].

something like SDL.NET is far more exciting because nothing is done for you

It's been a long while since I've used SDL (and never the .net wrapper), but I don't remember it being particular "close to the metal" anyway. If you really want to dig into the inner workings of these systems, you will have to interface OpenGL or DirectX.

There are also some thin wrappers around DirectX and OpenGL you could use, some I've heard of (but never used) are SlimDX, SharpDX and OpenTK. I believe there is a book on using C# with OpenGL, but I do not know the name of it offhand.

Also, XNA is just a framework around DirectX, you don't have to use (for example) the provided Game class, or SpriteBatch, or BasicEffect. In fact, I'd wager many developers end up rolling their own versions of these classes specific to their needs anyway.

Interesting ... is it true that SDL is using OpenGL under the hood by default? I know you can use it to get at OpenGL context ... but if you're just doing 2D surface blitting I'm not so sure OpenGL is involved ... I could be wrong.

Which brings me to another question:
Up until now my projects have all been 2D tile-based, using simple surface blitting - do you recommend that I change this and start using an OpenGL context for 2D rendering, just to become familiar with OpenGL? Also would this provide much better performance?
I'm experiencing some fairly serious slowdown caused (from what I can gather) by using transparent PNGs with per-pixel alpha for tile transitions and fades etc ... this wouldn't be an issue with OpenGL? And is it fairly simple to do equivalent tile-based rendering with OpenGL?

I think what your looking to do would be fully possible under openGL, openGL you can take advantage of hardware acceleration (dunno if SDL does aswell though).

SDL 1.3 will use hardware acceleration. SDL 1.2 (on whihch SDL.net I believe is based on) hasn't been using hardware renderer for quite some time. You can obtain an OpenGL context, but that basically allows you to use OpenGL for rendereing instead of SDL_BitSurface & friends.

Whether or not it is a good idea to move to OpenGL - I don't know. I *really* wanted to learn either OpenGL or DirectX, but I simply failed. For DirectX, the C++ API (and C++ itself) simly let me shoot myself in the foot way too often, and the complexity for even the simplest stuff is just amazing. It seems you have to write exponentially more code with every new version. I guess it's OK with people that have the time to learn it properly or you already know it and have an existing codebase. For the simplest drawings, you will have to write shaders (I don't know why they are called like that - they seem like scripts that get interpreted on the GPU) which you feed with data that you upload to the GPU memory. I'm quite the amateur, so this might not be entirely correct, but to blit an image and move it with the keyboard arrow keys you have to write a ton of code. OpenGL seems to have gone in the same direction.

Mentioning OpenGL, my problem with it is the total lack of sufficiently good books / online material. When you have a problem, you get the RTFM (e.g. reference pages on the OpenGL web site or a link to an age-old red book that is for 1.1 or something). From Amazon reviews, it seems that the latest reference book is full of deprectated stuff and doesn't focus on the new shader-based approach as much as it should. There is a beginner's book wirtten by some guys from GameDev, but a quick look at the contents reveals that it deals with graphics theory. I have mixed feeling about this, but at least it is short, and it is example-driven (I don't know how you'd read that on a Kindle since you don't get the examples CD, so I'd recommend you get the paper one).

I can understand why there is all this complexity with shaders and parallelism, but this is for proffessionals. For amateurs, SDL and XNA are basically what you need. If the performance is not good enough, I guess moving the XNA or Unity would be a better option. OpenGL's API is a bit cleaner in terms of ALL_CAPS_NONSENSE and line length, but it can fail silently unless you call glGetError real often, plus the state machine can be quite annoying at times.

In case you do want to move to OpenGL, don't consider online tutorials, specially NeHe. They use the immediate mode (understand: easy for the programmer, slow for the GPU as it doesn't execute whole chunks of code, but single instructions) or arcane libraries that haven't been around for decades. Just look for a book, or wait for LazyFoo to update his tutorials. I really liked his SDL tutorials, and I do hope his OpenGL ones will be as good.

shaders (I don't know why they are called like that

because some shaders can be used for things like bloom, sepia, motion blur etc etc