Check these out, especially the first 2.

Quote:Maybe I was also hoping for a little discussion on the pros & cons of developing with XNA compared to a native implementation from some experienced users, but I'll suppose I should just dive right in myself!

There isn't much difference. You are using DirectX 9 and the same shaders.

XNA won't give you access to DX10 features.

Quote:Original post by trancient

Maybe I was also hoping for a little discussion on the pros & cons of developing with XNA compared to a native implementation from some experienced users, but I'll suppose I should just dive right in myself!

Yeah I definitely recommend just downloading the SDK and taking a look around. As far as native vs. XNA goes...for PC you're really not very limited at all. Sure you'll have the usual issues of managed code like some small bits of increased overhead from managed wrappers and making sure the GC doesn't get your way, but in my experience those really don't pose much of an issue for game development. In the end to me it really just feels like I'm using D3D9 through a very nice framework, and I don't feel like I'm anymore limited than I would be with native D3D9 in C++ (on the contrary, using a managed environment has allowed me to some really cool things with how my game, map editor, and common framework interact that would've been difficult, time-consuming, or awkward in native code).

For the 360 things aren't quite so rosy, unfortunately. The following have either come up already, or I can see them as being future issues for my current project:

-Strictly managed code only. Can't use any native libraries through interop or CLI wrappers. Can be a headache if you've got legacy native code you'd like to leverage, or if you want to use one of the popular physics libraries.
-The .NET Compact Framework implements a subset of the .NET class library. Not all classes are available, and not all methods of the availble classes are implemented.
-Floating-point performance is poor. Most of the 360's fp power is in the vector units, which you have no access to (and the CF can't auto-vectorize it for either).
-The CF's garbage collector causes more noticable compactions than on the PC. Keeping your live object count to a minimum (and avoiding auto-boxing) is crucial for minimizing latency.
-CF isn't very good at inlining, and isn't great at handling virtual functions either.
-No access to 360-specific goodies. This includes the tesselator, MEMEXPORT, and the special fp10 back-buffer format. No access to fp10 is a real big bummer if you want HDR, since going fp16 means doubling your eDRAM footprint and losing hardware alpha-blending. Alternate color-spaces are an option, but will bring up your shader complexity and instruction count (and possibly bring up other issues with blending or multi-sampling).
-No control over tiling. It just kicks in automatically when you're rendering to a buffer that can't fit in eDRAM.

All that said, working on the 360 through XNA is still very viable. Especially if your goal isn't to produce AAA-quality graphics, or anything like that.

Unless an installer can take care of that.

-=[ Megahertz ]=-

If you wondering if a particular API or library is able to make a marketable game, then ask yourself this: "Is there anything about this API that will keep me from making a professional game?"

An installer would take care of dlls and frameworks needed for your game to run. Don't worry XNA comes with everything you need to deploy your game to the masses. Plus, most people by now have the .NET 2.0 Framework on their computers by now.

Quote:Original post by trancient
Re the PC side of XNA, I guess this is obvious to anyone familiar with .Net developement, but for me on looking into the deployment specs for a .Net app, I realised target systems will need have the .Net framework installed, plus the XNA framework to run which seems like a big barrier for marketing an Indie game to a non-technical audience.

You won't find many programs that DON'T need something installed on the target machine for them to run. Even a simple 'hello world' program in C++ needs the proper version of the C runtime to execute. You don't really notice when a program installs the newest Visual C runtime during setup, and all the random DLLs it needs. But because C# / XNA is new, and unknown to some people, this issue gets blown out of proportion.

What are the requirements of a standard C++ 3d game?

-Updated Drivers.
-Recent DirectX Redistributable
-A new C runtime that didn't ship with XP (VS 2005 or 2008 version)
-Dynamic Link Libraries for every library used
-etc...

It's no different with XNA / C# games. You just pack the xxxredist.exes onto the media which you ship your game, and install them from there if not present on the machine.