[MheQ]

I used

  public class Game1 : Microsoft.Xna.Framework.Game

        GraphicsDeviceManager graphics;
        SpriteBatch spriteBatch;

        Ball pall;
        MinuPad playerPad;
        public int screenWidth;
        public int screenHeight;

            public Game1()
            {
                graphics = new GraphicsDeviceManager(this);
                Content.RootDirectory = "Content";

            }

            protected override void Initialize()
            {
                screenWidth = GraphicsDevice.Viewport.Width;
                screenHeight = GraphicsDevice.Viewport.Height;

To get variable that stored screenHeight ( obvious right.. )

But I cant use the variable in different classes. For example I have a class called Ball.cs where I also need to use information about screenWidth and screenHeight.

When I try to use the same GraphicsDevice.Viewport.Width it gives me :

An object reference is required for the non-static field, method, or property 'Microsoft.Xna.Framework.Graphics.GraphicsDevice.Viewport.get'

My Question : Why cant I use GraphicsDevice.Viewport in other classes. What should I do to resolve the problem?

[MheQ]

I just kinda solved it with giving my Ball class constructor extra 2 arguments. Int newScreenWidth and int newScreenHeight . That seems a bit odd way of handling it tho it works... but what would be the correct way?

[Kilorn]

I'd suggest making ScreenWidth and ScreenHeight public static fields, since you will only ever have 1 ScreenWidth and ScreenHeight. Then you can access it from anywhere using Game1.ScreenWidth and Game1.ScreenHeight.

[BBeck]

If you are using screen dimensions, then you are probably at least updating from your class, if not drawing. So, I would suggest checking out game components. If you turn those classes into components they will have visibility to pretty much everything in Game1 and you'll be making use of some of those capabilities that Microsoft put into XNA.

[AdoTheLimey]

This brings up another question - what is the difference between setting the viewport width and height and setting the backbuffer width and height?

I set my game dimensions like so -

public static int ScreenWidth = 1280;
public static int ScreenHeight = 720;

protected override void Initialize()
        {            
            graphics.PreferredBackBufferWidth = ScreenWidth;
            graphics.PreferredBackBufferHeight = ScreenHeight;
            graphics.ApplyChanges();

            base.Initialize();
        }

[MheQ]

AdoTheLimey, on 26 September 2012 - 10:43 PM, said:

This brings up another question - what is the difference between setting the viewport width and height and setting the backbuffer width and height?

I set my game dimensions like so -

public static int ScreenWidth = 1280;
public static int ScreenHeight = 720;

protected override void Initialize()
        {            
            graphics.PreferredBackBufferWidth = ScreenWidth;
            graphics.PreferredBackBufferHeight = ScreenHeight;
            graphics.ApplyChanges();

            base.Initialize();
        }

I like that idea more to be honest..

I also now get it that if I want to use the screenwidth in other classes, I need to declare them public static ... But why is the static so important there? Shouldnt public itself let me declare stuff from other classes?

[BBeck]

AdoTheLimey, on 26 September 2012 - 11:43 PM, said:

This brings up another question - what is the difference between setting the viewport width and height and setting the backbuffer width and height?

They are two different things really. A viewport is a section of the screen. You can use them to display on multiple monitors. You can also use them to display multiple views of the game, for example if you have a 3D game with 4 players, each could have their own view of the game on the same screen.

The backbuffer is a memory buffer. The front buffer is also a memory buffer. Anything drawn into the front buffer is on the screen. Basically, the front buffer is the screen. The video card will light up pixels on the screen according to what's in the front buffer. The microsecond it's in the front buffer, the monitor will put it on the screen the next draw pass the graphics card makes to the monitor.

This causes a problem with the front buffer because you might be drawing your scene into the front buffer while the video card is trying to light up those pixels on the monitor. Drawing can be relatively slow, where as your monitor picture is redrawn every 60 seconds if your video refresh rate is set to 60Hz. You would end up with a problem where the picture is in the process of changing and redrawing at the same time. You would see the screen being redrawn because you would see the changes being made because of the slow draw rate. The screen would probably flicker with the changes and you would probably get screen tearing.

Because of that, that's not the way video cards work. The way they work is to not allow you to use the front buffer directly. They draw everything you send to them into the back buffer memory, which does not get drawn to the screen. Then when the draw is done, they do an ultra-fast copy of the back buffer into the front buffer that's basically out of your control.

Setting the preferred backbuffer is the way I've always been taught to set the screen size. Notice that it's "preferred" which means it's only a suggestion and it will decide what size it wants to make the backbuffer on it's own.

Since the frontbuffer is the screen and the backbuffer has to match it in size, the backbuffer will be your screen width.

I'm not 100% certain on this, but I believe you would have multiple viewports in one backbuffer for a split screen and a backbuffer for every monitor that you're displaying to (since you would have to have a frontbuffer for every monitor, since the monitor can't work without the frontbuffer.

So in short, viewports and backbuffers are two different things even though typically you just have the one viewport that matches the backbuffer in size when you aren't doing split screens or multiple monitors.

This post has been edited by BBeck: 27 September 2012 - 03:15 AM

[AdoTheLimey]

Thanks bbeck. That makes sense

MheQ - using my example above, if you were to declare ScreenWidth and ScreenHeight as Public, they are accessible to other classes, but that class would need a reference to the Game1 object. By declaring them as static, other classes can access them without a reference. You just need Game1.ScreenWidth

Both approaches work, but I think declaring them as static leads to cleaner code.