Sign in to follow this  

Questions on capabilities and limitations of XNA and X360 Marketplace

This topic is 2548 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey,

So I'm planning starting work on a small 3D isometric/tpp RPG game as a hobby project and have enough design decisions figured out to start coding. However, while I am fairly knowledgable with C++/DirectX, I was considering switching to using C# and XNA for this project, since they give the benefit of a better language, great standard library and ability to release on the X360 marketplace. However, never havning worked with XNA (but knowing C# and .NET), I figured I might ask those more experienced. The main questions / concerns I have are:

1. Obtaining the SDK and Installation - going to apphub lets me d/l XNA 4 bundled with VS2010. However, I already have VS2005 and 2008 express, and dont want to get 2010 as well, especially considering I've been hearing it runs a bit sluggish and my PC is some 4.5 years old now. Is there any way I can get XNA with these older versions?

2. Modularity and Content Pipeline - while I definitely want to make a game, not a game engine, I nonetheless want to keep as many aspects as I can modular, especially since this is an RPG. Hence, I want to have all the content loaded on the fly depending on various configuration files for different worlds/areas. Reading on the content pipeline, it seems like you have to add all your content to your project, which completly goes against a more dynamic design. Can someone with more experience please explain to me how exactly the content pipeline works and, if it is indeed so restrictive, if I can bypass it (with possible pros / cons).

3. Capabilities of the XNA framework vs. C++/DX9 - looking at the XNA games on the official website, in the RPG section, most seem to be extremely simplistic or jRPGs style, which worries me a bit about the capabilities of the XNA Framework. I dont want to spend a month or two developing only to find the framework is too limiting to do what I want. I don't want to go into much details, but what I want is typical standard stuff - 3D environments, simple bone animations, particle systems and some post-processing (possibly shadowmaps). Overall, I am aiming for something akin to Neverwinter Nights, albeit, obviously, much smaller in scope.

4. Selling the game - I know its early to think about something like that, but if my project takes off I may be interested in selling it as an indie. This is one of the biggest reasons I am thinking of XNA, as then I could put it on the x360 marketplace. Can someone who has gone through the process (and I know there are a few here who have) elaborate on how it looks? I read the guidelines on the site which explain it (Submit - review - put on marketplace etc.) but some first-hand accounts would be great.

4b. Selling the game on windows - if I decide to sell it for the PC instead of X360, will having using C#.NET and XNA framework put any limitations on that (i.e. would I need to pay royalties to MS?)

I know choosing the right tool for the job is important so I am asking here for those who have more experience with XNA. Any and all tips, first-hand accounts or general ideas are much welcome! Also let me know if you want more details about my project.

Share this post


Link to post
Share on other sites
1. XNA GS and VS 2010 are rather connected, due to the device manager (for uploading/debugging on 360 + Phone) and the content pipeline (which piggybacks off the VS build system). You'd probably be able to reference assemblies in another version of VS, but you wouldn't be able to create XNA projects or make Content projects or debug on devices. So really the answer is "no".

2. The content pipeline works by taking source asset files (image files, 3D model files, audio files, videos, custom XML content descriptions), converting them to a standard intermediate format (Importing), and then converting to a format suitable for immediate loading and use at runtime (Processing). The simplest way to use it is to have a Content project as part of your solution in Visual Studio, and add your assets to it. Then when you build, the pipeline imports and processes files to produce .xnb files, which contain the binary representation of your runtime content. If an app is running on a PC with the full XNA Game Studio + Visual Studio install, then you can also invoke the content pipeline programatically. Some people implement map editors this way.

There's two main reasons for having a content pipeline for a game:

A) You can do heavy processing beforehand, so that it doesn't have to be done at runtime. This is crucial for quick loading times on consoles...it can take long enough just to stream the raw data into memory, so you don't want to waste time doing fixup and extra processing. And some things are only feasible if done offline, like lightmaps or PRT or generating acceleration structures for your geometry. Even DXT compression can take a long time, if you have a lot of big textures and you need mipmaps.

B) You can do your importing and processing on a platform where you actually have the libraries to do it. Any precompiled libraries (native or managed) aren't going to work on the 360. And since you can't compile C++ for the 360, it means that you're going to be limited to what's provided by XNA + .NET CF, managed assemblies specifically compiled for the 360, and any managed libraries for which you have the source cad and can be compiled against the .NET CF. So in other words...you won't have much to work with. This makes loading .mp3 audio files, texture processing, or even loading standard image file formats a real pain in the ass. In fact it used to be that the 360 didn't have any runtime functions for loading image files, but with 4.0 they added Texture2D.FromStream so that Windows Phone could load images from the internet.

So basically the content pipeline is optional in that it's nothing you couldn't implement yourself with enough time and motivation, and in that the 360 + phone still have the basic file loading API's needed to read content files and parse them at runtime. But many of the XNA Framework classes (Effect, Model, SoundEffect, Video, SpriteFont, etc.) can only be created at runtime through content pipeline data, so you'd have to roll your own solution if you needed that functionality. The "Effect" one is pretty big...it's the only way to use your own custom shaders starting with XNA 4.0, and at the same time they made it so that you can no longer just use the regular DX shader compiler.

TL:DR version is that unless have your own content pipeline, you'd probably need to have a really good reason not to use the built-in one.

