   xna 2.0 question
  I'm following a programming book for my class and it's using XNA 2.0 i've installed XNA 3.1 game studio assuming it was compatible and it may not be...anyways i've got a second of code i've made and it almost like it is being commented out in the visual C#any ideas as to why would be nice.#if XBOX360  //on the 360, we need to be carefule about the TV's "safe" area.  screenBounds = new Rectangle((int)(Game.Window.ClientBounds.Width * 0.03f),(int)(Game.Window.ClientBounds.Height * 0.03f),Game.Window.ClientBounds.Width -(int)(Game.Window.ClientBounds.Width * 0.03f),Game.Window.ClientBounds.Height -(int)(Game.Window.ClientBounds.Height * 0.03f));#else  screenBounds = new Rectangle(0, 0, Game.Window.ClientBounds.Width, Game.Window.ClientBounds.Height);#endif
XNA 2.0 and 3.1 are somewhat source compatible. There are some changes but overall a 2.0 book should get you started and some searching should help you find alternatives to the things that changed in 3.1.I'm not sure what you're asking, but this code gives you one of two rectangles representing the screensize for either the 360 or the PC. On the 360 you have to stay away a bit from edges to prevent stuff from going off-screen with imperfect TV scaling. On the PC you don't need this, so the author of the book (this one?) used #if #else #endif to make 2 seperate code paths for either platform. These are so-called preprocessor directives, on which you can find more info here.;  Also just FYI...the Viewport class has a property named TitleSafeArea that you can use to keep your import graphics on-screen. On the PC it's the same size as your backbuffer, while on the Xbox 360 it's a bit smaller to compensate for overscan.   ;Quote:Original post by remigiusXNA 2.0 and 3.1 are somewhat source compatible. There are some changes but overall a 2.0 book should get you started and some searching should help you find alternatives to the things that changed in 3.1.I'm not sure what you're asking, but this code gives you one of two rectangles representing the screensize for either the 360 or the PC. On the 360 you have to stay away a bit from edges to prevent stuff from going off-screen with imperfect TV scaling. On the PC you don't need this, so the author of the book (this one?) used #if #else #endif to make 2 seperate code paths for either platform. These are so-called preprocessor directives, on which you can find more info here.Basically inside of visual c# it comments it out when i write that line and i can just type in whatever i want it's not compiling that section of code and i'm not sure why i though #if XBOX360 was a statement, but it's acting like a comment line instead.   ;  Anything inside the #if bracket will only be compiled if you compile your project for the Xbox 360. This means that the .cs file has to be part of an XNA Xbox 360 Project, and not a Windows project. When a preprocessor define isn't active, Visual Studio will gray out the code inside of it to indicate that it won't be compiled under the current settings.   ;  Hello,i will keep it to some information why this is useful in XNA.In XNA you can make copies of the same project for different targets (e.g. Zune, Windows, Xbox 360). If you update the code in your 'original' project all copies are updated too. So far so good.Now maybe you are doing something in your windows version different from your Xbox version. To solve the problem that the code is exactly the same in both copies, you can use so called preprocessor statements. Visual Studio knows with which settings it is told to build so it defines 'enviroment variables' with some informations. If you use somewhere #if XBOX (or XBOX360) Visual Studio looks up if it is really building for the XBOX as it comes to this part of the code. If it is building the project for Windows (will likely be the case in your book) is says 'Well not this time ... i better commend this out'. In Visual Studio the code will look like a comment (grey not green as it is not really a comment) as long as it is told to build for windows.You can test this with #if DEBUG ... come code ... #endif. If you choose debug setting on the menu the code will be executed and look just fine. As soon as you change the settings to release it will be grey and not executed.You can define your own checks with #define XYZ and use this with #if XYZ ... #endif.Hope this helps you some. Play around with it, it's useful stuff.--GWDev   ;  Here are just some simple examples (Its C++, but sorry, I can't do C# :P):#define HIGH_HEALTHvoid Init(){#ifdef HIGH_HEALTH    g_Health=999;#else    g_Health=100;#endif}With this, the compiler will comment out the line with the 100 health, because HIGH_HEALTH is defined. The user will have 999 health, built in in his application.With this://#define HIGH_HEALTHvoid Init(){#ifdef HIGH_HEALTH    g_Health=999;#else    g_Health=100;#endif}He'll have the normal 100 health, because HIGH_HEALTH is not defined and the line with the 999 will no be used (Like commented out at compile time).   