Cobworks

funny how i’ve always laughed at posts that tell you “how to make a scroll bar pink” because those problems seem silly or insignificant.

But after spending an entire afternoon and draining my brain of any trace of reason, I feel I need to let the world know that you can change the background color of a label. I’ve read on forums that say otherwise, but thats not quite true.

The catch is that you need to inherit from the flex label class so you can make the protected property “textField” publicly available somehow. Me, I created the following class:

package {
import mx.controls.Label;

public class BGLabel extends Label {
public function BGLabel() {
super()
}
public function getTextField():* {
return textField
}
}
}


With this, you use the BGLabel instead of the Label class in your mxml. To change the background, in actionscript you would write something like this:

myLabel.getTextField().background = true
myLabel.getTextField().backgroundColor = 0x4499CC

The reason why we need to inherit from Label is because we need access to its TextField class that the Label class is based on. TextField’s are able to change the background color’s, but labels for some reason are not. As the TextField property is protected, the only way we can get at it is to inherit.

Strangely though, if you set up a MOUSE_DOWN event listener for a label, the event passes in the TextField of the Label to the handler, not the label itself.

Other methods I tried to change the label background include using setStyle(), which doesn’t allow you to change the background color of a label. I also tried the opaqueBackground property , but I couldn’t get the background colors switching off and on the way I wanted. I would suggest you play with opaqueBackground first before you access the TextField property. But if you notice it not redrawing properly or other signs of flakiness, don’t waste an afternoon, use the TextField.

There was a time not long ago where I was super excited about the idea of really pushing Actionscript to its brink to deliver web-based games that rival the quality of older PC games (with better graphics). But alas! my dreams have been dashed! You see, Actionscript is an amazing medium; it can be used to make all kinds of applications, except applications that require any serious amount of processing.

To demonstrate my point I’ve created a wee demo. It’s a binary tree that uses recursion to draw itself. I’ve also added some code so that it can animate, but that’s more for fun rather than demonstration.

If you run the demonstration, you’ll find a very noticable delay when drawing more than 5 levels of recursion, or 126 branches. You’ll also notice that rendering takes an exponential amount of time longer compared to the next lowest number of recursions.

We aren’t splitting the atom here, we are merely drawing lines and my interpretation is that though Actionscript is great for more simple applications or a gui on a database, when it comes to serious processing power you are better off with different platforms.

For those who would argue that Actionscript is fine and I’m simply a crappy programmer (which I wouldn’t argue too much), you can optimize the code and prove me wrong here (CS4 fla here).

This is why my idea of an RTS in Flash is dead. Flash can’t handle it. Daphne is dead

BUT - Alchemy looks promising… speed of c/c++ in your browser, every browser, on every platform??? Fuck ya, that is an awesome idea (why every program for the OS then?)

Often times when speaking with clients they will complain that “something” is wrong with their FMS server(s), but rarely do they know what. And you can’t blame them, a large FMS deployment could consist of dozens of servers and server clusters pumping out and sucking in all kinds of different streams, the notion of a staging environment is not common in this senario simply because it seems impossible to test modifications using real-world test data.

What is often missing is a means simulate a real-world video load. A good way to start testing your streaming servers is to create a simple application in Flash or Flex that creates N NetConnection’s and N NetStream’s and have each ns/ns pair connect and pull a video from your FMS system. To do this, you’ll need to rely on array’s.

The idea is that you are going to loop over all the connections you want to make (careful, too many and you can grind your CPU on your test client machine to a halt) and initialize the nc objects:

var nsArr:Array = new Array();
var ncArr:Array = new Array();

for ( var i = 0, i < 500; i++ ) {
ncArr[i] = new NetConnection();
ncArr[i].connect( server );
ncArr[i].addEventListener( NetStatusEvent.NET_STATUS, onNetStatus );
}

While this is happening, your NetConnections are going to start calling onNetStatus(). In the onNetStatus() function you are going to want to create a NetStream for each NetConnection and have that newly minted NetStream start pulling down a stream:

function onNetStatus( evt ) {
var cnt = nsArr.length
nsArr[cnt] = new NetStream( evt.target );
nsArr[cnt].client = this;
nsArr[cnt].play( stream );
}

Of course, the above is to give you a head start only. There is a lot of additional things you can add. Note that the Flash runtime isn’t the most efficient software on the planet and it will consume massive amounts of system resources, so be careful!

If you wanted to load test a server that served text and misc data rather than video or audio, then the above code will need to be modified, but the principle is the same, if you want to test for 100 clients, you will need 100 NetConnection object’s initialized, with each one carrying their own data stream, be it audio, video or text.

I have recently cut some beef with Adobe and their decision to not allow the Flash player to capture keyboard input. In my game, Daphne, I see this decision as a show stopper… Imagine playing Starcraft and not being able to use hot keys in the heat of battle, lame. Hot keys are key to any self respecting RTS game developer.

