News

Add new post

deviceNormalPixelRatio: proposal for zoom-independent devicePixelRatio for HD Retina games

Reposted from /community/respimg per Marcos Caceres’ request.

This is a proposal for addition of a zoom-independent version of window.devicePixelRatio to HTML5.

The issue

Before Firefox 18 and Chrome 25, to make a 3D (WebGL) game drawn in HD, we could set the scale in <meta name="viewport"> to 1 and multiply the size of 2D things (HUD elements, menus) by window.devicePixelRatio.

However, since these versions of the browsers, devicePixelRatio started to take browser zoom level into account.

While the change works perfectly for loading of high-resolution versions of <img> images and background-images, it has been impossible to draw HUD elements in HD 3D games with correct sizes since that.

Glossary of this proposal

DPR – zoom-dependent window.devicePixelRatio.
Old DPR – devicePixelRatio behavior before Firefox 18 and Chrome 25.
New DPR – devicePixelRatio behavior since Firefox 18 and Chrome 25.

Issue details

With the old DPR, when <meta name="viewport"> scale is 1, we could simply multiply the size of HUD elements by DPR to get resolution-independent size of the element (so that it doesn’t look too small too dense displays):

//drawing a 48dip cross at (16dip;16dip)
ctx.fillRect(32 * devicePixelRatio, 16 * devicePixelRatio, 16 * devicePixelRatio, 48 * devicePixelRatio);
ctx.fillRect(16 * devicePixelRatio, 32 * devicePixelRatio, 48 * devicePixelRatio, 16 * devicePixelRatio);

On screen, the cross would have the following size with the old behavior:

Display DPI Zoom level devicePixelRatio Output size on screen
96 (1x) 100% 1 48×48
96 (1x) 200% 1 96×96
96 (1x) 400% 1 192×192
192 (2x) 100% 2 96×96
192 (2x) 200% 2 192×192
192 (2x) 400% 2 384×384

This is fine, on high-DPI displays 384×384 looks like 192×192 on low-DPI displays, so it’s correctly zoomed by 400% (48 * 4 = 192).

However, with the new DPI, DPR is multiplied by the zoom level too, so if we multiply the size by DPR, we get the element scaled twice (in the script by DPR and in the browser by zoom):

Display DPI Zoom level devicePixelRatio Output size on screen
96 (1x) 100% 1 48×48
96 (1x) 200% 2 192×192
96 (1x) 400% 4 768×768
192 (2x) 100% 2 96×96
192 (2x) 200% 4 384×384
192 (2x) 400% 8 1536×1536

On high-DPI displays, 1536×1536 looks like 768×768 on low-DPI displays. 768×768 is 1600% larger than 48×48, while we only wanted to zoom by 400%.

So, as I said before, we get the element zoomed by zoomLevel^2 instead of zoomLevel.et the element zoomed by zoomLevel^2 instead of zoomLevel.

Use case example

If you open WebQuake on a high-DPI display, you can see that the game is rendered in HD, but the HUD and the menus appear too small.

This is because I set <meta viewport> scale to 1. If I didn’t do this, the HUD size would be correct, but the game would be blurry.

What exactly I want is to render the game in HD while having the HUD drawn at correct size.

The solution

The solution is very simple.

A constant value which behaves the same way as the old DPR – doesn’t take zoom level into account.

Let it be named window.deviceNormalPixelRatio or navigator.deviceNormalPixelRatio.

Another important thing is to make it viewport scale-independent. It would have no point then, since it is to be used when viewport scale is forced to 1 (for manual scaling of selected elements).

It must be accessible from CSS queries too so we won’t have to use JavaScript to resize every element.

For HD image loading, the old devicePixelRatio would be used, and for manual <meta name="viewport"> correction, deviceNormalPixelRatio would be.

Another possible use

Along with DPI scaling, deviceNormalPixelRatio can be used to retrieve zoom level in a cross-browser way (there’s no way to retrieve zoom level yet!):

var zoom = devicePixelRatio / deviceNormalPixelRatio;

W3C Games Community Group Town Hall at GDC

