By VengantMjolnir  on Tue 30 of Mar., 2010 14:34 PDT

Welcome back to my tutorial series on 2D dynamic shadows. In this article I'm going to explain what blend modes are available in flash, and what each of the blend modes does. Why blend modes? They are extrememly useful for controlling the color of pixels and as you'll see, crucial to my shadow implementation. I'll go into that detail in a later article, where we are going to examine which blend modes are useful to create shadows.
Some of the following information is gleaned from wikipedia, some from random websites. The accompanying image to each blend mode is representation of how the blend mode looks when combining against two different images. Top left is original image while top right is blended with a gradient using the appropriate blend mode. Bottom right( I know, reveresed... ) is the gradient on its own while bottom left is it blended with a flat grey color( 0x666666. ) I'm going to discuss their usefulness as a filter for image manipulation, the specific formula that is involved and how it affects the end result.
One thing to keep in mind with all blend modes: The formula( or an optimized version of it ) is perfomed on each pixel to be blended! That means that an ADD blend will take less of your frame than an OVERLAY blend. However, since flash executes all of its code on the CPU, you are more often than not bottlenecked by pixel fill rates than anything else. Still, its worth remembering if performance is required.
A final note before I get right into it; my represenation for color here is in the form of RGB with 0-255 as possible values for each. To make a compatible flash color, this can be packed into an unsinged int using:
Color = r << 16 | g << 8 | b;

Normal blend mode

This is the standard blend mode which simply takes each pixel from the top layer if present. Otherwise the bottom layer is used. Flash uses this blend mode by default. I don't think this requires an image.

Simple arithmetic blend modes

Addition

Add Blend Mode

This blend mode simply adds pixel values of one layer with the other. In case of values above 255, white is displayed. Commonly used to create an animated lightening dissolve effect between two images. I've also seen it used many times in particle emmitters to create a 'glow' look to the particles when they overlap. Even though it is a simple operation to perform care should be taken not to overuse it.

Formula: Result Color = Clamp((Top Color + Bottom Color), 255)

The result is a whiter picture that is technically 'brighter' but has no deeper contrast to show it.

Subtract

Subtract Blend Mode

This blend mode simply subtracts pixel values of one layer with the other. In case of negative values, black is displayed. Commonly used to create an animated darkening dissolve effect between two images. It can also be used in particles to create a 'draining' of color. Like ADD mode it has uses in specific scenarios, but is not a great utility function for image manipulation. Why? Well it really just shifts the color spectrum in one direction which results in capping of the colors. With Additive blending it caps to white while with with Subtractive it caps to black.

Formula: Result Color = Clamp((Top Color - Bottom Color), 0)

The result is a darker picture with no contrast boost. If image enhancement is your goal, check out Multiply.

Difference

Difference Blend Mode

If Difference mode both colors are subtracted from one another and then the absolute value is taken. This means that the result shows the distance between both colors. The result can look a bit strange in many cases but has a few good uses. First, this mode can be used to invert parts of the base image depending on the blend image. Also, it can be used to compare two images (if the results are black, they are equal.)

Formula: Result Color = Absolute Value( Top Color - Bottom Color)

The results are... strange but useful.

Darken

Darken Blend Mode

Replaces only the areas that are lighter than the blend color. Areas darker than the blend color don’t change. Colors can seem to behave oddly with this blend mode. However, if you understand the underlying formula then it all makes sense.

Formula: Result Color = If ( Top Color < Bottom Color )
then Result = Top Color
else Result = Bottom Color

An important thing to keep in mind is this formula is run for each color value seperately, not on the color value as a whole. This may seem counter-intuitive to some. For instance, the color Red is 0xFF0000 while Blue is 0x0000FF. If you compared the values straight across( In decimal format Red = 16711680 while Blue is 255 ) then Blue should be the darkest color. Yet, when these two blend together using BlendMode?.DARKEN the result is Black. What? Yeah... that's simply a result of the component comparisons. If TopColor?.R = 255 and BottomColor?.R = 0, the result is 0 and the same applies to the other colors.

The result is a flattening of the baseline color of the image. Usually results in a much darker image.

