If you haven’t taken the time to come up to speed on Flash Player’s current useful gaming features and future features check out the stuff below.

Stage3D Desktop (Currently Available)
Stage3D Mobile (Coming Soon)
Epic Unreal demo running in browser through Flash Player
(Flash Player 11.2 Beta) Mouse Lock, Right, & Middle Click
Relaxing the drivers of GPU acceleration feature from 2009 to 2008 (maybe more in future releases)

There will be more information coming out over time, Flash Game Summit and GDC are a great place to come see what Adobe is doing. If you are a game developer and attending one of the conference be sure to come up to me and say hi.

Reading a bunch of posts some people just change this by hand for each project. Others post about how to change the index.template.html in the SDK templates folder. A drawback with this last approach is then all your projects will have wmode="direct" turned on, which is not necessarily bad but could cause issues in some cases.

My approach is a middle ground, I add a new template file to the templates that has the wmode="direct" enabled. Then you have the option to use the wmode="direct" by just changing your run configuration to point to this new template html file. Which I call direct.template.html and it comes out as direct.html in the bin-debug folder along side the AppName.html file. The drawback here is if you have projects that have multiple applications it will only copy over this second template for the default application. For this specific drawback you can just copy the direct.template.html over index.template.html (since direct.template.html will be in the project) and then have all them set to direct. This still gives you control over what you project should run at but not go looking for how to modify the index.template.html for each new project. Read on to see the steps I take to setup this up.

Steps to add direct.template.html and change run configuration

• Download or copy source from http://renaun.com/flex4/direct.template.txt and save it as direct.template.html in the following folder:
  • Win: C:\Program Files (x86)\Adobe\Adobe Flash Builder 4.6\sdks\4.6.0\templates\swfobject
  • Mac: /Applications/Adobe Flash Builder 4.6/sdks/4.6.0/templates/swfobject
• Create a new Flex or ActionScript Project (web not mobile). Check to see if direct.template.html is in the html-template folder.
• Run the application once to create default run configuration.
• Click on Run -> Run Configurations…
• Select the Project’s run configuration and deselect “Use default” in the “URL or path to launch”
• Change the last .html file name to “direct.html”, leaving the rest of the path the same. See image below:

The first AIR mobile application, nearly 2 years ago, I built for iOS was a game. It was so much fun using my skill set to built the application, it reminded me of the days when I was first learning how to program and how fun it is. The app is called Raining Blocks and been in the app store for almost 2 years now, it was just for fun and I don’t tell many people about it – until now.

I did Flex, since 1.5, and Flash work before joining Adobe nearly 4 1/2 years ago. The different projects have given many different programming experiences, from libraries (Pacifica), code in the Flash Player (Pacifica), server side payment integration (Shibuya/InMarket), and many demo applications. At the core I understand the Flash Player and like building components and libraries. Since joining the evangelist team I get to build more and more examples. It shouldn’t be a surprise that I augmented my examples with games when possible.

I just spoke at FITC Screens on “Digital Fun in the Digital Home” where I used applications like PickQuick and Eiden1. Both have all their source code available on github. Eiden1 was designed by my 5 year old at the time and has been to show since it uses WiiMotes through a Android IME with the Android device hooked up to the TV, a console in your pocket. Games just make sense to me when showing off cool features.

So I like games, whats all the fuss. Well, I am excited to say that my new focus as an Evangelist is Flash Gaming. I am joining the gaming evangelist team, so you’ll be seeing more posts around this topic.

How Flex works with helping you develop and design for multiple screens is provide a concept of applicationDPI. This applicationDPI is baked into the spark mobile skins, available in css media queries, and available to you any where in your code. Flex also provides a mechanism to override the applicationDPI for your needs, I will get to this in a bit. First for an example of an application making heavy use of the applicationDPI check out Caltrain Times. It is currently running across Android, iOS, and BlackBerry Tablet OS (PlayBook).

I have also personally tested it across these devices:

What is Flex's Application DPI really?

