Hello all, I recently started using xna to begin game programming, after working with it for a bit, ive come to a point of look at what other roads i could have taken to learn game development. I started reading up on XNA and seen some where that it basically uses DirectX internally, which brings me to the question. By programming with XNA, am I cheating myself? Would it be more beneficial to learn actual DirectX/OpenGL programming?

That depends on what you're hoping to get out of it.

What are you hoping to achieve?

If you want to learn about making games -- or if you're just interested in actually getting things done and producing some games -- then using XNA is fine. It will allow you to get games up and running with less hassle than a lower level option, and you will still learn about the process of creating games, get to practice your programming and problem solving skills, and learn about how games are structured.

If you want to learn about how things work on a lower-level then you should take a look at DirectX and/or OpenGL. Note that you do not necessarily have to take this path if you're aiming to eventually work as a professional games developer, and it certainly isn't required of indie or hobbyists -- if you choose to do so it'll be purely to satisfy your own curiosity -- it may open up the possibility of other roles in the future working at a lower level, but you can always choose to do these things at a later stage if you wish.


Does that help?

I've spent the last ten years learning C++ and DirectX building up a reusable framework. I've been messing with XNA for about 20 hours now, and I've realized that it is laid out almost exactly like my framework is, but is 100 times more polished and functional.

At some point you will probably find that XNA is becoming a factor which limits what you can do, eg no 64bit, only DX9, a slow content build process etc. At that point you can switch it out for something more flexible, perhaps SlimDX or if you really want the C++ API.
[/quote]

If microsoft keeps it updated, I don't see any reason they won't start implement DX11 or DX12 features when it comes out. I'm sure it will always be behind, the actual DX sdk.

The problem with XNA is they're interested in portability between a console, a phone (with 4.0), and the PC. You're not going to please everybody, but to a hobbyist that portability can also be a big boon. So it really depends on what your needs are. XNA is a good platform, but it's not an end-all-product that has everything out of the box. With 4.0, it does look like they're setting themselves up for eventually being able to move onto DX10/11, and it being only DX9 I wouldn't say is a strike against not using it.

I would advise not to chug along with XNA and realize you want something else, and swap in say SlimDX. XNA's API is a lot simpler than SlimDX's because SlimDX tries to match 1:1 the native directx calls. XNA does a lot for you inbetween (and to be honest I enjoy using the XNA API, it's nice to work with). SlimDX is really useful if you want to go beyond DX9 or use the other microsoft multimedia API's in a managed context, so it has its role to play (and does its job very well in my opinion).

In most cases, if you're interested in building small and large 2D/3D applications, but aren't all that worried about the technical graphical stuff (e.g. really getting your hands dirty in directX, or even OpenGL) then stick with XNA. It's babying you for some of the low end stuff (but that's what would happen if you used an engine or other framework in most cases, that's why they exist - to make you more productive), but you still have to actually write your application, which XNA certainly won't do for you.

As for XNA's content pipeline, I say its a good thing (importing and processing content is always going to be slow, if you have a lot of it). It is bit of a headache having to do that yourself, writing importers, getting the data into a runtime format, etc. It's fairly easy to work with and extensible, so It gets a good mark in my book. Only negative thing about it is you can import/process content at runtime (e.g. making tools that import a model so you can view it). If you have a tool that uses the XNA pipeline to do something like that, you actually need to have the end-user install the full game studio and not just the redistributable.

Hello all, I recently started using xna to begin game programming, after working with it for a bit, ive come to a point of look at what other roads i could have taken to learn game development. I started reading up on XNA and seen some where that it basically uses DirectX internally, which brings me to the question. By programming with XNA, am I cheating myself? Would it be more beneficial to learn actual DirectX/OpenGL programming?

The important parts of a game are the content and the design. XNA lets you focus a lot more on that important part, and abstracts away some of the technicalities.

Direct3D and OpenGL are also libraries that abstract away the technicalities of the graphics device. You tell these standardized APIs what you want to do, and the hardware and drivers will do the real work of getting the graphics up on the screen.

C++ is an abstraction on top of machine language. It lets you write portable code that can compile and run on all kinds of platforms without having to worry about the underlying details of how those hardware platforms work. You just need to know what the expected results of any operations are under the C++ standard (give or take any compiler dependent quirks).

You're always programming with a layer of abstraction.

XNA has lots of nice tools that help you pump out a game quickly. The input system is working. There is a working and configurable timing system. The content pipeline is a huge time saver. The C# language itself has a huge library full of helpful functionality that you can use to develop your software quickly.

The important thing is that you actually get a working game out there.

[color=#1C2837][size=2]As for XNA's content pipeline, I say its a good thing (importing and processing content is always going to be slow, if you have a lot of it). It is bit of a headache having to do that yourself, writing importers, getting the data into a runtime format, etc. It's fairly easy to work with and extensible, so It gets a good mark in my book. Only negative thing about it is you can import/process content at runtime (e.g. making tools that import a model so you can view it). If you have a tool that uses the XNA pipeline to do something like that, you actually need to have the end-user install the full game studio and not just the redistributable. [/quote]The content pipeline doesn't work at runtime because that's not what a content pipeline is for. If you want to load assets at runtime, open the files and process them yourself. [color=#1C2837][size=2]The content pipeline is for pre-processing assets for quick loading, and compiling them
[color=#1C2837][size=2]into a large database file. [color=#1C2837][size=2]These are 2 different concepts that have nothing to do with each other.

In general I'd say it really only gets in the way if you want to do pretty hardcore graphics stuff. Most people that use it just use sprites and the built-in sprite rendering class, and have no problems with it. Or even if you doing basic-to-intermediate 3D stuff you can still do that pretty well, since you have access to shaders on Windows and Xbox 360. On Windows and Xbox 360 you have to go through some slower abstractions and lose actions to some key platform-specific features, which can be a real bummer if you want to do some cool new graphical techniques.

[color="#1c2837"]As for XNA's content pipeline, I say its a good thing (importing and processing content is always going to be slow, if you have a lot of it). It is bit of a headache having to do that yourself, writing importers, getting the data into a runtime format, etc. It's fairly easy to work with and extensible, so It gets a good mark in my book. Only negative thing about it is you can import/process content at runtime (e.g. making tools that import a model so you can view it). If you have a tool that uses the XNA pipeline to do something like that, you actually need to have the end-user install the full game studio and not just the redistributable.

The content pipeline doesn't work at runtime because that's not what a content pipeline is for. If you want to load assets at runtime, open the files and process them yourself. [color="#1c2837"]The content pipeline is for pre-processing assets for quick loading, and compiling them
[color="#1c2837"]into a large database file. [color="#1c2837"]These are 2 different concepts that have nothing to do with each other.
[/quote]


I'm referring to the importers in the content pipeline assemblies rather than the idea of a "content pipeline". For most, the automatic content build via MSBuild is fine, but there are cases where you would want to tap into the importers that are found in those assemblies (I'd much rather use the FBX importer and my custom processors than build my own importer). E.g. intermediate tools for processing content manually or if you have an app that allows for user-generated content. You can certainly use the content pipeline assemblies at runtime, the apphub even has an example for this. But bundling these with your app requires the end-user to have game studio installed, which can be a problem since most likely your end-user won't have it installed, it's an extra step that people should be aware of.

I think this is just worth pointing out because the topic is about if XNA is babying you or not, and this might be a question that is pertinent to someone who's interested in building an app that can be modded by its users in some fashion.