Blog — Comments Off
01
Apr 11

Random and constrained circular motion

For a small project in the near future I could need some objects to move fairly random, but constrained to a specific area. After a quick look on the web I thought of something I read before but could not find anymore. It involves movement aided by two circles and is (IMHO) really easy to grasp. Here’s a quick explanation.

Imagine (if you can’t, there a picture below doing it for you) one circle in the middle. OK, now imagine another circle centered on the edge of the first. This second circle moves over the circumference of the first, thus describing a circular motion. Now place something on the edge of the second circle and have it move over it’s circumference. Depending on the size of the circles and the rotation speeds the object on the outer circle describes a lot of different motions looking a bit like a spirograph.

The two circles and the moving object (blue)

In the above image, the red circle is the first one. The green one moves over the circumference of the red one. The blue dot moves over the circumference of the green circle. It cannot get outside of the blue circle.

This however is a very regular motion. Not what I had in mind or promised you with the title of this post. There’s no long explanation to it, so I’ll get to it right away: To make the motion random, just have the direction of both the rotations alter at random intervals. Not to often or the final object moves in a jittery fashion (and may not even leave it’s position), not to few or the object moves to predictable. In the example below you can alter the frequency of the direction change as well as the speed of rotation (with thanks to http://www.minimalcomps.com/).

Get Adobe Flash player

Right-click on the flash file to view the source files.

Blog — Comments Off
11
Mar 11

Fullscreen with masks not added to stage

Just so anyone else won’t waste any time on this…

Situation

You want a Flash file allowing fullscreen playback in the browser. Next to this you have a DisplayObject somewhere on the stage with a mask applied to it by script.

Problem

The mask does not work properly in fullscreen mode. When going fullscreen, the content scales as it should but the mask shows only a portion of what it showed before.

Solution

If you dit not add the mask to the stage (which you don’t really need to do if nothing is about to scale), the mask does not scale with the rest of the content when the StageDisplayState goes FULL_SCREEN. Because of this it reveals the same area in square pixels (w x h), but since all the rest is scaled up, this is only a small surface compared to what it revealed before.

So, the lesson to be learned: If you’re gonna allow fullscreen mode in your application and use masks, add them to the display list. Maybe just add them to the display list, period. The few times not having to type the line:

1
addChild( theMask )

probably saved less time than I had to spend hunting this error. Below an example showing the error (above) and the proper result (below).

Get Adobe Flash player

 Get Adobe Flash player

Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
package  
{
    import flash.display.Sprite;
    import flash.display.StageScaleMode;
    import flash.display.StageAlign;
    import flash.events.Event;
    import flash.geom.Point;
    import flash.text.TextField;
    import flash.text.TextFormat;
    import flash.text.TextFormatAlign;
    import flash.text.TextFieldAutoSize;
    import flash.geom.Matrix;
    import flash.display.SpreadMethod;
    import flash.display.GradientType;
   
    /**
     * Class to demonstrate a mask needs to be added to stage
     * in order to function properly and scale up along with the rest
     * when stuff goes fullscreen
     *
     */
    public class AddedMask extends Sprite
    {
        // the mask
        private var m:Sprite;
       
        /**
         * build some interface and animation to make clear what is going on
         *
         */
        public function AddedMask()
        {
            stage.scaleMode = StageScaleMode.SHOW_ALL;
            stage.align = StageAlign.TOP_LEFT;
           
            drawText();
           
            var fsButton = new FSButton();
            addChild( fsButton );
           
            drawBackground()
           
            drawMask();
        }
       
        /**
         * Funciton which draws the mask (in this case across the whole stage)
         *
         * More or less what it's all about
         */
        private function drawMask():void
        {
            // the mask
            m = new Sprite();
            m.graphics.beginFill( 0x000000 );
            m.graphics.drawRect( 0, 0, stage.stageWidth, stage.stageHeight );
            m.graphics.endFill();
           
            // make sure the mask is added to the display list...
            addChild( m );
           
            mask = m;
        }
       
        /**
         * function to fill the background
         *
         */
        private function drawBackground():void
        {
            var matr:Matrix = new Matrix();
            matr.createGradientBox(50, 50, 0, 0, 0);
            var spreadMethod:String = SpreadMethod.REFLECT;
            graphics.beginGradientFill( GradientType.LINEAR, [ 0x666666, 0xCCCCCC ], [1, 1], [ 0x00, 0xFF ], matr, spreadMethod );
            graphics.drawRect( 0, 0, stage.stageWidth, stage.stageHeight );
            graphics.endFill();
        }
       
        /**
         * some text
         *
         */
        private function drawText():void
        {
            var tf:TextField = new TextField();
            var tfm:TextFormat = new TextFormat( null, 24, 0, true, false, false, null, null, TextFormatAlign.CENTER );
            tf.autoSize = TextFieldAutoSize.CENTER;
            tf.defaultTextFormat = tfm;
            tf.text = "See if you can still read this \n after going FullScreen";
            tf.x = (stage.stageWidth - tf.width) / 2;
            tf.y = (stage.stageHeight - tf.height) / 2;
            addChild( tf );
        }
    }
}

import flash.display.Sprite;
import flash.events.MouseEvent;
import flash.display.StageDisplayState;
import flash.text.TextField;
import flash.text.TextFieldAutoSize;
import flash.text.TextFormat;
import flash.text.TextFormatAlign;

class FSButton extends Sprite
{
    function FSButton():void
    {
        graphics.beginFill( 0x6666FF );
        graphics.drawRect( 0, 0, 50, 50 );
        graphics.endFill();
       
        // some text
        var tf:TextField = new TextField();
        var tfm:TextFormat = new TextFormat( null, 12, 0, true, false, false, null, null, TextFormatAlign.CENTER );
        tf.defaultTextFormat = tfm;
        tf.autoSize = TextFieldAutoSize.LEFT;
        tf.text = "Press\nme";
        tf.x = (width - tf.width) / 2;
        tf.y = (height - tf.height) / 2;
        tf.selectable = false;
        tf.mouseEnabled = false;
        addChild( tf );
       
        buttonMode = true;
        addEventListener( MouseEvent.CLICK, fs );
    }
   
    private function fs( event:MouseEvent ):void
    {
        if ( stage.displayState != StageDisplayState.FULL_SCREEN )
            stage.displayState = StageDisplayState.FULL_SCREEN;
        else
            stage.displayState = StageDisplayState.NORMAL;
    }
}
Blog — Comments Off
10
Mar 11

FITC, day two

The second day of FITC Amsterdam was another day full of great presentations. This is what I saw (and remembered).

Paul Trani

He showed optimization tips in the Flash IDE. Tips however were more general than that. First thing he mentioned was the huge PPI differences across devices. Ranging from 120 to 300something (a huge difference). Scaling interface elements based on Capabilities.screenDPI is one of the solutions for it: setting an object’s width to the Capabilities.screenDPI makes it one inch wide. Build your own little app that reads the capabilities of a device before you start developing for it. This brings back memories of “best viewed in …” days where cross browser development was not as easy as nowadays, however, Adobe seems to do a good job with the next releases in accommodating for all the different devices. The multi screen development as they call it. It remains a wild, wild world out there however. The examples Paul showed had timeline code (for which he apologized ;) ) but had a nice way of sort of seperating the model and view. His example shooter ran with just one document class for all devices and decive specific code in the document itself.

