UI At Every Size

Categories Uncategorized0 Comments
[typed string0=”Missed yesterday -.-….. ” typeSpeed=”40″ startDelay=”0″ backSpeed=”40″ backDelay=”500″]
I sometimes yearn for the Doom days where hardware was more constrained and more importantly consistent!!! Today it is baseline, to develop on various screen sizes… how dare you complain!
So let’s talk about UI (User interface) and how it  scales with different screen sizes….

Cascading Style Sheets

My first experience with dynamically scaled UI was with the ol’CSS. I was just editing some front end website at the time but was impressed at how well it scaled the elements. Of course there weren’t any conditionals and complex class filtering as we’re accustomed to today. jQuery may have been doing some scaling but I can’t confirm…. (somebody probably will in the comments)

A few months after, I had the opportunity to implement a dynamic UI scaler in the Poez Inc. engine. We were shipping and supporting the iPhone 3GS when the iPhone 4 was announced. Looking at the specs sheet the first thing that hit me was the doubling of resolution (480×320 -> 960×640). This increased the pixels per inch (PPI) from 163PPI to 326PPI, which directly impacted the quality of the 2D assets, to make things more entertaining, apple introduced touch points on the API level which added a layer of abstraction from directly accessing the pixel information. This made sense from their perspective as they were juggling a few devices under the same API. On our side, it put our engine out of touch………. 😉

To keep the story short, we initially shipped a quick fix which played around with multiplication factors as well as offline anti-aliasing on previously created assets. This quickly evolved into a semi-smart module that checked assets ratios, resolution and went about to make a decision on how to appropriately place them on the screen. It was amortized as it cached these decisions after the first run.

We eventually enabled developers to do their own scaling a-la CSS. Anchors come to the rescue as they add a dimension of constraint to a very fluid problem. They are points who’s position is a division of the resolution. Think 1/2, 1/3, 1/4 of the width and height. It is still not a precise science as a picture’s dimensions may bleed into another quadrant. This is where our “placer module” will do some box intersection tests to place things accordingly (cached of course, so done once per screen resolution/ratio).

Forward to Now

I just finished shipping the update to RunawayJRider and one of our blockers had to do with some scaling issues. We decided to push-back the update by a few hours just to maintain our quality bar. In this update, we released new control schemes and some had buttons which didn’t scale well on the  iPad and similar scaled screens.

I’m very tempted to write about some batching optimization we patched up to stream UI textures with 3D data in order to better utilize graphics card buffer…. but will hold off as I have a busy day 🙂

Until next blog (on time! this time!) 😉