Ok, I am a died in the wool gameCuber, but the fact that you can DIY Flashify your X-Box 360 is very cool. That nagging voice that says “it can run flash, you must buy it” is becoming louder. Also Engadget’s X-Box meets Flash meets the borg logo is also fun.

Microsoft has released a patch to the 360 that among other things closes the ability to run Flash. This is about as useful as that windows update that just lets you (and your Redmond-based overlord) verify that your copy of windows is legal. Even though the epic battle of Adobe V. Microsoft seem to be really gearing up, I hope that Flash will be a legitimate reality on all consoles at some point.

UI development in commercial games is generally lame, hard to do, and often has a different “feel” from the game itself. My understanding of the process is that the UI always ends up being a crunch time project and a fairly complex one when you aren’t using a tool so perfectly suited to the task as Flash. For any application, Flash is an excellent tool for adding great visuals, good capabilities and for going from .

A couple of years ago I went to a great presentation at Flash Forward NYC about how Orange Design had dramatically improved the UI development and design process for Lucas Arts by making the UI for several of their PS2 games run in Flash. I’ve never been clear if the player is on PS2’s or if it is software running on the specific discs (For more information, click on the Lucas Arts in Orange Design’s “Applications” section).

There was also an interesting article on GameSpot about how Flash may make its way onto the PSP and that it hasn’t been “intentionally ignored.”

Now if Nintendo would see the light, all would be well with the world.

In my previous post I talked about how to make the background of your U10 a Flash movie, so I thought I would post the source for my first background, a random generating background. It looks fairly plain on the desktop, but when you add in all of the menu items from the device, it looks a little more interesting.

In addition to adding the circle elements, I am altering the alpha level of the non-highlighted elements of the menu. To make the menu work with any background color, the text elements are set at about 30% opacity. The Flash background I’ve been working on is a bit bold color-wise and the menu items are getting lost. By bumping the _alpha of /all/currentMenu up to 300%, you can make the text opaque.

Prior to doing a little more introspection I had previously been changing the alpha of the root, but that affects other UI elements like the translucent black overlay for system notifications like volume adjustments and connectivity. By more narrowly targeting the alpha setting, I can boost just menu text and arrows.

Another interesting thing that you can see when you start doing dynamic backgrounds is that the SWF is reloaded several times. If the backlight turns off, the background will redraw when the light comes back on. The same holds for when you change from portrait to landscape or launch and exit a game. The strange thing is that right before it redraws, you still see the old state. It isn’t that the background was ever unloaded; it was just reloaded.

I am on a bit of a U10 kick recently after doing a U10 game for my presentation at Flash Forward. Craig Babcock wrote a comment on my previous entry and as I started to rant I thought it would be better to respond as a post rather than a comment. The U10 breaks every notion of key events that I have had and manages to be internally inconsistent with itself.

In Flash 4 player world, you don’t have Key.isDown to poll a key position to do smooth interactions. Instead you rely heavily on the accessibility feature of key repetition. You hold down a key and it fires once, pauses, and then fires repeatedly and rapidly. It doesn’t make for the best experience, but with some ingenuity, you can make pretty fluid movement.

On the U1o, when you add your SWF to the device, you quickly find that the key never fires. Since we are using an accessibility feature, I wasn’t all that pissed that key repeat didn’t work for a device like this, even though I was disappointed since this narrows the types of games I can make. What did frustrate me though is that the key repeat does happen on the device UI. In menus, holding down the side of the player (the key) will continuously scroll (and even accelerate and optimize the display) until you let go. In media player and radio settings, there is functionality that relies on your holding down the button for a longer period of time.

Clearly something strange is going on. I have a few guesses of what could be going on (I have no evidence to support any of these ideas):