To save some of the precious screen real estate, you need to make sure you know the capabilities of the device and what the general user expects to use to navigate. You can get rid of a lot of the buttons and let gestures be used for navigation, so like Stacy said yesterday, think really well about what you’re designing for.

Furtermore there were tips on all kinds of performance thingies:

  • bitmaps instead of vecors
  • blitting for faster drawing (see SWFSheet from Bit 101 or Zoë by Grant Skinner to aid creating spritesheets)
  • use cacheAsBitmap for elements only moving (x and y axis only)
  • use cacheAsBitmapMatrix for elements rotating and scaling etc
  • move displayobjects over whole pixels, not subpixels
  • use Graphics over Sprite over MovieClips if you can to preserve memory
  • remember to remove (unloadandstop of removechild) ojects when not needed anymore
  • take redraw regions into account ()
  • Use object pooling

This it can be found too on Thibault’s blog and other places. So much reading to do… :)

Next to a Space Invaders type of demo he showed, a nice piece of eyecandy shown was Flash Silk (I think only available for Android devices).

Deepa Subramaniam & Andrew Shorten

Paul’s presentation more or less seamlessly went over into the one of Deepa & Andrew talking about the new stuff in Flex 4.5 and Flash Builder 4.5 of which a tiny glimps was already given at the keynote of day one. Here we got the full story. Deepa showed the new templates based on navigation paradigms present on devices, the new versions of the Spark components retrofitted for mobile with separate skins for Android and iOS and the debugging while testing on the device trough either USB or WiFi. The SDK is also improved at several points, more Spark components replacing Halo components (datagrid, form, image, busycursor) as well as local aware formatters, improved modularization to accommodate or speed up development of big ass projects.

Andrew showed some of the new coding features which let it compete with FDT (which already has those features AFAIK). Al kinds of code assist among which code assist for meta tags, even for frameworks like Robotlegs (if they provide the proper XML file). There was a real short part on Catalyst, but to be honest I never used it, so the “NEW!” remarks did not make much sense to me. I understood the “better streamlined, also for use by developers”, but that was about it, sorry.

Alyoka & Jooony Emergence + reflection = emerection

No, not the reflection in a fancy black mirror… The first part done by Alyoka who started with a introduction to the ever mesmerizing Game of Life from John Conway. Next she showed a nifty implementation of some of Wolfram’s rules applied to a combination of byteArrays and bitmapdata (does not seem to be on their blog) to demonstrate the principles behind emersion. The presentation went on to give an introduction into the technical possibilities ActionScript has to help with reflection / introspection like describeType(). Jooony took over with  something that ended in peak & poke for ActionScript. Due to the lack of time and some hard to read sheets the story did not come across as it should have, but the punchline was that he read the bytes of a SWF file and found a way to more or less decompile it. With all the info gathered he was able to alter classes at runtime. Pretty impressive and true emersion but sometimes hard to follow. I wonder what will come out of his experiments.