Lets start with what its not. Its not a reflection of what the device's actual DPI, for example the DPI values in the above chart. What Flex does for developers is provide 3 classifications you build your application against. They values are 160, 240, and 320, but you can think of them as small, medium, and large. Its also important to think of the Flex three DPI classification approach as your way to define what your application looks like and how it acts not relative it directly to device DPI. I explain two examples of why this is important with my Caltrain Times application. First is how to handle incorrect DPI values from the OS level. Second is applying your look to a set of devices by customizing the DPI classification in Flex. I'll get to the detail of those two examples later in the article, first lets explain application DPI.

The definition, Flex's applicationDPI takes on two meanings. If you explicitly set the value your are telling Flex that this application is skin to applicationDPI=XXX (160,240, or 320) and for the application to automatically scale the SWF and contents to the ratio of XXX/runtimeDPI. The applicationDPI classification strings can be found in mx.core.DPIClassification. For more control of how your application looks for the different DPI's do not set this value. Then the value of applicationDPI is just a classification of 160, 240, or 320 (or some arbitrary value if you wanted to your own classification). By default Flex considers any device DPI of < 200 = 160, > 200 = 240 = < 280, and > 280 = 320. Now you can override the class mx.core.RuntimeDPIProvider, in the first case this controls the scaling, the second case it sets the applicationDPI value.

The rest of the post will make use of extending mx.core.RuntimeDPIProvider to handle incorrect DPIs from the OS and control the look between phones and tables.

Handling Incorrect DPIs

It just happens that on the Android devices depending on the OS and manufacturers there is a chance of the device reporting their DPI incorrectly. I address this problem in Caltrain Times application, specifically on the Motorola Atrix, in my custom extended mx.core.RuntimeDPIProvider class. The basis of my thoughts go back to the current landscape screen resolution and screen size values. I check the resolution threshold of 1024x600=614400 and screen size to figure out case that just don't make sense. Here is the code for screenSize and pixel checking:

In the case of a high resolution 4 inch Android device with incorrect DPI of < 220 you'll find that the screenSize is getting larger then 5 inches. In my application I just looked for any device that was larger then 4.3 screen size (might have to change that as phones get larger displays) and its screen resolution < 610000 with a report DPI of < 220. If all those criteria are found I force it to return a value of 240 which the correct value I want.

Here is the code (with some checks for the my desktop case in there too):

Note: The source code can be found at https://github.com/renaun/CaltrainTimes/blob/master/src/com/renaun/mobile/dpi/CustomDPIProvider.as.

Applying your look to a set of devices by customizing the DPI classification in Flex

In this example I use similar calculations to figure out if the device is of a tablet size. The reasoning for my Caltrain Times application is that I wanted to overrider the typical DPI classification of 160 for tablets to be rendered at the DPI classification of 240. For my application with the larger look on the bigger tablet screens it feels the screen out nicely and works well. Again I go into the custom runtime DPI class to do this. Here is the code:

The "pixelCheck < 1920000 && pixelCheck != 1296000" part is to handle running it through adl on my desktop. The rest probably makes sense, in the current device landscape tablets are typically larger then 7 inches and smaller then 11 inches with a resolution greater then 1024x600. If these values show up then I apply the DPI classification of 240.

Summary

The main take away is don't take the devices DPI at face value. If you want more control of your application across various devices make use of some classification constraints and check screen size, resolution, and DPI. It might seem like a bunch of work but this class can be used across applications and projects with minor tweaks depending on content requirements. Its also a good way to figure out if its a tablet or smartphone and outside of Flex DPI classification. Enjoy.

Check out my MAX 2011 talk where I go through Caltrain Times in more detail, as well as the source code available on github.com/renaun/CaltrainTimes.

You can tell Flash what glyphs of a font to embed with the unicodeRange property. Here is an example:

What is not obvious is how to get those unicodeRange values. I created a web application that lets you input any text you want, in any language, and get back the correct unicodeRange for the exact glyphs in the input text.

Its called Flash Embed Font Unicode Range Generator.

Flash Embed Font Unicode Range Generator

It is a great tool to keep your SWf size down for mobile or for apps that are localizing to different languages where glyphs become large to include full ranges.

You can grab the source for the application on my github here.