• FScommand2 - Perhaps there is a custom fscommand2 that can poll the key like Key.isDown. This would be essentially impossible to detect as long as it is only implemented in the protected UI.
• Different Player - The Flash games are running in a separate instance of the Flash player from the UI. You can tell this because you can set the frame rate of your game without it being slaved to a master SWF frame rate. You can also use background color and the _target for your file’s main timeline is just /. You can also tell that the UI player is not destroyed since randomized backgrounds still show their original pattern for a moment before being re-loaded. Since they are separate player instances, it has gotten me wondering if they are separate player versions. The player isn’t huge for a storage device like an MP3 Player. If I wanted to add functionality like the ability to launch the video or other broader actions and didn’t want this functionality exposed to the developer API, having a custom player for the trusted content would certainly be a route I would want to explore. None of the device identification elements seem specific enough to provide useful information on this theory.
• on() event shenanigans - I have the most negative evidence for this one. I thought that they might have mapped another key on the keyboard for for the purpose of a keyUp action so I created a button that maps every key that I could think of that was mappable in Flash 4. None returned anything unexpected. The only other things I can think of is a custom event like a keyUp (though that precise name didn’t seem to work) or there is a key that I am not thinking of to listen for.

Since I am pretty well thwarted I only have one possible test left. Some of my experiments with the UI have ended up screwing up the buttons. If I can find where they sit and unload the parent of the buttons, any buttons I add in my custom SWFs should start firing.

IMPORTANT NOTE: If you decide to give this a try, put your actions in something like a thumbnail file, NOT the background. If you screw up your UI in a thumbnail, you can restart the device and go back to the main menu. If you screw up your background, you could make it very challenging to get the device able to sync to your computer to overwrite the bad SWF. Since the device uses Flash buttons to give permission to the Power & Data selector, you need this to remain functional. Luckily, the power button seems to be a device control, not a Flash UI control, so you shouldn’t be able to break that.

Last night we launched Flash Player 9,0,60,120, a public beta of our next update to Flash Player. There are some pretty interesting features in it, most notably an enhancement to the full Screen, and a new caching system to let you download the Flex Framework once.

Read on for some details, but also check out Tinic’s Blog and his article about Flash Player 9 Update 3 Beta.

Full Screen:
Full Screen itself is actually a few new features.

First the ActionScript API is updated to let you specify a target rectangle rather. This rectangle will be the only content shown in the full screen view. Even if you select a rectangle that is not the same aspect ratio as the screen, it will still only show your rectangle and will show the background color as bars when needed.

As the player transitions from the web page to full screen, you will notice the next feature, transition. The transition will zoom from the embedded SWF in the browser and quickly take over the whole screen. This transition will give the end user information about what is going on, and what caused the full screen behavior to occur. I like the idea of transitions a lot. This let’s your eye track any elements you are watching as you enter full screen. Otherwise there is some possibility of loss of orientation on the screen during a direct change to full screen.

Once in full screen, the fun really starts. While Flash is painting a LOT more pixels on the screen, you’ll actually see your processor levels fall. Flash Player 9 update introduces “hardware scaling,” and will very efficiently render your content to screen. I’ve seen some internal demos that are pretty amazing. There are a few caveats though.

1. This is beta software!
2. If you are using software like VMWare or Parallels, you may experience a crash. Before going into fullScreen mode, right click in the player and choose settings. In the Settings UI you will find a disable hardware scaling option. Make sure it is disabled to prevent the crash.
3. As a developer, realize that not everyone viewing your content may be seeing it in hardware scaling. If the user’s video card does not support this functionality, the processing will be done through Flash’s traditional method.

Flash Player cache

Also as part of this beta release we are introducing a new way of caching Adobe platform components like the Flex framework. The framework is going to be an externalized file that Flash Player can download, verify and store on your local machine. The next time you need this file, from the same site, or any other site using this same file, you won’t need to download it again.

For Flex users, this means that the Flex framework will not be adding to your application from now on. You can take advantage of the UI components, but still deliver very small SWF files.

Wait, there’s more!
For the rest of the features and enhancements like recursive External Interface calls, multi-core support and more, take a look at the release notes.

