Do you like XNA?

5 replies [Last post]
Posts: 164
CP: 0

Well, I made a post about 2 seconds ago that inspired me to post this thread.

Do you like XNA? (If you've worked or experimented with it) A simple yes or no is fine, but some kind of explanation would be nice.

I really like XNA. Really, the only thing I don't like about it is the lack of scalable vector graphics. (but I don't really need them so whatever) I also don't like what I've heard about the audio API. (I don't really take the time to put sounds in my games... I'm not sure if I want to take the time to polish my pong/break out clones) I absolutely love the idea of the content pipeline, but it is a hassle to build your content. Plus the audio files are a monster after there built... Maybe the XNA team will fix that in the new version of the framework. (4.0 for you guys who don't know) Other than that, the content pipeline hasn't been too much of a hassle.

I've tried SFML. In all honesty, I like XNA better. (in terms of the class structure) This isn't really a discussion between SFML/XNA or which one NetGore should use. This is just your opinions. (hence the programming section) I don't think I would have the tenacity to post a topic like that anyway.

Posts: 1647
CP: 26119

XNA is great, but like all Microsoft things, it'd be nicer if it was more open. The turn-off for me is that I did not want to do things "the XNA way", and as a result it became more trouble than it was worth. But if that was no problem, and if I had no problem with developing a Windows-only program (which usually isn't a problem thanks to stuff like Wine), then it'd probably be my top choice. SFML is a bit too simple in my opinion - I like the access to lower-level stuff. But at least with SFML, you are not "locked out" and can still easily use OpenGL directly on top of it.

Just also wanted to add that XNA also is definitely a (large) step in the right direction for "average user" multimedia support. It takes care of restoring devices and assets, processing (compiling) content, batching, content management, etc. These are all things we all have to deal with and is just a waste of time to write. It is very nice to have a framework that does this all for you, and I hope to see that more often.

Posts: 164
CP: 0

I'm not sure about the overhead, but wouldn't it make sense if SlimDX and XNA could be used alongside on another. (SlimDX for sound at least)

Also, could you elaborate on what you mean by "the XNA way"? I feel like I've seen you say that before... I'll try to find where it was that I saw it. I think I'll be able to respond better to that...

Edit : found it on the SFML forums : (3rd post : SFML : Projects : NetGore - Open Source C# MMORPG Engine)

Spodi wrote:
Cross-platform was just a bonus. I can't think of all the reasons off the top of my head, but in brief, the big ones were:

Content pipeline - XNA pretty much forces you to compile your content. Loading bmps/pngs directly isn't very pretty, gives you assets that aren't able to be added to the ContentManager, and I believe is even deprecated now. While I like the idea of it, it made build times quite horrible. I didn't want people to have to manually add assets to the solution, so to even get them to build I had to create a custom msbuild project to do a "search and build". Even when content was already built, it took a good 4 seconds for just about 100 files. When they had to build, it took a good 20 seconds. Now, I just run a program in post-build that does a threaded compare/copy, and is nearly instant.
ContentManager - I didn't like having to unload all content in one call, nor did I like having to maintain multiple ContentManagers. However, altering the ContentManager is brutal in XNA. Even just loading content without it is rough, so you can't just "roll your own" easily.
Music - You HAVE to have Windows Media Player installed to use music in XNA, which was more just annoying. Playing music for the first time also resulted in a like 3 second stall on the calling thread, so I had to make a hack to create a background thread to just "prepare" the music.
Portability - I never really cared if the client was cross-platform, but the server needs to be. This engine is focused at indy developers, and Linux VPSes are almost always significantly cheaper than Windows ones. Grabbing primitives like Vector2 and Rectangle and using those without referencing XNA got quite ugly and required some reference-juggling via msbuild hacks.
Distribution - SFML is tiny. XNA isn't too big (a few MB), but the installation can be quite long for such a tiny thing.
Text input - There just isn't any of it in XNA. It was annoying enough to get EN-US keyboard text to work. To support other keyboard layouts, it was looking like it would require some Windows API calls to transform the real keys into virtual keys to get the text.
"The XNA way" - XNA pretty much forces you to use "their way". Usually, this wan't a problem. But at times, it became quite annoying (see ContentManager above). SFML isn't perfect either, nor is really any other engine (absolute flexibility just isn't really realistic), but at least SFML is open source so I can just change the engine. And this has turned out incredibly useful.

XNA isn't bad, it just wasn't suiting my needs.

Content pipeline - I agree with you there. Although, the new version improves this. Content projects are separate and you can separate your content into multiple content projects. That could drastically improve build times.

Content Manager - You can add content to a content manager and dispose/unload content with out using the content manager. You just have to inherit from the class and completely override the Load{T} method. Make a call to ReadAsset and make sure you provide a disposing delegate and then you can handle content management yourself. You can't load some content types easily without the content pipeline though. Some you can't load without the content pipeline at all. (mainly music) Someone said that the newer framework gives direct access to the SoundBuffers. (dynamic audio output or something like that)

Music - I can't say much more on that. Hopefully they improved the audio API in the newer release.

I pretty much agree with you on everything else. Similar to the opposite of what you said, XNA pretty much fits my needs. I guess that's what it all comes down to.

Another reason why I like XNA is that Microsoft is developing it and I don't really think they will drop it. I don't think SFML development will die, but I just feel kind of insecure using open source graphic engines. (more like a game framework I suppose, multimedia might be a bit more on the dot...) I doubt SFML will just die, but development might slow down. (it happens a lot with open source projects) Then again, I don't really know a lot about how active their development is...

Edit 2: Wow, really long post... Thank god for the edit button. I think I used it like 30 times by now. I'll try to stop editing this post now...

Posts: 531
CP: 967

I like XNA but i prefer working with DirectX directly in C++. If it could be more flexible like working with OpenGL or DirectX but obviously managed (I learnt Managed DirectX 9 without realising it had become obsolete Tongue)

And the thing i think with SFML is the community isn't huge. but i haven't been on it that much. is SFML relatively new?

There are 10 types of people in this world - Those who understand Binary and those who don't.

Posts: 1003
CP: 7799

The lead coder joined their forum in 2007 so I'd say not THAT new.
http://www.sfml-dev.org/forum/profile.php?mode=viewprofile&u=2

Posts: 164
CP: 0

Skye wrote:
The lead coder joined their forum in 2007 so I'd say not THAT new. http://www.sfml-dev.org/forum/profile.php?mode=viewprofile&u=2

It's not that new, but I'd say it isn't used a lot. SDL is probably used more than SFML. (Just my guess)

Edit: I checked their projects page, there were only 4 games that used it. (There are probably more though) None of them used the .NET platform.