Lighten

Lighten Blend Mode

Replaces only pixels that are darker than the blend color. Areas lighter than the blend color don’t change. This is exactly the opposite of Darken and has a similar formula. The effect produced is also of a 'flattening' of the images color but in this case towards a lighter spectrum.

Formula: Result Color = If ( Top Color < Bottom Color )
then Result = Top Color
else Result = Bottom Color

The result is a flattened image with less color depth than before.

Erase

Erase Blend Mode

Removes all base color pixels, including those in the background image. In this example image I changed the shape of the gradient to a circle just to illustrate the point a bit better. This works like a reverse mask in flash, hiding what it overlaps instead of revealing it. Alpha is respected and if you have an alpha gradient then only part of the resulting image is masked out. I'm not going to speak much on this one here and instead keep it for later.

Formula: Honestly, I can only guess at this one. I suspect it uses a few conditionals as the result is different based on where you are using it.( example, drawing to a bitmap with BlendMode?.ERASE when the bitmap has no transparency )

Multiply and Screen

Multiply and Screen blend modes are basic blend modes for lightening or darkening images. Overlay and Hard Light can be used to improve image saturation and contrast. All of these blend modes involve some form of multiplication and are slightly more complex.

Multiply

Multiply Blend Mode

Multiply blend mode multiplies the values for each pixel of the top layer with the corresponding values of the pixel for the bottom layer. As a simple multiplication can get values as high as 65025. Since this is far higher than the maximum allowed value, 255, the result is divided by 255. Many image editing software programs offer this option. It can be used to both darken and enhance an overexposed image by blending a copy of the image with the original. Since white(0xffffff) multiplied with white is( you guessed it ) white and black(0x000000) with black produces black, dark and light parts of the picture are retained while the rest of the image is darkened.

Formula: Result Color = (Top Color * Bottom Color)/255

The result is a darker, 'enhanced', picture. It can also result in a dark picture if overused or used incorrectly.

Screen

Screen Blend Mode

With Screen blend mode the values of the pixels in the two layers are inverted, multiplied, and then inverted again. This is in some way the opposite of multiply. Where the top layer is black the underlying colour is the same, where it is white, the result is white and all other pixels are lightened. Screen is the typical fix for an underexposed image because it lightens it.

Formula: Result Color = 255 - ((255 - Top Color)*(255 - Bottom Color))/255

The result is a brighter picture. It can also result in a washed out picture.

Overlay

Overlay Blend Mode

One of the most useful blend modes for improving saturation in an otherwise correctly exposed image is the Overlay mode. Use it on the top layer of an image with two layers the same and it boosts the colours in it. Light parts of the picture become lighter and dark parts become darker. It works by applying a multiply or screen effect depending on the base colour in the image. As you can imagine, branching code is much more complex than a simple addition or multiplication. Use this with caution in any runtime code.

Formula: Result Color = If (Top Color < 128)
then Result = 2 * (Top Color * Bottom Color)
else Result = 255 - (2 * (255 - Top Color)) * (255 - Bottom Color);

The result is a picture with greater saturation.

Hard Light

Hard Light Blend Mode

The Hard Light blend mode also multiplies or screens the image but this time the result depends on the lightness or darkness of the colours on the blend layer (not the base layer). It is handy for adding lights and shadows to an image because light pixels on the top layer are lightened and dark ones are darkened. Much like Overlay, this can get expensive during runtime.

Formula: Result Color = If (Bottom Color < 128)
then Result = 2 * (Top Color * Bottom Color)
else Result = 255 - (2 * (255 - Bottom Color)) * (255 - Top Color);

The result is a picture with greater contrast and saturation.

What's next?

Apologies for this taking so long to get out. I wanted to make sure my information was both accurate and informative. Also, I didn't want to just reprint other people's words exactly. Now the next thing to tackle is how these blend modes can help create shadows!

EDIT: If you stumbled here for the blend modes, check out Lost in Actionscript

Permalink 0 comments

By VengantMjolnir  on Fri 12 of Feb., 2010 01:51 PST