Ok, I am a died in the wool gameCuber, but the fact that you can DIY Flashify your X-Box 360 is very cool. That nagging voice that says “it can run flash, you must buy it” is becoming louder. Also Engadget’s X-Box meets Flash meets the borg logo is also fun.

Microsoft has released a patch to the 360 that among other things closes the ability to run Flash. This is about as useful as that windows update that just lets you (and your Redmond-based overlord) verify that your copy of windows is legal. Even though the epic battle of Adobe V. Microsoft seem to be really gearing up, I hope that Flash will be a legitimate reality on all consoles at some point.

UI development in commercial games is generally lame, hard to do, and often has a different “feel” from the game itself. My understanding of the process is that the UI always ends up being a crunch time project and a fairly complex one when you aren’t using a tool so perfectly suited to the task as Flash. For any application, Flash is an excellent tool for adding great visuals, good capabilities and for going from .

A couple of years ago I went to a great presentation at Flash Forward NYC about how Orange Design had dramatically improved the UI development and design process for Lucas Arts by making the UI for several of their PS2 games run in Flash. I’ve never been clear if the player is on PS2’s or if it is software running on the specific discs (For more information, click on the Lucas Arts in Orange Design’s “Applications” section).

There was also an interesting article on GameSpot about how Flash may make its way onto the PSP and that it hasn’t been “intentionally ignored.”

Now if Nintendo would see the light, all would be well with the world.

Making games for the U10 is fun, but I also want to be able to customize the Flash Lite UI that runs the rest of the device. I’ve gotten pretty far, so I thought I’d share what I learned in hopes that others are looking into this and can share what they have learned.

The Problem
The Iriver does a really good job of protecting its UI SWF. When you hook the device up to your computer you can see some directories, but there must be some that are simply not exposed. There are two main directories on the device, media which holds the DRM audio/video and can’t be modified except through Windows media player. The other directory is Data that can be modified as you wish.

The Vulnerable Spot
When I got my U10, one of the first features that made me raise an eyebrow was picture viewing. You use a tool to transfer JPGs from your desktop to the device where they can magically be loaded. The thing is that as I have really good cause to know from my traffic cam viewer and Flickr tool, Flash Lite 1.1 can’t load JPGs. Looking at the files on the device (/data/system/pictures/) The files are .JFU and .JTH, which I assume stand for “JPG Full” and “JPG Thumbnail.”

If you transfer any of these files to your desktop and change the file extension to .SWF, the Flash Player can run the file. The image viewer works in a very similar way to my traffic cam viewer. Instead of loading a JPG, it relies on an external solution to wrap the JPG as a SWF. This isn’t a server solution like mine though. The transfer tool does the conversion as part of the transfer process.

Knowing that, it is pretty easy to make your own Flash Lite 1.1 files and start loading Flash files into the UI. The easiest way I’ve found is to export your file and take a screen shot and save it as a JPG. Move that file over using the transfer tool to make the placeholder (and thumbnail file), then replace the JFU with your SWF remembering to alter the file extension. When you disconnect your U10 and it re-boots, go to Settings>Extra>Background>Pictures>(your image directory) and select the thumbnail for your SWF.

Introspecting the UI
With a Flash background you can do some pretty cool design things, but not a whole lot technically. To do more, it is a matter of finding out more about the Flash file that loaded the background. In Flash 5 and higher, there are a lot of tools that let you introspect into a parent SWF that another is loaded into. With for...in you can find everything you could ever need to know.

Back in the reality of Flash Lite 1.1, we have a much more limited set of tools. The best tool in our small arsenal is _target. For the background it is /bgImg/photo/photoDown. It doesn’t get us as far as I’d like since you can’t find out what else is in each of the timelines. Luckily there are other places that the images appears. Some of these other locations are a bit more revealing.

Full SWF as the Background:
/bgImg/photo/photoDown

Thumb SWF in the Background Selector:
UI in landscape:
/all/currentMenu/setupPhotoList/listBox/list2/photo
UI in portrait:
/all/currentMenu/setupPhotoList/listBox/list3/photo