The first Games Community Group event of 2012 will be held right before GDC (http://gdconf.com) on March 4th at the Mascone Center in San Francisco.

The Summit is free and open to the public. Sign up here: http://gamesCGmarch2012.eventbrite.com

The details:
Games Community Group Town Hall
Sunday, March 4 from 4-6pm

Mascone Center
Room 2002, West Hall 2nd Floor
747 Howard Street San Francisco, CA 94103

Get the map: http://maps.google.com…

So what will we do at this Town Hall?

Like our last summit, the goal of this town hall is to track the implementation of specifications this group has already recommended and extract and document new recommendations.

If you are planning to come to the Town Hall, please take the next month to continue to review the missing features/APIs we documented at our last meeting, file bugs with the browser vendors against them, and collect new features to propose to the group.

If you cannot make it on March 4th, feel free to discuss issues you care about on the mailing list, and send your proposals to me to be presented to the group. Take a look at our last report for examples of how to propose a new feature.

You can read a summary of our last report here:
http://www.w3.org/community/games/2011/11/10/w3c-games-community-group-new-game-summit-november-2011/

You can read the full report from our last summit here:
https://docs.google.com/a/bocoup.com/document/pub?id=1fs1hpZvP05ViEWtaLSmNQUV_PW2jCWS5Oe2GAdBKgl0

W3C Games Community Group New Game Summit November 2011

The Games Community Group met after the November 2011 Games Community Group Summit.

We collaboratively took notes, and have summarized our work in a W3C Games Community Group Summit Nov 2011 Summit Report.

Read the Report →

This report focuses on practical notes for the operation of the group, as well as our position on the following 17 open web standards that the games group cares about:

Existing feature overview

  • Mouselock / input locking
  • Joystick API (gamepad API (scott and ted))
  • Improvements to Web Workers

New Features

  • Orientation lock
  • Keyboard lock
  • Hardware feature detection
  • Access to screen pixel density
  • Surround sound audio support
  • General improvements to audio tag
  • High performance timers
  • Real-time peer-to-peer communications
  • Screenshot API
  • Advanced canvas rendering capabilities
  • Vector/Matrix in Javascript
  • ParrallelArray in JavaScript
  • WebGL in webworker
  • New WebGL APIs

W3C Games Community Group Summit November 2011 Agenda

W3C Games Community Group Summit Agenda

New Game Conference, November 3rd 2011

Hosted by Bocoup and Zynga

Goals For This Summit

Review the status and viability of recommendations collected at the last W3C Games Summit, collect new recommendations, and discuss strategies for communicating Open Web Game development tools to the general public.

Schedule

10 – 11am

  • History of the community group
  • Introductions
  • Community group goals
  • Existing feature request status update

11 – 11:15am

  • Break

11:15 – 12am

  • New Features

12 – 12:30pm

  • Lunch

12:30 – 1pm

  • Open source games tools

Further Reading

W3C Games Community Group Summit after New Game

We are hosting a Summit for the HTML5 Games Community Group the day after the New Game Conference (http://newgameconf.com).

The Summit is free and open to the public. Sign up here: http://newgame.eventbrite.com

The goal of the summit is to track the implementation of specifications this group has already recommended, extract and document new recommendations, and solidify a charter for this group.

The Summit will run from 10am – 1pm and be graciously hosted by Zynga at their new auditorium:

699 Eighth Street,

San Francisco, CA 94103 (corner of 8th and Townsend)

 

Welcome to the Games Community Group!

End of September 2011, a group of people passionate about games development and Web technologies gathered in Warsaw, Poland, next to the onGameStart conference, to discuss game developers needs for the next Open Web Platform.

During this half-day workshop, discussions covered more than 20 features that would ease the development of cool games using regular Web technologies. Some of these features were highlighted as candidate features worth including in potential Web standards (e.g. Joystick API, hardware feature detection, orientation lock), others as already being standardized, yet others as requiring more discussion, not a priority, not directly relevant, or out of scope of W3C. Check the full report for details.

The creation of a Games Community Group was proposed at the end of the workshop to pursue discussions, push for features of interest to be addressed by W3C working groups, monitor standardization progress, and otherwise serve as entry point for the games community in W3C. And this is how the Games Community Group came to life!

While the group starts to organize itself, I encourage you to join the group (simply follow the corresponding link on the right side of the group’s page) and introduce yourself and what you expect from the group on the public mailing-list public-games@w3.org (with public archives).