Elysian Shadows

Hey everybody, I doubt you'll recall but I stopped by a little over a year ago asking for advice on a language-of-choice type of decision. Gyrovorbis and others suggested C++, and while I looked into that route I also received word from other interneters that I should consider C# and the XNA library. After looking into it a bit, I realized that it was exactly what I wanted. So I began the process of porting/rewriting my engine/editor (in its state at the time) over to C# and XNA.

That took about two weeks, and since then I've done A LOT of work on the project (codenamed Project Crimson), and recently I've hit a few snags that have caused some major rethinking on the entire XNA front. First off, XNA incorporates a Content Pipeline, which prebuilds all of your content. While prebuilding all of your content beforehand and not being able to modify graphic, map, or sound files after the fact without recompiling the whole shebang makes worlds of sense (that's sarcasm for the slower readers), I was able to avoid the content pipeline for awhile thanks to a nifty little method for Texture2D objects called Texture2D.FromFile() that allowed you to load an image file into the game at any time. Unfortunately, that same FromFile method wasn't present for sound, so I ended up resorting to another library for sound, while using XNA strictly for input and graphics.

For some reason this still didn't sit well for XNA, and for some unknown reason users would need to have the entire XNA Game Studio installed on their machine in order to use my editor, and more importantly, my engine. Bleh.

So with all that taken into account, I decided I need to ditch XNA and find a sweet new library that could handle graphics and input, as well as sound since I wasn't having the easiest of times finding a new sound library that I liked well enough. Google searches screamed SDL.NET.

Remembering seeing a lot on SDL here and knowing Gyrovorbis is using SDL & OpenGL to power his engine on the PC, I thought I'd ask if you all think I should try and sort out my problems with XNA, or go for SDL.NET, or maybe even OpenGL? You're thoughts are more than appreciated.

PS: Making the move from XNA to either SDL or OpenGL wouldn't be the end of the world in my case, because the only functionality I really need is hardware-accelerated rendering of 2D textured quads. I've implemented some 3D zoom and rotation features using matrices, but it's not a deal breaker if they're initially broken or undoable.

PPS: I'm also going to be posting some stuff about Project Crimson soon, as the project itself is nearing completion since I completed my custom scripting system a few days ago. More on that in the future I guess.

GR33B wrote: Remembering seeing a lot on SDL here and knowing Gyrovorbis is using SDL & OpenGL to power his engine on the PC, I thought I'd ask if you all think I should try and sort out my problems with XNA, or go for SDL.NET, or maybe even OpenGL? You're thoughts are more than appreciated.

I recently started learning C# and admittedly love the language. I have not touched XNA nor do I have any definite plans on doing but I can imagine that it helps simplify game-design for the newbie game programmer. You will run into less restrictions by utilizing C/++ with SDL or another library. Keep in mind that OpenGL is not a multi-media library, but only a graphics library so you would need SDL or some other interface to handle your input/sound/etc...

If I were Bearrick I would tell you to not use C/++ and to use RPG Maker instead because it is easier and you will finish your project. I am not, so I will have to suggest moving to C/++ if you feel ready.

edit: I think I just realized that your question did not involve switching from C# to C/++ at all but rather ONLY switching libraries. D'oh! Anyways, I find SDL to be more than sufficient for my needs so I would absolutely recommend it. I hope someone with experience in both SDL and XNA will reply back to your post to give you a bit more insight.

GR33B wrote:For some reason this still didn't sit well for XNA, and for some unknown reason users would need to have the entire XNA Game Studio installed on their machine in order to use my editor, and more importantly, my engine. Bleh.

They only need the XNA Runtime (plus .NetFramework 3.5?). You simply run it as part as the ending install.

The XNA Content Pipeline... not sure if I ever really liked it. It is useful but takes far too much control out of your hands. You can make your own. There are some other pipelines others have made that give you much better control about what's going in/out.

For now I use the Bass Audio library and it's worked pretty well with XNA.

I've Heard some good things about SlimDX, An unofficial update\rebirth of Managed DirectX (Pre-XNA), however it's lacking in tutorials...

AIWar uses SlimDX, so it's functional and speedy with 2D anyway. Past that I know nothing about it.

This is more a question of design versus engineering. XNA is an entirely prebuilt engine complete with everything such as rendering libraries, collision detection, entity management, animations, and everything that you would otherwise have to do from scratch.

If you're in it to learn, and want to be all you can be, SDL.NET.

If you just want to make a game and don't care about the science or engineering behind it all, XNA.

@ Gyro:

To be honest, I think you're either misunderstanding or exaggerating the amount of work that XNA does for you...

I respect that you're a purist with a hacker mentality, and I'm firmly of the opinion that an understanding of C and the associated low-level concepts (e.g. pointers and memory allocation) is a necessity for anybody seriously interested in a career in programming or software engineering. C++ is clearly a must for anybody wanting to work as a programmer in the games industry. However, the way you speak about XNA perhaps belies some animosity or contempt which isn't entirely justified:

XNA is an entirely prebuilt engine...

Strictly speaking, this isn't true. XNA describes itself as a "framework" and I believe this to be a fairly accurate description. What do you mean by "engine" here? A game engine (it certainly isn't)? A full-featured rendering engine (hardly)?