Full SWF viewed in the Photo Viewer:
/all/nextMenu/photo/photo/photoDown

Thumb SWF in the Photo Selector menu:
UI in landscape:
/all/currentMenu/PhotoList/listBox/list2/photo
UI in portrait:
/all/currentMenu/PhotoList/listBox/list3/photo

Also using _currentframe and _totalframes can reveal a little, but I haven’t had much chance to play with sending the various movie clips to different frames. The root does have 70 frames though, so there could be some interesting things there.

I’ve been spending my time exploring the other timelines, specifically the menu timelines. Strangely, every time I try to modify /all’s properties, it really screws things up. I have no idea how, but setting the _y of the movie clip, often makes the buttons non-functional and can even shift the UI into portrait mode. No clue why. There are however some elements off-stage if you want to take a look.

Just be careful, you can seriously screw up your ability to interact with the device. If you mess things up you can still generally connect up to your PC and replace your malfunctioning file. When it asks you whether to do power only or power and data, you may have to try a variety of buttons. If you get seriously screwed up, you can always download the firmware update tool from iRiver and reformat the device (eep!).

I am on a bit of a U10 kick recently after doing a U10 game for my presentation at Flash Forward. Craig Babcock wrote a comment on my previous entry and as I started to rant I thought it would be better to respond as a post rather than a comment. The U10 breaks every notion of key events that I have had and manages to be internally inconsistent with itself.

In Flash 4 player world, you don’t have Key.isDown to poll a key position to do smooth interactions. Instead you rely heavily on the accessibility feature of key repetition. You hold down a key and it fires once, pauses, and then fires repeatedly and rapidly. It doesn’t make for the best experience, but with some ingenuity, you can make pretty fluid movement.

On the U1o, when you add your SWF to the device, you quickly find that the key never fires. Since we are using an accessibility feature, I wasn’t all that pissed that key repeat didn’t work for a device like this, even though I was disappointed since this narrows the types of games I can make. What did frustrate me though is that the key repeat does happen on the device UI. In menus, holding down the side of the player (the key) will continuously scroll (and even accelerate and optimize the display) until you let go. In media player and radio settings, there is functionality that relies on your holding down the button for a longer period of time.

Clearly something strange is going on. I have a few guesses of what could be going on (I have no evidence to support any of these ideas):

• FScommand2 - Perhaps there is a custom fscommand2 that can poll the key like Key.isDown. This would be essentially impossible to detect as long as it is only implemented in the protected UI.
• Different Player - The Flash games are running in a separate instance of the Flash player from the UI. You can tell this because you can set the frame rate of your game without it being slaved to a master SWF frame rate. You can also use background color and the _target for your file’s main timeline is just /. You can also tell that the UI player is not destroyed since randomized backgrounds still show their original pattern for a moment before being re-loaded. Since they are separate player instances, it has gotten me wondering if they are separate player versions. The player isn’t huge for a storage device like an MP3 Player. If I wanted to add functionality like the ability to launch the video or other broader actions and didn’t want this functionality exposed to the developer API, having a custom player for the trusted content would certainly be a route I would want to explore. None of the device identification elements seem specific enough to provide useful information on this theory.
• on() event shenanigans - I have the most negative evidence for this one. I thought that they might have mapped another key on the keyboard for for the purpose of a keyUp action so I created a button that maps every key that I could think of that was mappable in Flash 4. None returned anything unexpected. The only other things I can think of is a custom event like a keyUp (though that precise name didn’t seem to work) or there is a key that I am not thinking of to listen for.

Since I am pretty well thwarted I only have one possible test left. Some of my experiments with the UI have ended up screwing up the buttons. If I can find where they sit and unload the parent of the buttons, any buttons I add in my custom SWFs should start firing.