Thought it is possible for players to play Daphne in a regular browser window surrounded by HTML, it loses a lot of appeal, especially as your mouse must always be over the Flash canvas in order to register certain fundamentally important (and basic) game features, such as the ability to scroll the game map when your mouse is at the edge of the canvas. It is too easy to move your mouse beyond the Flash canvas, especially when your base is being over run and you are frantically scrolling the map to look for defense or an exit. This significantly deteriorates game play.

And besides that, who wouldn’t want to play games in full screen vs a small canvas in a browser?

A limited solution is to have your Flash canvas take up 100% of the width and height of the browser page and rely on the browsers build in full screen functionality (usually activated by the F11 key). This is limited because different browsers have different notions of ‘full screen’. Firefox for example expands to full screen, but the address bar is still visible on top (though there are plug-ins that remedy this). Opera mean while implements true full screen right out of the box.

This is a limited solution for these reasons, and because the end user may need to install a new browser to play Daphne in full screen. The whole idea of using Flash as my development platform is so Daphne can be played in any environment and behave the same with no additional downloads or without troubling the end user to have to manually install 3rd party products.

Nevertheless, this proves my point that Adobe is out to lunch when it comes to the thought process behind their idea that keyboard input whilst in full screen is a security liability. It can be done by circumventing Flash and javascript entirely and just relying on the browser.

When in full screen, the Flash runtime simply won’t pass keyboard events to your code. When I first discovered this, I asked myself “why?” as it makes no sense to disable text entry simply because you are in full screen mode. I recently had a chance to ask some Adobe people why this freakin weird behaviour exists, I was told that Adobe views this as a security liability and that they are worried someone may use text entry in full screen mode for evil. They went on to say that users could be fooled into thinking a fullscreen Flash app could simulate an OS and somehow do something bad. I have no idea what. Last I checked Flash doesn’t let you access a file system or registry and OS’s don’t ask for credit card information, or personal information… actually, websites that don’t run in full screen mode do. And guess what, desktops have been running full screen apps that accept keyboard input since, well, the concept of a desktop has been around! Oddly, its not a Vista security flaw to run apps - such as games - in full screen mode and allow text input.

After a bit of back and forth with the Adobe guys, they simply said Flash is “very restrictive” and that Adobe obviously doesn’t want Flash to become a liability cause it would loose a lot of luster and possibly market share (oddly, it was me who brought up real Flash liabilities).

Though I understand the concern, It bothers me that software companies get overly anal about security. Vista is apparently the most secure Windows OS ever. So secure that it’s unusable and wastes my valuable time. If the concept of “security first, purpose later” is prevailing at Adobe like it has done at Microsoft and other large organizations, you can count me out. ironpython looks promising…

(Adobe, if you are reading, put the the glass of Kool-Aid down allow full screen text input).

When I first saw Flash go to full screen mode on youtube, my understanding of computers evolved a bit, possibilities for web-based apps began to swarm in my head.

I began to think of the big picture, this whole web platform vs traditional desktops as a developers medium, I threw Flash into the mix and realized that there are very few applications that one can’t deliver from a browser. Google apps proves that office tools don’t need to reside on a client. A myriad of other data driven web apps and RIA’s prove that everything from contact information to maps and directions to shopping, social communications, audio and video downloading and games is all readily available online.

So who needs a desktop? Well… we aren’t there yet, any seriously processor intensive app such as 3d games and video encoders are best left to the desktop to utilize the efficiency of lower level languages. But that leaves a lot of room, especially now that you can command the entire full screen of a clients computer.

Bootcamp

The basics of full screen in Flash are well documented, on a Mouse or Key event handler, just set the display mode:

stage.displayState = "fullScreen";

or

stage.displayState = "normal";

This will trigger the full screen event that you set in your main class’s constructor:

stage.addEventListener( FullScreenEvent.FULL_SCREEN, onFullScreen );

Stretching and Distortion - The Explaination

When Flash goes to full screen mode, by default, it will stretch your swf to the dimensions of your desktop. Often, I find this to be gay and annoying as the stretching will distort your content.

Lets say you have a 320×260 swf that has a video in it. The video controls dimension is 320×240, leaving you with 20 pixels on the bottom for your playback controls. That video should have an aspect ratio of 4:3.

Lets say a clients desktop is just like mine and has a resolution of 1280×800, thats an aspect ratio of 8:5 which is obviously not 4:3. If you have your swf go to full screen, by default the video will be stretched a little bit wider and if your audience cares about such things, they will likely think your site is gay and find something else.

Stretching and Distorting - The No-Stretch

To prevent any stretching from happening, Flash comes with some handy dandy flags you can set in your stage to control this kind of malarky. For my game, Daphne, I don’t want any stretching at all. I do not want my units to suddenly gain 100 pounds when the user switches to full screen, instead, I want Flash to simply expand the width and height of my swf without stretching my swf. I have a massive 3200×3200 tilemap in my game that’s always there even though the player can only see 800×600 pixels of it at a time in normal screen mode and <screenwidth>x<screenheight> pixels at a time in full screen mode.

