Me and my friend have been trying to build the starts of a 2D game, and we have a lot of the ground work done…but just a few questions I have.

Bare with me as I am new to XNA.  And game design.

My first questions is how important would it be to base game movements of time…what I mean is right now the game is bassed off cycles, when you hold in a button and it cycles through if you keep holding it in , the player will move as often as the program cycles through. Does this make a huge impact from one computer to another, will the player end up having a different movement speed?

I would think it would not be such a  big deal if we made the game for the xbox as all the hardware is the same…but I could be wrong ? Any insight on this would be good.

My next question has to do with resolution on the 360 We made this game bassed on being the size of 800x600. When I set the perferedbuferrsize? I think that was the syntax name, anyway…when I set the height and width to 600x800 it crops the outer sides

http://i170.photobucket.com/albums/u267/Exadon/ScreenShot.jpg

right where you see the blocks outlining the picture and the  “techno grass” on the bottom is where the game gets cut. Is there a way or a syntax to adjust it to fit? I tried making the res larger and this will help in making the bottom not cropped out…but it still droaws the right side out of my tvs view

Any insight would be great

By default, XNA games use "fixed time step": the framework calls your game's update function 60 times per second.  So unless you change the game to not used fixed time steps, it should work the same on all systems and you don't have to base things on time.

I think the second problem you're having is due to drawing outside the "safe area".  Search for that term on the forums and you'll get several threads that explain it.

Jim Hunter:

By default, XNA games use "fixed time step": the framework calls your game's update function 60 times per second.  So unless you change the game to not used fixed time steps, it should work the same on all systems and you don't have to base things on time.

 

I think the second problem you're having is due to drawing outside the "safe area".  Search for that term on the forums and you'll get several threads that explain it.

Thanks for the quick answers. searching on the safe area now

Most things that move, I've found, should be time-based, otherwise they've most too fast or too slow depending on the system they're run on.

Lord Ikon:

Most things that move, I've found, should be time-based, otherwise they've most too fast or too slow depending on the system they're run on.

David Hunt:

Lord Ikon:

Most things that move, I've found, should be time-based, otherwise they've most too fast or too slow depending on the system they're run on.

With a fixed time step, you don't have that problem. The Update method is called a fixed number of times per second, regardless of how fast or slow the machine is running. This can lead to jittering on some systems, and on especially slow systems, you might get catch-up frames. But, the total distance moved in a given time period will always be the same, no matter how fast or slow the user's machine is.

Yes, that is basically what I said. If you use time-based calculations you won't have problems of speeding up or slowing down.

Lord Ikon:

David Hunt:

Lord Ikon:

Most things that move, I've found, should be time-based, otherwise they've most too fast or too slow depending on the system they're run on.

With a fixed time step, you don't have that problem. The Update method is called a fixed number of times per second, regardless of how fast or slow the machine is running. This can lead to jittering on some systems, and on especially slow systems, you might get catch-up frames. But, the total distance moved in a given time period will always be the same, no matter how fast or slow the user's machine is.

Yes, that is basically what I said. If you use time-based calculations you won't have problems of speeding up or slowing down.

No, actually. I'm arguing that, if you use a fixed time step, time-based movement calculations aren't necessary. If I know that my update function will always be called 60 times each second, then I can use a fixed amount movement each frame and know that it always result in the same distance over a given number of seconds regardless of the speed of the machine.

Without a fixed time step, you have to use time-based movement calculations to get that effect.

How are you able to guarantee 60fps at all times even with fixed timestep enabled?

You can't always guarantee 60fps, but you can guarantee that your Update method will be called the expected number of times. As I said, on some systems you can get jitters and/or dropped render frames. If that becomes a problem, and the code's performance can't be tweaked, then a lower fixed rate can be chosen.

There are cases where free frame rate and time-based movement will work better, but for most 2D games, fixed timestep works better and is a lot easier to deal with.

Thanks for that blog post!