IMPORTANT NOTE: If you decide to give this a try, put your actions in something like a thumbnail file, NOT the background. If you screw up your UI in a thumbnail, you can restart the device and go back to the main menu. If you screw up your background, you could make it very challenging to get the device able to sync to your computer to overwrite the bad SWF. Since the device uses Flash buttons to give permission to the Power & Data selector, you need this to remain functional. Luckily, the power button seems to be a device control, not a Flash UI control, so you shouldn’t be able to break that.

Making games for the U10 is fun, but I also want to be able to customize the Flash Lite UI that runs the rest of the device. I’ve gotten pretty far, so I thought I’d share what I learned in hopes that others are looking into this and can share what they have learned.

The Problem
The Iriver does a really good job of protecting its UI SWF. When you hook the device up to your computer you can see some directories, but there must be some that are simply not exposed. There are two main directories on the device, media which holds the DRM audio/video and can’t be modified except through Windows media player. The other directory is Data that can be modified as you wish.

The Vulnerable Spot
When I got my U10, one of the first features that made me raise an eyebrow was picture viewing. You use a tool to transfer JPGs from your desktop to the device where they can magically be loaded. The thing is that as I have really good cause to know from my traffic cam viewer and Flickr tool, Flash Lite 1.1 can’t load JPGs. Looking at the files on the device (/data/system/pictures/) The files are .JFU and .JTH, which I assume stand for “JPG Full” and “JPG Thumbnail.”

If you transfer any of these files to your desktop and change the file extension to .SWF, the Flash Player can run the file. The image viewer works in a very similar way to my traffic cam viewer. Instead of loading a JPG, it relies on an external solution to wrap the JPG as a SWF. This isn’t a server solution like mine though. The transfer tool does the conversion as part of the transfer process.

Knowing that, it is pretty easy to make your own Flash Lite 1.1 files and start loading Flash files into the UI. The easiest way I’ve found is to export your file and take a screen shot and save it as a JPG. Move that file over using the transfer tool to make the placeholder (and thumbnail file), then replace the JFU with your SWF remembering to alter the file extension. When you disconnect your U10 and it re-boots, go to Settings>Extra>Background>Pictures>(your image directory) and select the thumbnail for your SWF.

Introspecting the UI
With a Flash background you can do some pretty cool design things, but not a whole lot technically. To do more, it is a matter of finding out more about the Flash file that loaded the background. In Flash 5 and higher, there are a lot of tools that let you introspect into a parent SWF that another is loaded into. With for...in you can find everything you could ever need to know.

Back in the reality of Flash Lite 1.1, we have a much more limited set of tools. The best tool in our small arsenal is _target. For the background it is /bgImg/photo/photoDown. It doesn’t get us as far as I’d like since you can’t find out what else is in each of the timelines. Luckily there are other places that the images appears. Some of these other locations are a bit more revealing.

Full SWF as the Background:
/bgImg/photo/photoDown

Thumb SWF in the Background Selector:
UI in landscape:
/all/currentMenu/setupPhotoList/listBox/list2/photo
UI in portrait:
/all/currentMenu/setupPhotoList/listBox/list3/photo

Full SWF viewed in the Photo Viewer:
/all/nextMenu/photo/photo/photoDown

Thumb SWF in the Photo Selector menu:
UI in landscape:
/all/currentMenu/PhotoList/listBox/list2/photo
UI in portrait:
/all/currentMenu/PhotoList/listBox/list3/photo

Also using _currentframe and _totalframes can reveal a little, but I haven’t had much chance to play with sending the various movie clips to different frames. The root does have 70 frames though, so there could be some interesting things there.

I’ve been spending my time exploring the other timelines, specifically the menu timelines. Strangely, every time I try to modify /all’s properties, it really screws things up. I have no idea how, but setting the _y of the movie clip, often makes the buttons non-functional and can even shift the UI into portrait mode. No clue why. There are however some elements off-stage if you want to take a look.

Just be careful, you can seriously screw up your ability to interact with the device. If you mess things up you can still generally connect up to your PC and replace your malfunctioning file. When it asks you whether to do power only or power and data, you may have to try a variety of buttons. If you get seriously screwed up, you can always download the firmware update tool from iRiver and reformat the device (eep!).