Richard Jewson & Oskar Sundberg

“Speech” did not really have anything to do with it as the title of the presentation suggested, it was a transcription error from email to program booklet. The presentation was about procedural content and generative art.

Both work at Blastradius. A very brief overview of generative art was given, Islamic art with it’s complicated mathematical rulesets, Mozart’s algorithmic composition with dice and a deck of card to some computer facilitated generative art. Today we can use similar algorithms from long ago to do more with it aided by the computing power of modern times.

Then the procedural content creation of Elite and Exile (Both BBC Acorn, I’m old enough to have seen some working remains of those) was discussed. In Elite the galaxies were generated by algorithms and in Exile the game map. With the use of the proper input for an algorithm (randomseed for instance) you’ll be able to generate the same ‘random’ map over and over so you don’t need to manually define it in the game. It may take a while though before you end up with an acceptable random map.

If those techniques back in the days may have been used to safe memory, nowadays with an abundance of memory, the algorithms can be used to save time (otherwise needed for manual asset creation).

A presentation was given of a Nivea project their company did(for the life of me I can’t find it online…). Users could create a leaf on a tree as sort of a crowdsourced artwork. The tree was created with an variation of an L-System with some wind and dynamics that respond to mouse movements added to it. Added to that were very dynamic brushes inspired by the ingredients of the product.

Finally there were some examples on the more playful side:

The introduction of a project in the making of them selves called Binory.com topped it off. For this project they still need input in the form of people that can provide algorithms that create content that people then can order on print. There’s a buck in there for the algorithm owner. Mail:  hellobinory [ a t ] gmail  [ full stop ] com.

Bartek Drozdz

3D workflow for the New Era

Bartek talked about his history in 3D development in Flash and Unity. From his first project in Flash with Papervision to a Unity project with an 80+ inch touchscreen in a 6 company project and the changes his roll as a developer went through. His first project he did everything himself and build the skateboard model from scratch in code, later on he build his own assets in Blender and now he has to let modelers do the modeling since 3D project have become to complex to do on you own. The capabilities have increased so much over the last few years that each part of the project has too much of it’s own expertise that one person can do it alone. He had a nice overview of the work areas involved in 3D application development:

Low level stuff

(what most people will never touch or see) WebGL, OpenGL ES, Molehill

Engines most developers work with

JS engines (Three.js), Unity (C#, js, as3), AS3 engines (Away3D)

Workflow tools

This is the glue between assetcreators and coders ( python, maxscript, unity editor api )

The art / design tools

3D editors (Maya, Blender etc), Gamelevel editors (Unity)

Data input

Generative art, physical input motion data etc.

At the moment Bartek is impressed with Unity, easy in use and coding (C# is a lot like AS3), the API is easy to learn and the coding done only has to deal with game logic.

The case study, done in Unity, he showed was a project that runs at a Swedish airport and is called Woodbot pilots. Quite an impressive project done with 6 different companies and Bartek himself. It involves a portrait positioned touchscreen with a 3D camera (no, no kinetic) above it to capture the movement of the player which is translated to the direction the bot is steered through a rocky landscape, check out the video on his website.

The things he learned from this whole project were (among others):

  • Concept art is not to be used in the final product (even if it is 3D concept art). Maybe that was why a lot of concept art is done drawing on paper (although the concept art for Woodbot pilot was beautifull)
  • Make prototypes to test concepts and the gameplay. You cannot think it all through, you must experience.
  • Talk (a lot) with 3D artists, there is so much that can go wrong and could use extra attention that the artist cannot work out on it’s own. Things to take into consideration are: polycount low where needed, higher where possible, textures & shaders work different in model software and the engine of choice, structure of models (pivots, groups etc) require attention, procedural content could be easier to use, depending on useage and engine.
  • Automate the asset pipeline: use editor script wisely to, for instance, inspect models. (After having spent numerous hours inspecting models, Bartek decided to write scripts to do it for him, time investment but in the end saves time and frustration)
  • Build levels in game editor, seperate the phase of modeling from level design because then you’ll know what it looks like exactly as well as that you’llbe able to use features specific to the engine which the modeling software does not have.

The conclusion however was that there is no ideal workflow across technologies / tools, just rules of thumb…

Evan Roth

He was last but certainly not least. You really need to look up his work (as advised, a google search for “bad ass motherfucker” will do just fine). His story was about empowerment, open source and open data. This single sentence does not do his work any justice. And since most of it is visual, check out the website. His work can be seen as aesthetic but with substance as his lollypop infographic explained. Sometimes it can be seen as pure aesthetic, sometimes a bit juvenile mischievous, sometimes pretty ‘pofessional’ and sometimes with unexpected backgrounds but always good. Something to think about on the train ride home without any more battery life left :)

It ware three very nice days with loads of info. Although it costs some, it is definitely worth it. Hope to be able to again go next year!

← Older Entries
Newer Entries →