This tutorial is aimed at beginners and those who use Adobe's IDE to develop. If you already use FlashDevelop, or are confident enough in your IDE of choice to use my source code, feel free to skip this tutotorial. My development environment of choice is FlashDevelop for a variety of reasons. Its free, it is well documented and it has many plugins available. Additionaly, it has many useful features such as:

• Auto-Completion
• Jump to declaration
• Configurable short-cut keys
• ASDoc Support for both generation and code hinting
• Project exploration and management panes
• Configurable viewports( able to have documents side by side )
• Comment block folding including ability to specify regions
• Extensive template and snippet support

And these are just some of the things I use on a daily basis. There are other reasons I like FlashDevelop as well but ultimately the reason for this (hopefully) short tutorial is not to convert others but simply to provide a common place to start for those who don't know, as well as a way for me to only have to support one development toolchain. With that in mind, lets get started!

Prerequisites

• FlashDevelop - Of course, get it here.
• Debug Flash Player - After downloading you'll need to run it at least once to associate .swf files with it. I reccomend getting both the projector and web plugin( AX for IE, and Adobe classes Firefox as a netscape compatible browser. ) Get it here.
• Flex SDK - My advice, just get a stable build unless you know what you are doing. Get it here.
• Java SDK 1.6+ - Sun has a lot of different versions available which can get confusing. Just download the JDK(Java Development Kit) SE, at time of writing version 6 update 18 is the most current. Get it here.
• TIME!!! Sorry, don't have a download link for this one yet...

Ok, now that you are all set you'd think the next thing to do is start a new Project. You're almost right, a quick word about folder structure is in order first. Folder structure is very important in any work flow and any programmer will tell you this. However, even though I'm a flash programmer I don't follow Adobe's best practices for flash package/folder structure. Instead I follow the approach I used when developing for C++. My folder structure runs something like this.

• Personal Projects
  • Flash
    • Specific Project
      • bin
      • src
      • assets
    • Shared
      • Core
      • External Libraries

This allows a clear seperation of core code from project specific code, and an easy way to switch between projects too since the project file lives in my Flash folder.

Now, onto the project itself. A picture is worth a bunch of words so I'll lead with that.

I know, its hard to read and its small... but you have FlashDevelop open right? No? If you seriously don't then please open it. The start page greats you with its abundance of information, just look for the 'create project' link. Or alternatively create a project from the 'Project' menu option, you're call. Once the project wizard opens up though, you should have something like the image above. Select AS3 Project, name it something you can live with( I chose to call it DynamicShadowTutorial? but that's just so I have something for the screenshots, ) and navigate to your folder structure we set up earlier. Make sure you check 'Create directory for project' or else you'll have files in wierd places. Of course, if you already set up the project directory then you can skip this step and just select that in the browse window.

Once the project is created you should have something similar to what I listed above. You still have to create an assets folder but that can wait if you are feeling lazy. What can't wait is the moving of the project file itself... There are other ways to do this but in this case it is easier to explain the moving of one file as opposed to a directory structure. To accomplish this with the minimum of fuss, close the project in FlashDevelop( via the 'Project' menu option. ) Then copy/paste, cut/paste or just plain drag between 2 windows to get the project from out of the 'DynamicShadowTutorial' directory and into the one above it... which if you've been following should be the 'Flash' directory. Now, reopen this in ))FlashDevelop and you should see your project directory open in the Project pane. The reason for doing this is really simple... you can now create additional projects using the same method and your .as3proj files will all show up in the project pane. Double click on one and you have now just switched projects without having to close anything down. Plus, you now have access to the Core files from within all your projects and can share common code very easily.

If all is set up correctly you should be able to put a simple

trace( "Hello World" );

That's it for now. I'll cover blend modes in the next tutorial and how these can apply to lighting.

Permalink 4 comments

By VengantMjolnir  on Sat 12 of Dec., 2009 02:46 PST