3. On the PC you're more or less dealing with a managed wrapper around D3D9. You can't use any of the "driver hacks" available to access IHV-specific features and there's some weirdness regarding render targets to maintain compatibility with the Xbox 360. But for the most part you can do pretty much anything you could do in native D3D9. The 360 has the same feature set available, but you'll have to deal with the terrible CPU performance*. The 360 CPU doesn't really set the world on fire when running optimized native code, and it absolutely dies on the awful code spit out by the .NET CF. Floating point performance is a particularly painful point, especially since you have no access to the vector units. It also can't inline a lot of trivial functions, which means you have to manually inline tight inner loops for intensive things like particle system simulations. Personally I also ran into a lot of problems with high Draw call overhead, especially when predicated tiling was active. I had to use a lot of instancing/batching to get decent performance.

That said, I was working on a 3.1 game for a while and I still managed to make something that looked pretty decent and still ran at 60fps/720p/4xMSAA with HDR, shadows, etc. There's some pictures here if you want to have a look.

4. I never finished my game and wasn't ever very active in the peer review process, so I can't help you on this one. I'm sure if you browse the XNA forums you can find a lot of vocal people with opinions. :P

4b. You're pretty much free to sell your game however you want on Windows, as long as you're not using any third party libraries/tools with licensing terms that prevent you from doing so. Your one disadvantage vs. a native app is that you have to make sure .NET Runtime is installed, which means the user may have a pretty long install process for your game.

*I should mention that this was the case back when I was doing XNA stuff with 3.0/3.1 and the performance situation *might* have changed since then...but I doubt it.

Share this post


Link to post
Share on other sites
There are critical (and subtle) differences between PC and X360 so make sure you build and test against the X360 frequently.

The 10 MiB EDRAM & predicated tiling of the XBOX can catch you out.
Especially as there is no access to the hardware depth buffer.

The largest rendertarget you can use for deferred shading without triggering predicated tiling is:
1024 x 576 x 32bit (3 mrts + dsb) comes to 9 MiB
1024 x 640 x 32bit (3 mrts + dsb) comes to exactly 10 MiB but won't work

Geometry instancing (using VFETCH) on the X360 is very powerful
but if you use that power effectively your PC and X360 projects can diverge drastically.
I design my games so they work the same on PC and X360, so I simulate the PCs basic instancing with VFETCH, nothing more.

You can not change render target bindings without losing the depth stencil buffer (or paying a very heavy price)

The X360 garbage collector is quite basic - so you need to write 100% garbage free code otherwise you get stuttering, I recommend use a memory profiler continually as you work - any garbage pops up - you can find the source and solve it easily. (I am happy with scitech memprofiler)

Once you know the workarounds for the niggles XNA is a joy to work with.

Share this post


Link to post
Share on other sites
I'm working on a project that makes very minimal use of the content pipeline. The main motivation for this is to keep the tool and asset pipeline as portable (to other platforms) as possible. When you start customizing the XNA content pipeline you end up writing a lot of 'junk' support code to help it read and write your custom structures. I decided (this time around, I've done projects previously using the content pipeline as intended) I'd rather invest this time in developing something that could be reused on PC, iOS, etc.

That said, doing things this way is proving to be a lot of work so unless your goals are similar to what I described I really wouldn't recommend it. You can still dynamically load and unload content that's been processed with the XNA pipeline. Having to add it to your project is just a way of adding it to the list of assets that you want preprocessed (into XNA binary formats). I'm having to do all of this by hand with my approach, so there's really no way to avoid having a big list of assets somewhere and having a "build assets" phase to your build process. You should also note that games that are to be distributed on Xbox Live have a maximum size of 150MB. This is the size of the archive you upload, so it can be compressed as much as you want (something the content pipeline can handle automatically for you).

The peer review process can be pretty annoying, and definitely doesn't feel like you're developing for a professional platform. But all in all it's just an annoying few weeks out of your whole project.

Regarding Matt's performance comments, nothing has really changed in 4.0 on that front.

Share this post


Link to post
Share on other sites
Thank you all for the detail replies, much useful!

I think I will stick to C++ / DX9 after all. Although worse language and standard library support, at least I'm familiar with it and won't need to put up with the quirks and limitations imposed by XNA. And there's hope for some OpenGL and thus cross-platform support at some point in the future.

Also, I do not currently have an X360; I was hoping to develop for Win32 primarily and then, at a later point if the project takes off, add support for 360. But from what you describe it looks like I'd need to code from the get-go with special consideration for the xbox and test frequently, so without that I'd probably just be aiming in the dark and shooting myself in the foot in the long run.

Again, thank you for the feedback!

Share this post


Link to post
Share on other sites
Quote:
Original post by Koobazaur
2. Modularity and Content Pipeline - while I definitely want to make a game, not a game engine, I nonetheless want to keep as many aspects as I can modular, especially since this is an RPG. Hence, I want to have all the content loaded on the fly depending on various configuration files for different worlds/areas. Reading on the content pipeline, it seems like you have to add all your content to your project, which completly goes against a more dynamic design. Can someone with more experience please explain to me how exactly the content pipeline works and, if it is indeed so restrictive, if I can bypass it (with possible pros / cons).
The content pipeline is not restrictive, or mandatory.

You can load any file you want, any time you want.

The content pipeline just takes all your files at build time, and pre-compiles them into a big archive of files that are made to load real fast. It's basically a big compressed archive.

Nothing in your content pipeline gets loaded automatically. You still have to load everything manually, just like you had a folder full of files. The difference is that instead of having pngs and tgas, you have files that made to load directly into texture data as quickly as possible.

Share this post


Link to post
Share on other sites

This topic is 2548 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this