XNA: The title-safe area and SDTVs

11 years, 11 months ago 0
Posted in: Blog, XNA

In this article we discuss the trials of working to the title-safe area in your own Independent XNA titles. We look at the problems that this can raise and possible solutions that you should consider right from the start of the project.

On face value, working to ensure that the contents of your console / XNA title fit may sound like a trivial task. However, we have learnt our lesson well, and after our first project – we have come to realise that it’s something that you have to consider right from the beginning. Not everyone has a 42 inch 1080p screen like you might, and making sure your game works across all types of displays can cause a real headache if left to the last minute. 

Background Information

Before you start thinking about the title-safe area, you’ll need to know a little bit about where the problem comes from. I personally play my Xbox 360 on a 720p 32″ inch flat-panel. After writing a small XNA application, turns out we’re only actually seeing about 95% of the screen. Even on a modern TFT display, there is still some of the original picture lost – which we call overscan (some of the picture is being drawn ‘off the screen’).

People may be playing your game on one of a huge variety of screens. Before even thinking about overscan, consider the different types of screens shown below;

An overview of home TV screen resolutions

An overview of home TV screen resolutions

As you can see from the figure above, some gamers will be approaching your game with 2.1 million pixels on their 42″ plasma screen but others will be playing it in their bedroom on only 400 thousand pixels. Not only that, but some will have their screen in 16:9 ratio and others 4:3! All this before we even consider overscan…

If the above wasn’t enough of a headache, you also have to consider that some TVs will not display the edges of the picture. The ‘title safe’ area of a television – the area that is guaranteed to be visible, is approximately the central 85% of the screen. This means that you might (but also might not) lose a whopping 7.5% off of all sides of the picture.

The BBC advise that, in the worst case scenario on some TVs, you might lose up to 5% on the top and bottom of the screen and 10% on either side. It has been suggested that Microsoft advise that you should consider a safe area of 7.5% on each side of the screen (leaving 85% of the center of the screen as the title-safe zone). I would suggest working towards 85% of the screen as the title-safe zone.

Problem 1. Screen Resolution

You have to support all resolutions in order for your game to be accessible by everyone. Luckily, in XNA this problem can be circumvented, as the Xbox allows you to program for the 720p mode and it will automatically scale it to 1080p or SDTV for you. However, for text-heavy games, you may need to consider different interfaces for different screen sizes…

Possible Solutions

Design for 720p: The easiest, quickest and nicely satisfactory solution to the resolution problem is to design your game for 720p. As it’s the “middle” resolution, you get a fair indicator of what your game will look like across the board. Make sure that the text is bigger than you need it to be on your 720p monitor and test it on an SDTV monitor before you go to release. Your game should still look detailed on a 1080p screen and your graphics should all scale nicely (as long as none of them are too small).

Design for different resolutions: While this may generate some extra work behind the scenes, if your game heavily relies on text in the interface, or you want to make the absolute best use of the screen that the player has, then it’s a good idea to think about having 2/3 different subclasses of your “HUD” or “View Screen” classes so that you can design the output for the user.

Problem 2. Text / Icon Size

On the one hand you need to make sure that text and icons are visible on the smallest possible screen (a 14″ SDTV), especially if your 720p game is being scaled down to 480i. Alternatively, you don’t want to have text taking up a third of your 1080p screen… 

Possible Solutions

Use Icons: Icons are useful in making your game more attractive across a variety of screen sizes. If you explain what the icons mean on a ‘how to’ page with nice big chunky text for your SDTV users, then you can get away with using just fixed sized icons in your game across all screen sizes. If your icons are distinctive and clear, this means that you can get awaywith placing icons in a suitable location to make the best use of your screen on any resolution.

Let the User Decide: It might be relatively easy for you to add a ‘text size’ option to your option screen. If you allow for small, medium and large text then the user can choose the most appropriate text size for their use. If they are using a small screen, they can choose to use up more of their screen with bigger text (to make it visible), but on larger screens users might opt to have the small text – as their screens are large enough for it to still be visible.

Use Voice Acting: In many circumstances, it might be possible to backup important text items with voice acting. If you have a weapon select screen, using icons and having the name of the weapon read out will accommodate for a situation where you have made the text small. 

Problem 3. Play Area / HUD Border

You need to accommodate for screens that only show 85% of the picture. However, if you cram your interface in so that it goes around the edge of the screen with a 7.5% border on each side – you end up with a large ‘dead’ area outside of the play screen that the 80% of gamers that don’t have an overscan problem will see as ‘wasted’ space. This is possibly the hardest problem to resolve if you have left it until after development!

Possible Solutions

Minimise your HUD: This is the option that we went for with Ikaroids. By minimising the HUD so that it only consisted of 2 icons, a bar and a number, we could cram it all into one corner (which was 7.5% of the way from each edge of the screen). Gameplay still takes place underneath our HUD, so we made it low contrast and non-obtrusive.  This is a suitable solution for games that don’t need to display information.

Go ‘HUD Free’ with Popup Menus: If this option suits your game, you may want to remove the HUD altogether from your game. Additional information can be found by pressing ‘start’ on a popup menu which may (or may not) pause the action when it’s present.

Add a big fat border: In some games, such as board games and the like, it’s more than possible to simply add an artistic border to the outer 8% of each edge of the screen. The border might represent celtic flourishes around your game board or other suitably present imagery. As long as none of your game elements (board or score charts) verge into these areas and your game play is simply – this is a perfectly adequate solution.

Let the user decide: If you need a detailed HUD at the edge of the screen, and you’re conscious of maximising the use of the playing field by making the HUD as slimline as possible, you might want to have a slider bar that sets the coordinates of all of your HUD elements. Quake 1 did something similar to accommodate all gamers (although, their options weren’t for overscan, just for low-pixel gamers). Having a slider bar set a value for the overscan and moving all of your HUD items in from the edge by a specific number of pixels is reasonably simple, as long as you code for it from the start.

A case study… Ikaroids

In closing, I wanted to give you an example of how we updated Ikaroids to make it fit the ‘title-safe’ area. First of all, here is an example screen shot from before we realised that we had a problem. The title-safe area is depicted in red.

An example from Ikaroids of a bad title-safe area

An example from Ikaroids of a bad title-safe area

In the above example, you can see that many of the HUD elements are not visible on all types of screens. The score for example is so much cropped you can’t really tell what the numbers should be. In the below example, you can see that we have rectified most of these problems. The elements are all understandable even at the worst case scenario. In this example there is minor cropping, but this is the worst that it should ever be. It’s also worth noting that we had to modify the camera too, so that the edge of the map was visible. Our original camera pan only a tiny amount outside of the level (so you couldn’t ever see the edge of the level if you had large overscan). We rectified this in the most recent version.

Ikaroids with an Updated HUD to fit the title-safe area

Ikaroids with an Updated HUD to fit the title-safe area

We’d love to hear from you

I’d love to hear about how you’ve overcome these challenges in the past. If you have some natty ideas that you would like to share with the world, please feel free to leave a comment below.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>