...complete with everything such as rendering libraries

Yes, XNA handles the representation of textures in memory for you. Yes, in 2D it allows you to create a render target and load and blit an image with a few lines of code (in much the same way as SDL does, for example).

In 3D it handles the loading/representation of a mesh and provides a simple example shader with the most basic lighting and texturing functionality (i.e. the kind of functionality you get from OpenGL out of the box without the use of any shaders). To do anything at all interesting you will be writing shaders in HLSL (which is effectively a subset of C) and dealing with vertex buffers etc., just like you do with OpenGL or DX. Want a quad in 3D space? You have to implement it yourself. Culling more complex than back-face? Roll your own. This certainly isn't a rendering engine like Irrlicht where you can just enable a flag for parallax occlusion mapping.

...collision detection...

As far as I'm aware, XNA provides only basic AABB and bounding sphere collision detection, with no collision resolution or contact point detail whatsoever. If you want anything non-trivial, you will have to implement it yourself. I can't realistically see anybody being able to use these features without being able to implement their own version.

...entity management...

XNA again does very little work for you here...

For resources like textures and sounds, you are basically given a dictionary object for each resource type.

For more abstract game objects, you are provided with an extremely limited "game component" interface which, again, does sweet fuck-all in terms of reducing the amount of work required. This basically amounts to a vector of objects which have their "Draw" and "Update" methods called each frame. That is all, it is basically the most naive system possible, too inefficient for most purposes (i.e. interactions between objects will be O(n^2)) and many/most developers won't even be using it.

There is no scene-graph/spatial management going on here either - no automatic octrees or even simple scene hierarchy implemented for you (besides a flat list with one level of sub-meshes).

...everything that you would otherwise have to do from scratch...

This is clearly hyperbole - what would you suggest XNA does actually leave to the developer? It is more than just game logic.


My point is that while yes, XNA does hide some lower level implementation details from the user, these are the things which you immediately wrap and abstract away at the beginning of a project and rarely ever need to touch again. Really, this was a necessity if anyone expected Microsoft (who are, after all, Microsoft) to let 3rd-party code from hobbyists run on their flagship console.

Having used both XNA and C++/OpenGL and dabbled in DX, in my experience the features of XNA which are actually useful are those which are (almost) trivial to implement or are at least very well understood and widely documented. Comparing my own projects in XNA and C++/OGL, when taking the lower-level route I quickly (as in a few leisurely evenings or several solid hours of work) reached a state of functionality comparable to the subset of XNA features I rely on - at this point the workflow became roughly the same.

So a statement like "If you just want to make a game and don't care about the science or engineering behind it all, XNA" isn't entirely appropriate when an inexperienced developer who picks it up will be quite taken aback when they realize they need to deal with vertex buffers and write shaders in a C-like language just to create a billboard or particle system.

Suggesting that using XNA means the developer won't learn anything just because they don't have to implement their own vector class doesn't really make sense. If they were seeking an actual academic approach they would be on a computer science course working in C/C++ implementing data structures and studying computability, not using .NET in the first place. Arguably, they wouldn't even be using SDL for their game as it has image formats, font rendering, event queue etc already handled for you.

GyroVorbis wrote:XNA is an entirely prebuilt engine complete with everything such as rendering libraries, collision detection, entity management, animations, and everything that you would otherwise have to do from scratch.

Ganna have to agree on most parts with ClassA here. You're giving XNA more credit than it's entitled to. It gives you plenty of classes to handle drawing, sound, input, and various Xbox 360 function, but it is in no way put together as an engine to easily crank out games. There's a few game starter kits, but those are mostly for learning how to handle various concepts in C#/XNA.

There are BoundingSphere and BoundingBox classes for simple collision detection and the closest thing to entity management is that their Collections library is pretty strong, but that's actually part of C#. If you actually want to put together a solid game, you still have to go through the standard development process. The XNA framework just puts you a few abstractions away from the nitty gritty stuff that you love.

