   360 programming in C++?
  Is it possible to use Unmanaged C++ and DX calls to program the 360? Or is it possible to use XNA with C++? I'm writing an engine in C++ and want it to be cross platform, but stupid Microsoft only supports C# for XNA. I'd use XNA if I could, but I don't want to port the engine to C# just to support it. The way XNA "beams" things to the 360 cannot be altered, right? Because if it just sends a file over, one would think you could make a skeleton EXE and replace it at the last second, fooling it to use a C++ exe?I'd love to make 360 games but C# is not for me.   
  Unless you're a registered Xbox 360 developer with an XDK, you cannot run native code on the 360.  You can only run managed assemblies that were specifically created to target the 360's version of the .NET Compact Framework.  This means you can't call into native DLL's, nor can you use just any precompiled managed assemblies.I'm not sure if you can use C++/CLI to create a purely managed assembly that will work on the 360...officially C# is the only language supported for XNA development. Even if you could it's not really what you're looking for, since you'd still have to write all managed code.   ;  Ah, well I'm making the engine so you can swap out wrappers easily so after we make a game with it and all that I could buy an XDK license and code a 360 wrapper for it.   ;  Unless you're a recognized developer, microsoft won't sell you a license and won't allow you to distribute it until they've vetted it.   ;  It would be a great idea give for free a student edition, that can't make executables, but can run using Visual Studio, in order to avoid selling titles.So we can learn, and they can mean.   ;  Learn D3D9 and the latest version of any C++ API or function you find that starts with the letter X (XInput, XAudio2, ..) on a Windows PC. Quote:Because if it just sends a file over, one would think you could make a skeleton EXE and replace it at the last second, fooling it to use a C++ exe?Not a chance. PC x86 instructions will not run on the Power PC cores in the Xbox 360. Xbox executables are also signed and protected in a few ways that you aren't going to break. It works for C# because there's a CLR running on the XBox side so no platform specific machine code gets sent.I'd advise making your game (forget engines for anything other than learning or personal use, the commercial and open source engines already have such a head start that it's not worth it for commercial gain unless you have something *really* different) for PC but engineering and designing the code well so that you can easily port to another platform later on (e.g. if someone at MS loves your game and agrees to you publishing it on XBLA).My day job is as an engine programmer specialising in Xbox360 stuff, trust me, there isn't that much difference to progrmming for a PC. When we first got devkits, we ported the basics of a PC DirectX 9 engine to 360 in about a week!So what's significantly different from Windows PC? (and tips)* The CPU cores are PowerPC based. These don't run ANY of your x86 specific code (including MMX, SSE, etc). They have some different performance characteristics (cf. in-order execution vs out-of-order execution). They're big-endian (x86 is little endian). Your binary file access, bitfields, tricks with casting types into things they're not, etc - they all break when you port unless you're very careful. Older Apple Macs use big endian CPUs (PowerPC and 68k)* One application runs at a time and it always occupies all of the screen and machine resources. So window handling, message pumps, etc all dissappear. A lot of Win32 APIs go away too, if it's not in Win32 base (memory, files, etc), be wary.* All older Direct* interfaces are gone. No DirectDraw, no DirectPlay. This includes down-level COM interfaces, so no D3D8, etc. Only D3D9, the X* APIs, and a handful of Win32 core APIs. There are of course a bunch of new APIs :)* D3D: No fixed function pipeline. Shaders only! Shader model 3 only. [There are a few 360 specific additions to SM3]. Use HLSL. The shader assembly you know from PC isn't what the hardware uses (it isn't on PC either, but that's a different story).* D3D: Don't get too reliant on D3DX. It has some D3DX but there are better APIs out there. Some of them are cross platform and available on PC (e.g. XNA Math).* D3D: If you use the D3DX Effect system, don't use the more advanced things like scripting too much.* D3D: Render targets are a very different beast on 360. Your 360 implementation will end up completely different to your PC implementation. When designing your engine, think VERY carefully about the scope of when render targets are rendered to and when their contents are required as textures.* D3D: It's a fixed platform so there are new APIs that let you get a bit closer to the metal and expose some things you won't see on PC - but you really only need to worry about those kinds of things when you're optimising and adapting for the platform specific stuff.* Any executable that's released on Xbox360 has to go through a quality control procedure at MS. They check your game against all sorts of things on a big checklist, stuff like "does the game crash if we leave it running for more than 8 hours", "does this button on the controller do the same thing in this game as it does in every other game and does the picture of the controller on sceen look like the real one", etc. Study a few Xbox games and you'll get the idea - it's to make the gamers experience as consistent and smooth as possible. Follow the Games For Windows guidelines and you'll have covered a few points.Merry Christmas.