XNA or SlimDX?
Also, the content build is a separate project in the generated workspace. If you change a file, you only rebuild the content project, not the whole thing.
If you're not using the pipeline, is there actually a compelling reason to use XNA over other game APIs?
And to reiterate, I haven't used XNA since 3.0, and I don't remember the support for non-pipelined files being particularly good /at that time/.
And to reiterate, I haven't used XNA since 3.0, and I don't remember the support for non-pipelined files being particularly good /at that time/.
If you're not using the pipeline, is there actually a compelling reason to use XNA over other game APIs?
And to reiterate, I haven't used XNA since 3.0, and I don't remember the support for non-pipelined files being particularly good /at that time/.
Short answer: Certainly!
Long answer: But it depends ultimately from person to person.
If you've been using unmanaged DirectX, the reasons might not be as compelling, but XNA conforms to the design of C#. The components like vertex buffers are designed a little more sensically (as of XNA4), things like render targets are easier to use, all of the boilerplate is already written for you, you already have access to good model and sprite rendering right out of the box, the effect framework is a bit easier to use. You don't need to worry about all the silliness like lost device handling, etc.
All that said, I have, myself, started moving towards SlimDX. Use the right tool for the job, everyone. XNA is a fantastic framework for DX9. But if you want to support 10 or 11, your only choice is SlimDX and that will likely never change until the next XBOX console is released and they intend on having an XBLIG on it as well (lets all hope!).
What kind of 'support' are you talking about? If you want to load a file, use C# file reading capabilities and load it. Use of XNA doesn't change that. Some of the XNA datatypes like textures even have member functions to load directly from a file.
And to reiterate, I haven't used XNA since 3.0, and I don't remember the support for non-pipelined files being particularly good /at that time/.
The content pipeline is simply a great tool to take all your source assets and convert them into quicker to load formats, and put them all into a big database file, similar to all other games that get published. It's like making a WAD for doom. The allegro game library can also do the same thing for you.
The content pipeline will also keep all the linked files up to date automatically by adding new versions of the file in automatically. The converted files from the pipeline are quick to load because they are stored in formats where they can be streamed into memory instead of parsed and constructed at runtime.
This also doesn't stop users from using their own data. If you want users to be able to mod and change game data, just let them put them own files in the folders, and check if they exist at runtime.
If an override file exists, load it. Otherwise grab the default one from the content pipeline. Simple.
As for why use XNA over slim DX? XNA is an entire game framework, not just an API wrapper.
If you're more of a graphics programmer and you want to use bleeding edge features to make graphical demos. Use SlimDX.
If you want to make an actual working game, XNA will help you get started a lot faster. All the base functionality is there. You just worry about your content and design for the most part. There is also close to endless documentation, articles, and tutorials.
XNA is a multiplatform game programming framework.
SlimDX is a DirectX wrapper for C#.
It's an apples and oranges comparison. They are both great, but not directly comparable.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