To set these properties, throw the following lines into your applications main constructor:

stage.scaleMode = StageScaleMode.NO_SCALE;

stage.align = StageAlign.TOP_LEFT;

As you may have guessed, I’m instructing the Flash runtime to not do any vector scaling at all and to put the top left of my game in the top left of the screen (Flash tends to seemingly randomly place swf’s in full screen if you don’t provide it with some instructions).

Stretching and Distorting - The Math

If you want to scale your content’s dimensions up or down without distorting the content, consider the slope of your screen. By that I mean the rise over run. If you divide the height (rise) of your screen by the run (width) of your screen, you will get the slope. To illustrate, consider:

The standard wide screen aspect ratio of 16:9 = 9/16 = 0.5625

My 1280×800 screen = 8:5 = 5/8 = 0.625

Your standard TV dimensions 4:3 = 3/4 = 0.75

And a perfect square will have a slope of 1.

The pattern here is this: the wider the screen, the smaller the slope.

Armed with this knowledge, you are now able to manually scale your content without distorting it. The very latest update for the Flash runtime (at the time of this writing it’s 9.0.124.0) has two properties in the stage that specify the full screen width and height of your swf (even if you are in normal screen mode). They are stage.fullScreenWidth and stage.fullScreenHeight.

You now have your contents width and height as well as your screens width and height. In order to go full screen on any monitor, you need to use the awesome power of slope to determine if your contents aspect ratio is wider than the aspect ratio of your screen. If the monitor your opus is running on has a slope that is greater than your content, that means the screen has a taller aspect ratio than your content and you will need to have filler along the top and/or bottom of the screen. Conversely, if the slope of the screen is less than that of your content, your content will span the height of the screen and have filler along both sides.

Stretching and Distorting - The Magic

To figure out how to scale your content, try this:

if ( objSlope > screenSlope ) {  //span vertically, will have filler on the sides

          objHeight = screenHeight;

          objWidth /= objHeight / screenHeight;

} else if ( objSlope < screenSlope ) {   // span horizontally, filler on top and/or bottom

          objHeight /= objWidth / screenWidth;

          objWidth = screenWidth;

} else {   // same aspect ratio

          objWidth = screenWidth;

          objHeight = screenHeight;

}

With that, you can rest assured that your game or video or whatever visual object will scale and keep its aspect ratio and not be distorted. This code is best written while listening to Billy Idol’s “Rebel Yell”.

Though this is all swell, there are still some things your average, mortal Actionscript programmer can’t fix, such as text entry in full screen mode.

Mercifully, work (only?) typically occupies 8 hours of my week day. That leaves me with about 8 hours of personal time, half of which is usually spent on less exciting things like being in transit, eating, washing up, etc.

Often, at work I can’t wait to get home, I don’t think about what I will do at home and inevitably, when I get home, I spend several minutes frozen wondering what I’m going to do with my new found, temporary, precious freedom.

As I am not big on TV, I often find it difficult to wisely spend my precious free time. I am very conscious, almost obsessed, with the thought of me of the future looking back on my earlier years and asking my future self “Why was I such a useless git? What the hell did I do with my time?”.

It is for this reason that I often am programming video games in my free time. I know it is debatable whether or not mucking about with Flash and all its quirks is really a better use of my time than doing nothing, but different strokes for different folks…

The reason I like programming video games is that games are always unique. There is no standard list of GUI components you constantly use, there usually isn’t any database malarky to deal with. The GUI should be custom and unique and how the components of your game interact with each other and the user is totally up to you and what you think is awesome. I find that using standard components over and over again gets a bit boring. Finding slick new ways to access data is also quite dry. There are billions of frameworks that help make developing such classic database apps (enterprise apps?) super easy to the point that it’s no long fun to program.

Hence, I like my game programming.

The first step to creating any application of any significant size is finding a name by which to reference it. As I suck at finding cool names for things, I follow a Greek Nymph naming convention. So far Echo and Calypso have been used, so I randomly decided to choose Daphne, famed for her decision to escape Apollo’s gino-like obsession by transforming herself into a Bay Tree.

I will make no pretenses, Daphne is based upon Blizzards original Starcraft as much as possible. This is partly due to my pathetic lack of creativity, but it is also due to the fact that Starcraft is one of the best games ever made, definitely the best RTS. It is primarily for this reason that Daphne is a sort of homage to what I consider to be the best game developers on the planet right now (seriously, who makes better story lines than Blizzard? and with the glaring exception of Warcraft 3, all their games must of been at least partially developed by some sort of higher being).

So, I have started working on Daphne, So far I have the tile map stuff working fine and a lot of the multi-player communication stuff is sorted. I would like to post the game in updated carnations as I develop it, but right now, it’s so god damn ugly and lame that I’m going to have to wait until it is at least some what presentable to people with a vivid imagination.