Hey, Captain Forever is a absolutely a ton of fun and I reccomend it whole-heartedly. No, its not for everyone, but it is definetely worth a try. What is it? Well you have two options, click the link below my ship design or read my mini-review to find out.

                                                                     
                                                                     
                                                                     
                      v                                              
        |---| |     |---|                   |---|     | |---|        
         | |  +   v  | |                     | |  v   +  | |         
    --- --- --- |---| ---         |         --- |---| --- --- ---    
    |  =|  =|  = | | =  |         +         |  = | | =  |=  |=  |    
    --- --- --- |---| ---       |---|       --- |---| --- --- ---    
          ^      | |  v          | |          v  | |      ^   +      
                --- |---| |   | |---| |   | |---| ---         |      
              -+|  = | |  +   +  | |  +   +  | | =  |+-              
                --- --- --- --- |---| --- --- --- ---                
                  ^ |  =|  =|  = | | =  |=  |=  | ^                  
                    --- --- --- /---\ --- --- ---                    
                      ^   ^   ^ | @ | ^   ^   ^                      
                                |---|                                
                          v   v  | |  v                              
                        --- --- |---| --- ---                        
                        |  =|  = | | =  |=  |                        
                        --- --- |---| --- ---                        
                          +   +  | |  +   +                          
                          |   | |---| |   |                          
                                 | |                                 
                                |---|                                
                                  ^                                  
                                                                     
                                                                     
                                                                     
Pilot this vessel

Ok, Captain Forever is a fun physics based game set in a deadly space environment. You start off in this small command module with limited engines and weaponry. Then a blue helper shows up, gives you a tiny clue as to what happened and drops off some supplies. You have to grab the modules quickly and get set up since the sector is teeming with people that want to kill you. I know that's what I did.

The ships are represented by three different types of modules, girders, engines and weapons. All the modules are color coded according to their strength and weight, starting with green and moving up through yellow, orange, red, purple, blue and so on. Starting with girders, they are the structural components and form the basic framework for a ship design. Girders can only attach to other girders or the command module, but they can be used for framing for the ship or for armor to protect it. However, girders have weight and balance is important. If a ship is unbalanced it will have trouble flying straight.
Engines are pretty obvious and come in the same color ranges. It is important for engines to be in balance as well. If the ship has too many engines on one side it won't turn properly or even fly straight. However, engines are quite interesting in that they can be placed on any one of the four sides of a ship( front, back, left, right.) Depending on where an engine is placed helps to determine the role of that engine. Engines facing to the rear of the ship will fire when forward thrust is desired. Engines on either side of the ship's command module, but pointing to the rear, will fired to help turn the ship. If the design calls for a tight turn, then engines can be placed on the front facing forward to create counter-thrust and spin the ship around quickly. Lastly, engines can be placed facing out to either side and be used to strafe the ship. All of this makes for quite an intense design process and we haven't even considered weapons yet!
I'm going to refrain from directly commenting on the gameplay in this post, mostly I'm going to use it as an introduction to the game and a call-to-action to try and beat my design. Good Luck!