If you want a finer level of control than what XNA offers, there's always SlimDX as already mentioned. Their own documentation looks to serve well for lack of many tutorials online.

Well, I read everybody's response to my response. Then I went off and read more about XNA.

I guess you guys are right. Rereading what I said, it was pretty stupid to call it a prebuilt "engine." It's certainly offering more than just an API, but far less than an engine. I think you guys said it best by calling it a "framework."

I really don't have anything against XNA at all. I use C# at work, and I'm becoming pretty familiar with .NET and what it has to offer. For me, I'm a low level kind of guy. I think somewhere between C and assembly when I program. I enjoy having that level of control.

It looks like that's the only thing you're missing with XNA. I thought that a lot of the design/mathematics/engineering aspects of game development were abstracted away from programmers with XNA. Reading more has definitely made me change my mind.

@Gyro
I know that you're really interested in taking a fine grained level of control. The shader pipeline of XNA would be the perfect match for you, then. Quite literally writing a shader reconfigures the graphics hardware (to some extent) which is actually an extremely simple architecture. Some people still write GPU assembly, though not as much anymore. Much of the algorithms involved in taking that level of control demand an exceptional attention to the minutia that you find interesting :]

Also, the GPGPU front is really sort of the next frontier for fine grained access to the GPU's resources. There are some VERY interesting things coming out of that camp and much of the architecture over the next several generations will become increasingly geared towards handling the more generalized tasks that people are throwing at GPU's now. The engineering and mathematic aspects to this form of programming are ESPECIALLY prevalent.

Maybe as a pet project :]

GyroVorbis wrote: I really don't have anything against XNA at all. I use C# at work, and I'm becoming pretty familiar with .NET and what it has to offer. For me, I'm a low level kind of guy. I think somewhere between C and assembly when I program. I enjoy having that level of control.

To be honest, I only grudgingly stepped into C# (which I had always assumed was merely Microsoft's half-assed answer to Java) so that I could play with XNA on the 360. I found myself pleasantly surprised by the language, which I now consider to be very well designed (in terms of a language specification, disregarding any particular implementation and its performance). However I still tend to code in a fairly "c++ like" way, probably not taking full advantage of certain language features.

Personally, I would still prefer to code in C++/OpenGL if I wasn't concerned about my target platform and of course if I absolutely needed performance. For most practical (business/web) software development or pragmatic hobbyist/retro game development where performance boundaries are hardly being pushed I think C# is at just about the right level of abstraction though - I can't see having to deal explicitly with mallocs or the fact that strings are stored null-terminated and may use multibyte encoding is going to sit well with internal corporate developers in terms of productivity.

qpHalcy0n wrote: Also, the GPGPU front is really sort of the next frontier for fine grained access to the GPU's resources. There are some VERY interesting things coming out of that camp and much of the architecture over the next several generations will become increasingly geared towards handling the more generalized tasks that people are throwing at GPU's now. The engineering and mathematic aspects to this form of programming are ESPECIALLY prevalent.

This is definitely an interesting area these days! A friend of mine is doing his thesis on using GPUs for scientific computation (lots of matrix work - fluid dynamics, finite element analysis etc) and it's quite fascinating, although I've never got very deep into GPGPU myself.

Just to clarify, I use a very tiny amount of the XNA Framework in my engine. The only thing I use it for is graphics and rendering, and getting the state of the keyboard. Even then, I use a small portion of that.

The only XNA methods I use are spritebatch.Draw(), which is the default texture rendering method, and Texture2D.FromFile(), a method that allows you to load textures without the dreaded content pipeline. As for input, I only use the method Keyboard.GetKeyboardState(), which I then convert into a boolean array so I can enable and disable keys at my leisure. Everything else, such as collision detection, animation, saving and history, and even a custom scripting engine I did on my own, and they do not rely on any framework. I really try to use the bare minimum of libraries when I do use them, so my engine does not become overly dependant on one library or another.

So if anyone knows of a C# compatible library that can load textures, render/blit a specified portion of a texture, and get the state of the keyboard's keys, and maybe even do sound, let me know. It would literally take less than an hour to replace the few XNA method calls with the new library's calls.

If you just want 2D, take a look at Gorgon. It's pretty cool. You'll probably also be able to get some 3D in there using SlimDX pretty easily, though I haven't tried. As for sound, I like BASS. It's also pretty cool. It plays and does lots of stuff (especially with the plugins) and doesn't afraid of anything^W^W^W^W^W^H.