This is probably another one of those questions, but I have not found anything recent on it. That is, addressing XNA 4.0 and SlimDX March '11.
I am learning C# for some fun, and want to go into 3D. I originally planned to go for XNA, but the MSDN site scared me a little. It seemed very much to say 'XNA is for Windows Phone and XBOX!'. I know it does Windows too, but still.
I also remember hearing about SlimDX. It seems good, and the comparitive table seemed to slant in favour of SlimDX over XNA.
However, I am not a fan of writing very low level code.
Is there a decent, up to date comparison of the two, not just feature wise?
And if I want to make a 3D game just for Windows, should I prefer one over the other?
XNA or SlimDX?
Many people use XNA to write strictly Windows games to no ill effect. While XNA is designed to support WP7 and the 360, Windows is also a primary platform and functions just fine. The only difference are platform specific features of both WP7 and the 360 which are obviously unavailable on Windows (For example, xbox avatars on the 360 and touch input on WP7)
It's also worth noting that XNA is easier to learn and designed for your chosen language (C#). SlimDX is pretty much a verbatim wrapper for the native C++ libraries which carries with it some of the nuances and design choices that aren't typically dealt with in a managed environment.
SlimDX is an fantastic library, but if you are learning C# at the same time, I would recommend something higher level like XNA which takes care of most of the low level details. Once you get the hang of things and if you feel like you'd like more control over everything, you could certainly migrate to SlimDX.
It's also worth noting that XNA is easier to learn and designed for your chosen language (C#). SlimDX is pretty much a verbatim wrapper for the native C++ libraries which carries with it some of the nuances and design choices that aren't typically dealt with in a managed environment.
SlimDX is an fantastic library, but if you are learning C# at the same time, I would recommend something higher level like XNA which takes care of most of the low level details. Once you get the hang of things and if you feel like you'd like more control over everything, you could certainly migrate to SlimDX.
Author
I think I am getting C# pretty well down. I messed with it a few years back, and C++/Python experience helps.
If SlimDX is a verbatim wrapper, I think I shall go for XNA. I assumed it was an XNA but at a slightly lower level. And technically it is then, just at a much lower level than I thought.
Thanks!
EDIT: Can anyone recommend a good book for XNA 4.0? I'd prefer to learn it right from the start.
If SlimDX is a verbatim wrapper, I think I shall go for XNA. I assumed it was an XNA but at a slightly lower level. And technically it is then, just at a much lower level than I thought.
Thanks!
EDIT: Can anyone recommend a good book for XNA 4.0? I'd prefer to learn it right from the start.
Though you seem to have made your decision already, I thought I'd share my experience wrestling with the XNA vs SlimDX question.
About 8 months ago, I decided to start work on a game project using C#. My initial investigation led me to XNA and I went as far as installing the SDK until I found information that put me off XNA and onto the SlimDX path. In the last few months I found out some additional things about XNA 4.0 which I didn't like, so I'm confident I made the right decision to go with SlimDX.
That said, my reasoning is no doubt different to yours, as I was looking for a lower level graphics API like DirectX or OpenGL rather than a game API. I also have misgivings about the long term plans Microsoft has for the PC side of XNA. In my personal opinion, SlimDX has more of a future.
In practise I find that SlimDX being a "verbatim wrapper" is actually quite a benefit, as I can read c++/DirectX code samples or books and very quickly translate them into C#/SlimDX.
About 8 months ago, I decided to start work on a game project using C#. My initial investigation led me to XNA and I went as far as installing the SDK until I found information that put me off XNA and onto the SlimDX path. In the last few months I found out some additional things about XNA 4.0 which I didn't like, so I'm confident I made the right decision to go with SlimDX.
That said, my reasoning is no doubt different to yours, as I was looking for a lower level graphics API like DirectX or OpenGL rather than a game API. I also have misgivings about the long term plans Microsoft has for the PC side of XNA. In my personal opinion, SlimDX has more of a future.
In practise I find that SlimDX being a "verbatim wrapper" is actually quite a benefit, as I can read c++/DirectX code samples or books and very quickly translate them into C#/SlimDX.
Keep in mind these thoughts are coloured by my own bias:
The overall gist of what I found was evidence that Microsoft's plans for XNA (which covers PC, Xbox360 and WinPhone7) look to not include the PC. The Xbox360 is a static piece of hardware, whereas the PC has continued to develop, and now there's Directx10, 10.1 and 11, which the Xbox doesn't support. Microsoft's current strategy around XNA seems to be to standardize the API to allow developers to create games for the 3 platforms at once really easily. However, this flexibility comes at the price of supporting the PC's newer capabilities.
I tried to find out if XNA 4.0 supported DX10, 10.1 and 11, but I had trouble finding a clear answer, so I'm not sure if it does. In contrast, SlimDX supported Direct3D10 in 2008, and added beta support for Direct3D11 & Direct2D in August 2009. SlimDX tends to release a few times a year, whereas XNA is once a year.
I'd love to quote actual sources instead of giving vague comments, but I found it all through google, and now 8 months later, I can't remember where I read any of it. This is the only source I've read recently that I could actually find:
http://www.theindies...th-of-an-indie/
I encourage you to dig deeper and decide for yourself.
Microsoft's strategy makes sense if you assume that every coder knows DirectX/C++ just as well as they know C# and have plenty of time on their hands. If you want to use API's that are newer than 3 years old, you should use C++. If you want to cover several platforms, you should use XNA.
Alternatively, if you're not a c++ guru, and want to use C# *AND* make use of the latest API's, SlimDX is the way to go in my opinion.
The overall gist of what I found was evidence that Microsoft's plans for XNA (which covers PC, Xbox360 and WinPhone7) look to not include the PC. The Xbox360 is a static piece of hardware, whereas the PC has continued to develop, and now there's Directx10, 10.1 and 11, which the Xbox doesn't support. Microsoft's current strategy around XNA seems to be to standardize the API to allow developers to create games for the 3 platforms at once really easily. However, this flexibility comes at the price of supporting the PC's newer capabilities.
I tried to find out if XNA 4.0 supported DX10, 10.1 and 11, but I had trouble finding a clear answer, so I'm not sure if it does. In contrast, SlimDX supported Direct3D10 in 2008, and added beta support for Direct3D11 & Direct2D in August 2009. SlimDX tends to release a few times a year, whereas XNA is once a year.
I'd love to quote actual sources instead of giving vague comments, but I found it all through google, and now 8 months later, I can't remember where I read any of it. This is the only source I've read recently that I could actually find:
http://www.theindies...th-of-an-indie/
I encourage you to dig deeper and decide for yourself.
Microsoft's strategy makes sense if you assume that every coder knows DirectX/C++ just as well as they know C# and have plenty of time on their hands. If you want to use API's that are newer than 3 years old, you should use C++. If you want to cover several platforms, you should use XNA.
Alternatively, if you're not a c++ guru, and want to use C# *AND* make use of the latest API's, SlimDX is the way to go in my opinion.
Both are valid choices. The support of lack thereof for anything past Direct3D9 isn't going to help or hinder you. The final look of your game will depend on your artist, not the version of the underlying API.
I didn't like XNA because of the content pipeline thing. Last time I used XNA -- which was awhile ago and not very extensively -- I felt like I was basically forced to compile all of my assets into the executable itself, which made user modification sort of impossible, which undercut what I was trying to do. Also rebuilding because I changed some sprite got annoying.
The content pipeline is there for those who want to use it. Otherwise, ignore and load your own files. You can even use XNA's handy functions that let you load textures from external files.
I didn't like XNA because of the content pipeline thing. Last time I used XNA -- which was awhile ago and not very extensively -- I felt like I was basically forced to compile all of my assets into the executable itself, which made user modification sort of impossible, which undercut what I was trying to do. Also rebuilding because I changed some sprite got annoying.
The content pipeline is only some big, evil, limiting feature to those who can't read the API documentation, and spread kneejerk FUD over dev forums.
I didn't like XNA because of the content pipeline thing. Last time I used XNA -- which was awhile ago and not very extensively -- I felt like I was basically forced to compile all of my assets into the executable itself, which made user modification sort of impossible, which undercut what I was trying to do. Also rebuilding because I changed some sprite got annoying.
The content pipeline doesn't build content into the executable. It merely compiles the various files you put in it into an intermediate format readable by all platforms. All files are accessible to user modification if you write tools for them, and the 3D model format is actually FBX, which is heavily supported by various modeling tools. If you change any files inside the content project, you don't rebuild the whole application application. All it does is convert the single file you added to it, and nothing more.
You also don't need to use the content pipeline at all for the most part. The only time you actually need to use them is for effect files and sprite fonts.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
