Flimflam

You know, I've always wondered, when they created the C++11 spec, why did they create "nullptr" instead of just using the reserved but functionless "null" keyword that already exists?

Was it because people were creating their own functionality for it via macros or what have you?

Hmmmm, this sounds promising. So how does this work? I write a C++\CLI wrapper library that links to the native C++ library, and then write a C# WinForms app that references the C++\CLI wrapper?

Yes, this is essentially what you do.

The person who wrote that is absurdly wrong. There's nothing inside D3D11 that prevents you from using an OS earlier than 8 (or 8 for that matter?). What he appears to be referring to, is when building applications in Visual Studio 2011, there is no C runtime compatible with Windows XP presently, and it's (IIRC) still presently questionable if there will ever be. Applications written in that version will only run on Vista or higher.

If you're targeting D3D11 alone, that isn't even an issue, as Windows XP can't use D3D11, and if you did want to target XP with D3D9, nothing is stopping you from using an earlier version of Visual Studio.

There is a strong argument still for using Direct3D9 because XP is still in use even in the gaming world. Pretty much everyone, big studio and indie alike still targets it, because a 13% share is still statistically significant. Ignoring even ~13% as an indie can be problematic. Targeting D3D11 does reduce the number of people who can play your game; it just depends on your goals. If you're planning to sell the game, you may wish to consider targeting D3D9 for the time being. You might also consider learning D3D11 and creating an abstract rendering interface, implementing the ideals of D3D11 and translating that into D3D9 at the back end.

XP is losing ground every time a new survey is done by Valve. It's getting more and more appealing to drop D3D9 in favor of 11.

There's two things you can do for loading images, and only one, vastly unpreferred method for everything else.

1) You can load images into textures using Texture2D.FromStream(). It only loads jpegs, pngs, and bitmaps if I recall correctly. Any other format you will need to load yourself and manually set into a texture.

2) The other option is to include the XNA framework with your level editor, so you can invoke the content pipeline at runtime. This option is laughable, really, because it would require your end users install the xna framework, c# express (can't install xna without this), and the full .net 4.0 framework (ditto). In total, that's a few gigabytes of data which is relatively unrealistic to expect of your users and one of the main criticisms I ultimately have with XNA. Sounds, Sprite Fonts, Meshes, etc all would require this option to compile into xnb files at runtime as the Content Pipeline is not included in the standard runtime.

I never looked into it but there may be third party file converters out there that you may be able to utilize.

However, adding DirectX very much rubs me the wrong way. The problem with OpenGL is that it is not used enough, so switching away from it makes the situation worse for OpenGL...

If you already have a code path to support this, you should probably support it. I doubt any of the users who are currently unable to play due to this bug care about the status quo of OpenGL; they just want to play the game they paid for. You'll burn a lot of consumer good will if you simply tell these people the problem is ultimately unfixable over politics (preferring to keep it 100% OpenGL on PC.)

I love how this gets people's panties in a twist. And I love how people point out all these examples of very good programmers who've used the construct in very specific circumstances as proof that it's good, but completely ignore all of the catastrophic examples that lead to Go To Statement Considered Harmful.

I've said it before, and I'll say it again: There is absolutely no viable use case for goto in my working environment (C# 4).

I completely agree with you about there being a distinct lack of use for goto in C# but I think the reason everyone has reacted so negatively is that your first comment makes no mention of C#, where a plethora of other methods are available. It just sounded rather flamebaitish.

There's a few ways you can go about this.

1) Allow the player to pause the game, but limit the pause duration for 1 or so minutes per game. Allow the player to signify in the pause screen that they will forfeit if they don't return in time.
2) Allow the player to prompt the opponent(s) with a request for pause. If the opponent(s) do not agree then the person requesting a pause should have the option to forfeit or resume playing.

I think the second option is more polite and well rounded, personally. Sometimes people have to get up and forbidding such a necessity is really just cruel as there is a number of reasons why they may not be able to wait. It's better to just wash your hands of it and leave the choice in the hands of the players rather than yourself.

Also consider that if you just direct your users to the DX9 end-user web installer, it'll install the D3DX dlls that are missing from their machine.

The content manager loads files once and hands the reference to everything else that tries to load the same file.

Do not call Dispose on anything loaded through the content pipeline: it's not your responsibility. Instead, dispose the content manager in question and it will properly unload the resources.

When it comes to a point where you want to be able to unload individual resources, start using multiple content managers. Then when you want to unload resources, dispose of the specific content manager and it will properly dispose of its contents.

You shouldn't tell your program to re-enter the function at the end of the function, and that's why you're hitting 100% CPU usage.  You'll taking away the systems ability to delegate CPU usage as necessary by essentially locking the game into a tight loop. It's about as bad as putting your rendering function in a for(;;) loop.

I have no idea exactly what that is, but it's very possible that library is actually set up to hook itself into every application that loads. Various programs do that (FRAPS to name another one)

You are correct that making less calls to Begin() and End() are better, because each End() call submits the batch to the hardware. However, you're probably overthinking it a bit too much. You can send hundreds of batches to the hardware without really worrying about performance.

You should consider batching your sprites depending on their needs, instead of forcing everything into a single batch. Certainly batch them together as much as possible, but don't be afraid to start new batches when they need different things.

Ohhh! God.. How does one code multiplayer games with XNA?

Lidgren is a good managed library for doing networking. http://code.google.com/p/lidgren-network-gen3/

You're not supposed to use the networking stuff on Windows. It's 100% strictly supposed to be used for debugging 360 games.