What is the correct way of not supporting 50Hz only displays for community published Xbox games?

Is there an option to say the game only supports 60Hz displays when the game is published, so that the Xbox deals with the problem, or do we have to display our own message?

Andy.

Why wouldn't you want to support 50 hz displays?

I believe the XNA framework will take care of 50hz vs 60hz automatically so you'd have to manually display a message. I haven't seen any option to automatically disallow displays.

Harald Maassen:

Why wouldn't you want to support 50 hz displays?

The same reason all 6 Xbox 360 games on my shelf only support 60Hz - it's makes the job of writing and testing a multithreaded, networked, physics based game easier if they all run at the same frequency...

What do you mean by "only support 60Hz"? The video refresh rate is only somewhat related to the three things you mention.

My development partner lives in London and I'm in the midwest Stateside. That said, I've never had to write anything special to normalize the display for his TV.

As long as you do time based calculations (e.g. using GameTime), there should be almost no difference whatsoever between the frequencies. And even then, as long as you keep your update code in the update method, that is not frame-dependant.

Why wouldn't you want to support 50 hz displays?

Because I have no way of testing it? Or is there some ultra-secret trick to get 50 Hz output from a US Xbox running with a US HD (ATSC) display?

jwatte:

Why wouldn't you want to support 50 hz displays?

Because I have no way of testing it? Or is there some ultra-secret trick to get 50 Hz output from a US Xbox running with a US HD (ATSC) display?

You'd need a dev kit to that, and of course a PAL-50 compatible TV. Edit: Actually, I wonder if you had a UK RF lead whether the modulator is inside that?

If you use the time elapsed each frame to move your objects and do your calculations, the only potential problem you may run into is objects moving by bigger steps each frame than they would otherwise.  You can test for this by forcing your elapsed time variable to 20ms instead of 16.6ms.  Everything will move a bit faster, but you can check for any clipping or collision problems.

Jim Perry:

What do you mean by "only support 60Hz"?

I guess he means that they are amongst the many 360 games that will refuse to run if you if you have your 360 set to run at 50Hz.

I don't think there's any point in making a game made with the XNA framework refuse to run though. You can still have 60Hz calls to Update() so the game logic should still work identically, just the updates can't possibly all be matched with calls to Draw(). It might feel a little jerky, but it's better than not running for the people with only an old TV that doesn't support 60Hz. I shouldn't think there'd be many of those though playing games from XBLCG anyway.

abnormalsoft:

If you use the time elapsed each frame to move your objects and do your calculations, the only potential problem you may run into is objects moving by bigger steps each frame than they would otherwise.  You can test for this by forcing your elapsed time variable to 20ms instead of 16.6ms.  Everything will move a bit faster, but you can check for any clipping or collision problems.

There's more potential problems than that. What if you're doing a network game which relies upon the logic being synced between players?

Or let's say you were making a bullet hell shmup where the enemy bullet patterns are a key part of the game and they need to be consistently behaved. If you make it only support a single duration for the frames then it's significantly easier to do the work. For instance: an enemy moving at constant velocity spawns a bullet every frame, the bullet's initial position is the same as the enemy's, then each entity has its position updated according to its velocity. It's trivial to implement and you'd get a nice even pattern of bullets. How do you get the same pattern at 50Hz? Most bullets would be emitted effectively part way through a frame--you'd have to track at what time within a frame the next bullet should be emitted (taking into account that this may be later in the same frame as for the last bullet), use that time to work out where it'd be emitted from and then update its position using the remainder of the frame's time. It's clearly more work. Designing more complicated patterns so that they are the same for different frame durations would end up taking much more time. Is it worth it when you can simply write the logic for 60Hz and support 50Hz displays by letting frames get dropped?

Opprobrious:

...For instance: an enemy moving at constant velocity spawns a bullet every frame, the bullet's initial position is the same as the enemy's, then each entity has its position updated according to its velocity. It's trivial to implement and you'd get a nice even pattern of bullets. How do you get the same pattern at 50Hz? ...

Under no circumstances should you be performing critical game logic on a per frame basis. For a start, you have very little idea how stable the frame rate will be - let alone compared to other players (The 50/60hz split is another example of this).
As already mentioned in this thread, you should perform all your game logic in Update(), which is always called a set number of times per second (unless you set Game.IsFixedTimeStep to false).
The inverse of Game.TargetElapsedTime determines how many times Update() is called. The default is 60 times per second.

StatusUnknown:

Opprobrious:

...For instance: an enemy moving at constant velocity spawns a bullet every frame, the bullet's initial position is the same as the enemy's, then each entity has its position updated according to its velocity. It's trivial to implement and you'd get a nice even pattern of bullets. How do you get the same pattern at 50Hz? ...

Under no circumstances should you be performing critical game logic on a per frame basis. For a start, you have very little idea how stable the frame rate will be - let alone compared to other players (The 50/60hz split is another example of this).
As already mentioned in this thread, you should perform all your game logic in Update(), which is always called a set number of times per second (unless you set Game.IsFixedTimeStep to false).
The inverse of Game.TargetElapsedTime determines how many times Update() is called. The default is 60 times per second.

I know all this. By "frame" I mean an update of the logic. My whole point is that it can be much easier to code for consistent behaviour if you only need to code for the logic being done at a single rate.

jwatte:

Because I have no way of testing it? Or is there some ultra-secret trick to get 50 Hz output from a US Xbox running with a US HD (ATSC) display?

This answer confuses and angers me. Are you playing devil´s advocate here?

CosmicFlux:

The same reason all 6 Xbox 360 games on my shelf only support 60Hz - it's makes the job of writing and testing a multithreaded, networked, physics based game easier if they all run at the same frequency...

As mentioned, the Update() method will be called at 60Hz regardless of display frequency.

I would also strongly suggest rethinking your multithreading, networking and physics protocols if they are so reliant on framerate.

This answer confuses and angers me. Are you playing devil´s advocate here?

No. I refuse to sell a program for money when I cannot test that program first -- that's just normal ethics.
I turn on vsync, and do not use fixed time step in the framework. This means that update and render will be called at 50 Hz on PAL sets, and 60 Hz on NTSC sets. I do my own fixed time-stepping inside the Update() function, to compensate for a jittery frame rate (sometimes it may drop to 30 Hz because of VSync).
However, the PAL player will still be at a disadvantage, because 1 out of 6 update steps, he will not see one of the frames rendered, and the updates will be slightly jerky (again, the 1-in-6 frame drop).
If you use the game delta time in your time step, then you have the problem that simulation is different on a 60 Hz machine than on a 50 Hz machine, because most integrators aren't actually stable (and certainly not numerically synchronous) across different (or, worse, varying) frame rates.

jwatte:

This answer confuses and angers me. Are you playing devil´s advocate here?

No. I refuse to sell a program for money when I cannot test that program first -- that's just normal ethics.
I turn on vsync, and do not use fixed time step in the framework. This means that update and render will be called at 50 Hz on PAL sets, and 60 Hz on NTSC sets. I do my own fixed time-stepping inside the Update() function, to compensate for a jittery frame rate (sometimes it may drop to 30 Hz because of VSync).
However, the PAL player will still be at a disadvantage, because 1 out of 6 update steps, he will not see one of the frames rendered, and the updates will be slightly jerky (again, the 1-in-6 frame drop).
If you use the game delta time in your time step, then you have the problem that simulation is different on a 60 Hz machine than on a 50 Hz machine, because most integrators aren't actually stable (and certainly not numerically synchronous) across different (or, worse, varying) frame rates.

Well yeah in general I agree with you, but in this specific case there´s so many alternatives:

- If you set fixed timestep to false you can´t really count on a 60 hz update rate, as frames that have to do many calculations may drop you framerate to below 60.
- If you set it to true than you can count on 60 updates per second on both 50hz displays and 60hz displays
- You could test a 50hz update rate by setting fixed timestep to true and limiting it to 50hz
- You could manually force a 60hz update rate and fit it into a 50hz update rate.. ie your game will go slower but the state changes will be identical to a 60 hz machine. This is how a lot of old games worked - it´s not an optimal solution, but..

- All of these beat the crap out of showing a messages that says "I´m sorry but I wasn´t able to test this on a 50hz display so unfortunately you won´t be able to play this game."

Harald Maassen:

All of these beat the crap out of showing a messages that says "I´m sorry but I wasn´t able to test this on a 50hz display so unfortunately you won´t be able to play this game."

But you still haven't tested it on a 50Hz display, so what makes you think it will definately work? Fact is the majority of AAA games do actually choose not to support 50Hz, and that's a technical and commercial decision that the companies are free to choose (the Xbox TCRs specifically allow it). Unless you have worked on all those games, or at least on one of them, I'm not sure you are qualified to judge others for the course they choose to follow.

Now, I am sorry to say that above all of this noise, I don't see a definitive answer.

Let me rephrase the question - for commerical disk based games there is the option to prohibit the game running on an Xbox that can only display at 50Hz, and the ability to advertise this fact on the box prior to sale. Is there an equivalent for community games?

Andy.

You can choose what territories to sell the game in. I e, Britain is a separate territory if I remember correctly, and you can choose not to sell there.

jwatte:

You can choose what territories to sell the game in. I e, Britain is a separate territory if I remember correctly, and you can choose not to sell there.

That would be pretty stupid. Do you think no 360 owners in the UK have a TV that supports 60Hz? That's not even close to being true...

If you really want to deny access to people using 50Hz, there's a RefreshRate member of DisplayMode, so it's possible to test for and display a message or whatever. Better than assuming an entire country should be denied access...

If 10Hz destroys your physics system, then what happens when there is a 1 second delay when they open the Xbox menu console or get network lag, or anything else that makes framerate far from constant? Just do time-based updates and v-sync. That way you have constant updates and you are covered if framerate fluctuates.

On second thought, can't you just run your console through an analog connection, and change between 50/60hz?...
I'm pretty sure I've changed between them in the past.

I'm in the UK, and I doubt many Xbox 360 owners have a TV which only supports 50Hz. I'd go for a warning message that it might not play well at 50z
What's probably more of an issue is the different aspect ratio of the sceen (i.e. I think most tvs in the uk will support 60Hz, but unless they are widescreen they'll be in the PAL aspect ratio rather than NTSC). I'll have to find a CRT somewhere and work out what the 360 does with a PAL screen, and whether it is possible to code a game to avoid a black bar at the bottom.

Fippy Darkpaw:

If 10Hz destroys your physics system, then what happens when there is a 1 second delay when they open the Xbox menu console or get network lag, or anything else that makes framerate far from constant? Just do time-based updates and v-sync. That way you have constant updates and you are covered if framerate fluctuates.

You'll find that '10Hz', or more properly +3.33333 mSec per frame, will break the best of them under the 'right' conditions. Nothing to do with bad coding, just the way the numerical integration works. And fixed framerates are a key part of the solution for dealing with network lag and ensuring all clients can keep their simulations in sync.