(I'll review the game in full very soon)

Permalink 0 comments

By VengantMjolnir  on Thu 10 of Dec., 2009 00:20 PST

I gave it a lot of thought, and I've decided to make my lighting stuff open source. However, if I'm going to do it, I'm going to do it right. So I'm going to create a series of tutorials to go along with my stuff. My reasoning behind this decision is quite simple really, I want to give back to the community I've been a part of for a while now. I've learned so much from so many sources that offered up help, tutorials or samples. Now its time I provided something someone else can use.

As a taste, I'm going to put up the roadmap for the first set of tutorials. I'll update as I get more of the tutorials put online. I trust that I leave you seriously enticed.

Dynamic Shadows in Flash AS3

The aim here is to provide a set of tutorials on how to create dynamic shadows in flash using Action Script 3. I hope to give back to the flash community in some way. I have learned a ton over the years from many places, places that offered both source code and instruction on how to implement it.

Tutorial Roadmap

1. Development Environment
   • Setting up FlashDevelop and a simple package structure. Feel free to skip if you are not a beginner.
2. Blend Modes in AS3
   • A quick talk about blend modes and how these can help use to help fake shadows and light.
3. Lights, pushing back the shadow
   • What is a light? This tutorial focuses on how light is actually the absence of darkness, and how this is a good thing.
4. Shadow Casters
   • This is a long one, so buckle up. Here we go through the drawing of shadow caster vector shapes. These are used to erase parts of the light. Bring your math skills.
5. Optimizations Part One
   • Using Box2D to pair casters and lights. You could substitue your own broadphase here.
6. Optimizations Part Two
   • Caching shadow geometry for non-moving casters.

Permalink 0 comments

By VengantMjolnir  on Sun 29 of Nov., 2009 22:33 PST

In the last couple of weeks I haven't had as much time to work on my own projects as I would like. However, that isn't to say I have been completely without progress. So without further disemination...
I began by refactoring my lighting system a bit. I'm preparing for integration into a game editor so I needed a clear way to seperate out data from behaviour. I decided to go with a factory system, and have a Create() and Destroy() method for my lights and shadow casters. I'm currently instantiating the lights and casters directly. Physics and lighting are something I haven't quite decided how exactly I'm going to set up, but I have it right now that my helper functions for my physics world return a unique ID, and I assign that to the light or caster.
I'm not currently using an actor system for the physics, I'm just assigning the unique ID to the b2Body:m_userData and then returning it. In my custom contact listener I have a simple method:

override public function BeginContact(contact:b2Contact):void 
{
	super.BeginContact(contact);
	var light:LightComponent;
	var casterID:int = -1;
	if ( contact.GetFixtureA().IsSensor() && !contact.GetFixtureB().IsSensor() )
	{
		light = LightSystem.Instance.GetLight( contact.GetFixtureA().GetBody().GetUserData() );
		casterID = contact.GetFixtureB().GetBody().GetUserData();
	}
	else if ( contact.GetFixtureB().IsSensor() && !contact.GetFixtureA().IsSensor() )
	{
		light = LightSystem.Instance.GetLight( contact.GetFixtureB().GetBody().GetUserData() );
		casterID = contact.GetFixtureA().GetBody().GetUserData();
	}
	
	if ( light != null )
	{
		light.AddShadowCaster( casterID );
		//trace( "Adding contact with light:", light.Id, casterID);
	}
}

• Component
  [+]
  • LightComponent
  • GradientLightComponent
  • TexturedLightComponent
  • ShadowCasterComponent
• System
  [+]
  • LightSystem
  • PhysicsSystem
  • RenderSystem
  • SerializationSystem
• Template
  [+]
  • GradientLightTemplate
  • LightTemplate
  • TexturedLightTemplate
• Utilities
  [+]
  • GraphicsResource
  • LightContactListener

The last thing I've done so far is start work on a very basic camera and rendering system. So far all I have is a prototype camera movement( hooked to arrow keys ) that shows off just how bare my test setup is. At least everything is moving correctly.
Demo on next page...

Permalink 0 comments

By VengantMjolnir  on Sun 29 of Nov., 2009 16:51 PST

I am continually finding things to experiment with. Its almost as if I really don't want to complete any games on my own...
I know that isn't true, but sometimes it feels like it and that makes me a bit sad. Of course, I then look at what I've accomplished and I'm usually feeling ok again. This time, it was a barcode clock that was written in javascript that I found and wanted to do over in flash.Barcode Art by Scott Blake
For those who just want the source/and or demo, here it is. Clock.zip (31.15 Kb)
Otherwise, I started by taking the images from Scott's site and vectorizing them. However, I couldn't find a font I liked so I kept the numbers and A/PM as images. Then I created a small class for the digits, and a small class for the Prefix/Suffix. Wrapping it into a driver was almost trivial.

Permalink 1 comment

By VengantMjolnir  on Sat 28 of Nov., 2009 19:35 PST

Earlier today I ran some tests on static versus instance members in actionscript. There were interesting results to me, and if you are interested they are here. After a bit of thought I ran into the conclusion that maybe getTimer() isn't very reliable. It is only millisecond precision so asking it to accumulate sub-millisecond tasks could very well be asking for trouble. Of course, flash doesn't have a more precise timer and I wasted the better part of a day finding that out. Still, it should be close enough as long as I'm sampling a larger action than a single operation.
Armed with this thunderbolt of a revelation I decided to remove the timer from the loop and sample the entire one million iterations as one. Of course, I needed a new baseline so I tested this against an empty loop.
Here are the new results, minus the time for the empty loop:( the empty loop was a consistent .3 milliseconds ) Also, the assignment operation was simply( which would have been flattened into a single operation with an optimizing compiler ):

 value = 5;

As you can see, MUCH more consistant. Now any profiling has to be taken with a grain of salt but from what is shown here it looks like there if very little difference. However, it seems that the 'static is slower than instance' appears to be wrong.
Now for the kick in the teeth (Grin). If you've been following up to this point you'll remember that I tested a 'public' static member against a 'private' instance member that had a public get function. Well I was curious just how much overhead this function introduced so I tested the same thing using a public var and public const.

WOW, what a difference eh? This would indicate that statics are indeed slower... 20 times slower!

Oh, and the last interesting thing I took out of this was: const for whatever reason seems slower than var.

Permalink 0 comments

By VengantMjolnir  on Sat 28 of Nov., 2009 15:10 PST

I was curious about the speed differences in AS3 between a static member of a class and an instance member. I frequent many forums and from a few different places I picked up the impression that static in actionscript is considered slower. However, when I went to confirm this I could see nothing.

So, I decided to test it myself. I set up a simple Profiler class that uses getTimer() to determine the interval between Start() and Stop(). I initially used this because I was testing ))GetAverageTime but(( the times returned were very small, on the order of 0.0002 ms... Yeah. I realize that I could do more complicate work to test it but I wanted a baseline that was easy to test against.

I came up with the test structure that you see below, and I figured it was a good way to start with.

for( i = 0; i < 1000000; ++i )
{
   profiler.Start();
   //... do something ...//
   profiler.Stop();
}
average[index] = profiler.GetTotalTime();
index++;
profiler.Reset();

Permalink 0 comments

By VengantMjolnir  on Mon 09 of Nov., 2009 01:08 PST

Ok, so I've had a little bit more time this weekend to work on my shadowing stuff. I still haven't fully implemented the optimizations I wanted to( some are in ) but I have made a bit of progress none the less.

My earlier lighting model was based on the idea that I would draw each light seperately into its own renderTarget( bitmapData ) and then erase the areas that the shadow casters affected. Then I would do the same for the shadow overlay with each light. Two passes, one to erase the shadow( a black renderTarget over the scene ) and another to additively blend the lights together.

However, this had problems in itself.. the overlay blend mode I was using produced bleed through of bright colors and didn't show my shadows as well as I thought it did. Turns out the test case I was using was quite a dark texture so that is why it looked ok.

So, scrapped that lighting model and went with a simpler one. Now there is only one pass for the lightmap, and it is blended multiplicatively to the background scene. This produces a much better result and takes half the rendering. That's a win in my book.

Another part of my plan was to leverage the physics engine's broadphase for my lighting manager. That way I could use the physics engine's broadphase to tell me what lights are affecting what shadow geometry. Saves me the trouble of writing my own broadphase and the performance of running two of them at once. I chose Box2D as my physics layer for a couple of reasons. One, I'm familiar with it as I've worked with it lots in the past. Two, its flexible and very full featured. Three, it has an excellent community( of which I like to consider myself part. ) Of course, since I wanted to try the newest version of Box2D I needed to brush up on the API changes. In the process I spent some time updating some of the testBed examples to work with the newest SVN version.

And now, here is another demo to try. Hit SPACE_BAR to turn on or off debug rendering. With it off there are no shadow casters in place... but that is where the game entities would be anyway.

Demo on Next Page

Permalink 0 comments

By VengantMjolnir  on Thu 05 of Nov., 2009 01:17 PST

Here is a preview of what something I'm working on. Its the beginnings of a deferred shaded 2D dynamic shadowing system...

Why? Well mostly because I wanted to see if it was possible. However, if I'm being honest, its also because I have a couple game ideas in mind that would use this system. Look forward to some more posts in the future.

Demo on next page

Permalink 0 comments