Hi,

Passing this along, but it should be a great presentation! Also, if you haven’t seen a live breeze presentation, it is well worth checking one out. They are very nifty.

Creating Mobile UI Interfaces for Rich User Experiences

Tuesday, November 15, 2005
12:00 PM - 1:00 PM US/Eastern

Macrochats are online, live product discussions!

Join Andrea Trento to learn how to create mobile UI interfaces able to grant rich user experiences with Flash Lite. Flash Lite is creating a revolution in the development of rich content for mobile phones and devices. This macrochat focuses on both technical and design challenges for mobile UI interfaces, as well as helps understand the use of Flash Lite to create engaging user experiences. This session will provide an in-depth exploration of the mobile experience and mobile navigability.

What You Will Learn

*Flash Lite as a viable way to develop mobile UI interfaces
*Mobile user experience and navigability concepts
*UI input methods
*Development techniques to deliver UI interfaces for your mobile applications

Macrochat Speaker Bio:
Andrea Trento is General Manager at Interpreting.it, the communication agency he founded in 1998. His expertise includes developing Rich Internet Applications and games for mobile devices and the web, as well as advising various European government bodies on the use of web- and mobile-based technologies. He is an active contributor to the Flash Lite community and cooperates with Italy’s Macromedia User Groups Actionscript.it. As Member of Team Macromedia for Mobile and Devices, Andrea teaches different subjects related to Macromedia products and technologies and regularly contributes to Italian magazines focusing on mobile technology and development.

Register for this Macrochat here: http://www.macromedia.com/cfusion/event/index.cfm?event=detail&id=3409 75&loc=en_us

Last night we launched Flash Player 9,0,60,120, a public beta of our next update to Flash Player. There are some pretty interesting features in it, most notably an enhancement to the full Screen, and a new caching system to let you download the Flex Framework once.

Read on for some details, but also check out Tinics Blog and his article about Flash Player 9 Update 3 Beta.

Full Screen:
Full Screen itself is actually a few new features.

First the ActionScript API is updated to let you specify a target rectangle rather. This rectangle will be the only content shown in the full screen view. Even if you select a rectangle that is not the same aspect ratio as the screen, it will still only show your rectangle and will show the background color as bars when needed.

As the player transitions from the web page to full screen, you will notice the next feature, transition. The transition will zoom from the embedded SWF in the browser and quickly take over the whole screen. This transition will give the end user information about what is going on, and what caused the full screen behavior to occur. I like the idea of transitions a lot. This let’s your eye track any elements you are watching as you enter full screen. Otherwise there is some possibility of loss of orientation on the screen during a direct change to full screen.

Once in full screen, the fun really starts. While Flash is painting a LOT more pixels on the screen, you’ll actually see your processor levels fall. Flash Player 9 update introduces “hardware scaling,” and will very efficiently render your content to screen. I’ve seen some internal demos that are pretty amazing. There are a few caveats though.

1. This is beta software!
2. If you are using software like VMWare or Parallels, you may experience a crash. Before going into fullScreen mode, right click in the player and choose settings. In the Settings UI you will find a disable hardware scaling option. Make sure it is disabled to prevent the crash.
3. As a developer, realize that not everyone viewing your content may be seeing it in hardware scaling. If the user’s video card does not support this functionality, the processing will be done through Flash’s traditional method.

Flash Player cache

Also as part of this beta release we are introducing a new way of caching Adobe platform components like the Flex framework. The framework is going to be an externalized file that Flash Player can download, verify and store on your local machine. The next time you need this file, from the same site, or any other site using this same file, you won’t need to download it again.

For Flex users, this means that the Flex framework will not be adding to your application from now on. You can take advantage of the UI components, but still deliver very small SWF files.

Wait, there’s more!
For the rest of the features and enhancements like recursive External Interface calls, multi-core support and more, take a look at the release notes.