Designing a sprite class in haXe/flash

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Designing a sprite class in haXe/flash

Nathan Huesken
Hi,

Looking around how people do animations in haXe/flash, it seems a
common practice is to hardcode them.

I do not really like that approach, I prefer a more data driven
approach.

In C++ I would write a sprite class, which defines a set of images and
animations (series of images) that can be loaded from an XML file. It
than supports a "setAnimation(name)" and "update(time)" function.

I am new to haXe and flash, and the way things are done in haXe/flash
are new to me. So I am wondering if people could give some insights on
how to do it in haXe/flash (or even point me to an implementation i
missed googling).

So, would you derive the class from Bitmap and set BitmapData whenever
the current image changes? Or would you derive it from Sprite and add
the current image as the child?

Then I am thinking, it is possible to define an animated object in an
extern swf file (even create it with the flash IDE), is it not?
Then the class should also support loading a swf file and provide the
same interface as if a XML was loaded, but I have no Idea how one would
do that.

Any thoughts and insights are extremely welcome :).

Thanks!
Nathan

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Designing a sprite class in haXe/flash

James W. Hofmann
Nathan Huesken wrote
Hi,

Looking around how people do animations in haXe/flash, it seems a
common practice is to hardcode them.

I do not really like that approach, I prefer a more data driven
approach.
Making any data-driven approach work is a slippery problem. The Flash APIs are already designed to be a domain-level solution for graphics and animation, so anything you add on top will have to improve iteration times or portability to be a gain over hard-coded behavior, and that usually means doing something very focused and narrow(thus non-reusable). I've done a lot of work on the pipeline/import stage, which I'll describe below.

Nathan Huesken wrote
In C++ I would write a sprite class, which defines a set of images and
animations (series of images) that can be loaded from an XML file. It
than supports a "setAnimation(name)" and "update(time)" function.

I am new to haXe and flash, and the way things are done in haXe/flash
are new to me. So I am wondering if people could give some insights on
how to do it in haXe/flash (or even point me to an implementation i
missed googling).

So, would you derive the class from Bitmap and set BitmapData whenever
the current image changes? Or would you derive it from Sprite and add
the current image as the child?

Then I am thinking, it is possible to define an animated object in an
extern swf file (even create it with the flash IDE), is it not?
Then the class should also support loading a swf file and provide the
same interface as if a XML was loaded, but I have no Idea how one would
do that.
First you will have to decide how your art pipeline is going to work, and whether you're distributing a single swf or a multi-load. If you want vector assets, you can build in Flash IDE, export individual swfs, and then combine them into a library with swfmill or SamHaXe. If you want bitmaps, you can start from PNG spritesheets and slice them up at runtime. That gets you a collection of images. But then you have to consider how you want to animate at runtime. You can attach them to the stage, attach outside the stage and draw() later, draw() to a Bitmap and copyPixels(), etc. There are tradeoffs to each of these in how much you're letting Flash do for you vs. how much you can optimize later.

Let me describe the system for my "Fireball" engine. It has fast, pre-transformed bitmap sprites that use only copyPixels at runtime, like those in Flixel. This is probably most similar to how you would envision it in C++, in fact:

1. Transformation functions are defined that assign ms timings and calculate different scaling, rotation, alpha, etc.

2. A sprite with indexed values is composed from these transformation functions - a nested list structure which requires the user to have implicit knowledge of the order and type of transformations. For example, if I have a sprite with 1000 ms of animation, an optional horizontal mirroring, and 10 levels of scaling, I do a lookup by passing in a list of three floating point values, one for each of the parameters. Thus, it's no trouble for me to cache my transformations upfront - a major problem of the native Flash API.

3. I define animations more conveniently in a JSON data format, which detects my use of the various parameters, sets up the transformations for me, and enforces a conventional ordering of the various transformation types. This format is supposed to be "good enough" for most uses. It's not perfect by any means, but in my test cases it seems to have worked pretty well.

4. I defer actual rendering calls until the end of a frame, so that sprite draw order is not tangled with other aspects of entity updates.

You can see this implementation here:

http://bitbucket.org/triplefox/fireball/src/tip/fireball/gfx/sprite/

and an example of the anim data format:

http://bitbucket.org/triplefox/fireball/src/tip/nina/src/data/sprites.kfj

Some things that I haven't done yet: I haven't done anything for packed spritesheets(the goal of the currently unused Atlas and AtlasFrame classes), I haven't really fleshed out the usage of hotpoints or pivots, I don't have a way to define anims of multiple sprites(skeleton or particle stuff), and I've done nothing for timeline-based scripting and tweening, a feature of Flash IDE that would be desirable to reproduce in a more portable way.

Also, note that the whole point of Fireball is to have an engine capable of runtime asset iteration, so I have a huge infrastructure built up around that, which the anim code is layered on. All the stuff with asset embedding is a non-issue, just drop files in /src/data and they appear as a Hash key, so long as the extension is recognized. I haven't written a lot about Fireball on this list, but maybe I should. It's getting good enough to be really useful, I just haven't done much to document it yet. (I'm going to go through the bug tracker this evening and update it, I put a lot of notes and musings in there.)
Reply | Threaded
Open this post in threaded view
|

Re: Designing a sprite class in haXe/flash

Tony Polinelli

Flash is the most common way to produce animations for the swf format. If you havent played with it much, i'd definately look at that first. You can export an asset as a class, and then access it at runtime, either by assigning a class of the same name (and package) - if you use the -swf-lib, or by finding the class in its loader domain (getDefinition) and instantiating it, if it is in the same domain, then use Type.createInstance. 

once you have the animation, you can choose to keep it as vector (if that is what it is), or cache its frames to bitmaps. If you precache all of the frames then things will run faster. 

This is one approach, another would be to load in spritesheets. I have found that having a Bitmap object, and switching its bitmapData each frame is very fast, no slower than copypixels. Here's a link link (again.. i know...) to a test http://blog.touchmypixel.com/2008/11/caching-animation-frames-vs-spritesheets/ - it is in as3, but we have a haxe version on the tmp googlecode, i'm not sure if it works tho - just an example, i'm sure you can use these techniques to become less 'hardcoded' too - but you might want to experiment with the basics if you havent already first. 




On Tue, Jun 29, 2010 at 3:08 PM, James W. Hofmann <[hidden email]> wrote:


Nathan Huesken wrote:
>
> Hi,
>
> Looking around how people do animations in haXe/flash, it seems a
> common practice is to hardcode them.
>
> I do not really like that approach, I prefer a more data driven
> approach.
>

Making any data-driven approach work is a slippery problem. The Flash APIs
are already designed to be a domain-level solution for graphics and
animation, so anything you add on top will have to improve iteration times
or portability to be a gain over hard-coded behavior, and that usually means
doing something very focused and narrow(thus non-reusable). I've done a lot
of work on the pipeline/import stage, which I'll describe below.


Nathan Huesken wrote:
>
> In C++ I would write a sprite class, which defines a set of images and
> animations (series of images) that can be loaded from an XML file. It
> than supports a "setAnimation(name)" and "update(time)" function.
>
> I am new to haXe and flash, and the way things are done in haXe/flash
> are new to me. So I am wondering if people could give some insights on
> how to do it in haXe/flash (or even point me to an implementation i
> missed googling).
>
> So, would you derive the class from Bitmap and set BitmapData whenever
> the current image changes? Or would you derive it from Sprite and add
> the current image as the child?
>
> Then I am thinking, it is possible to define an animated object in an
> extern swf file (even create it with the flash IDE), is it not?
> Then the class should also support loading a swf file and provide the
> same interface as if a XML was loaded, but I have no Idea how one would
> do that.
>

First you will have to decide how your art pipeline is going to work, and
whether you're distributing a single swf or a multi-load. If you want vector
assets, you can build in Flash IDE, export individual swfs, and then combine
them into a library with swfmill or SamHaXe. If you want bitmaps, you can
start from PNG spritesheets and slice them up at runtime. That gets you a
collection of images. But then you have to consider how you want to animate
at runtime. You can attach them to the stage, attach outside the stage and
draw() later, draw() to a Bitmap and copyPixels(), etc. There are tradeoffs
to each of these in how much you're letting Flash do for you vs. how much
you can optimize later.

Let me describe the system for my "Fireball" engine. It has fast,
pre-transformed bitmap sprites that use only copyPixels at runtime, like
those in Flixel. This is probably most similar to how you would envision it
in C++, in fact:

1. Transformation functions are defined that assign ms timings and calculate
different scaling, rotation, alpha, etc.

2. A sprite with indexed values is composed from these transformation
functions - a nested list structure which requires the user to have implicit
knowledge of the order and type of transformations. For example, if I have a
sprite with 1000 ms of animation, an optional horizontal mirroring, and 10
levels of scaling, I do a lookup by passing in a list of three floating
point values, one for each of the parameters. Thus, it's no trouble for me
to cache my transformations upfront - a major problem of the native Flash
API.

3. I define animations more conveniently in a JSON data format, which
detects my use of the various parameters, sets up the transformations for
me, and enforces a conventional ordering of the various transformation
types. This format is supposed to be "good enough" for most uses. It's not
perfect by any means, but in my test cases it seems to have worked pretty
well.

4. I defer actual rendering calls until the end of a frame, so that sprite
draw order is not tangled with other aspects of entity updates.

You can see this implementation here:

http://bitbucket.org/triplefox/fireball/src/tip/fireball/gfx/sprite/

and an example of the anim data format:

http://bitbucket.org/triplefox/fireball/src/tip/nina/src/data/sprites.kfj

Some things that I haven't done yet: I haven't done anything for packed
spritesheets(the goal of the currently unused Atlas and AtlasFrame classes),
I haven't really fleshed out the usage of hotpoints or pivots, I don't have
a way to define anims of multiple sprites(skeleton or particle stuff), and
I've done nothing for timeline-based scripting and tweening, a feature of
Flash IDE that would be desirable to reproduce in a more portable way.

Also, note that the whole point of Fireball is to have an engine capable of
runtime asset iteration, so I have a huge infrastructure built up around
that, which the anim code is layered on. All the stuff with asset embedding
is a non-issue, just drop files in /src/data and they appear as a Hash key,
so long as the extension is recognized. I haven't written a lot about
Fireball on this list, but maybe I should. It's getting good enough to be
really useful, I just haven't done much to document it yet. (I'm going to go
through the bug tracker this evening and update it, I put a lot of notes and
musings in there.)
--
View this message in context: http://haxe.1354130.n2.nabble.com/Designing-a-sprite-class-in-haXe-flash-tp5233469p5233724.html
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Designing a sprite class in haXe/flash

jlm@justinfront.net
If your on a budget swishmax is quite powerful but flash is really nice tool, but if your just doing a linear animation, you may find exporting a flv from aftereffects or similar may give you some powerful results.  Video is a hassle to work with but it does optimize storing keyframes and differences for the frames between so it is smaller than just an array of png's that will take time to process to bitmapData's, and video can be streamed.

if you are finding flash vectors heavy then you can store movieclip frames as bitmaps so you can later play them fast, but as I said this can be slow to create here is a snipit... sorry some details in the form of other classes are missing and I can't rem which version of the class is good, so I have posted the second but it may have bugs and may not be good code, I am using a visible switch technique which is probably fairly fast once the structure is created, but I rely on loading a flash asset movie to my code which I grab from SimpleView via it's linkage name.

package zpartan.generic.views;

import zpartan.generic.views.SimpleView;
import flash.display.Sprite;
import flash.display.MovieClip;
import flash.geom.Rectangle;
import flash.geom.Point;
import flash.events.Event;
import flash.display.Bitmap;
import flash.display.BitmapData;


// hsl signal classes
import hsl.haxe.Signaler;
import hsl.haxe.direct.DirectSignaler;



class CacheTimelineClipView2
{
    
    
    private var _scope:             Sprite;
    private var _nom:               String;
    private var _view:              SimpleView;
    private var _mc:                MovieClip;
    private var _mcPreCache:        MovieClip;
    private var _listCacheClips:    List<Sprite>;
    private var _currCacheClip:     Sprite;
    private var _cacheItter:        Iterator<Sprite>;
    private var _firstTime:         Bool;
    private var _toggle:            Bool;
    private var _frame:             Int;
    
    public var cachedSignaler(      default, null):     Signaler<Void>;
    
    public function new( scope_: Sprite, nom_: String )
    {
        
        _scope              = scope_;
        _nom                = nom_;
        cachedSignaler      = new DirectSignaler( this, false );
        
        init();
        
    }
    
    
    private function init()
    {
        
        _toggle                     = false;
        _firstTime                  = true;
        _view                       = new SimpleView( _scope );
        _mc                         = _view.addMovieClip( _nom );
        _mc.gotoAndStop( _mc.totalFrames );
        _mc.visible                 = false;
        
        _listCacheClips             = new List();
        _mcPreCache                 = new MovieClip();
        _mcPreCache.x               = _mc.x;
        _mcPreCache.y               = _mc.y + 20;
        //_mcPreCache.alpha           = 0.2;
        _frame                      = 1;
    }
    
    
    public function startCaching()
    {
        
        //_bgPreCache.cacheAsBitmap   = true;
        //_mc.play();
        _mc.gotoAndStop(1);
        _mc.addEventListener( Event.ENTER_FRAME, cacheFrames );
        
    }
    
    
    private function cacheFrames( e: Event )
    {
        
        var cacheSprite: Sprite;
        trace( _mc.currentFrame );
        if( _mc.currentFrame == 1 && _firstTime == false )
        {
            
            _mc.removeEventListener( Event.ENTER_FRAME, cacheFrames );
            _currCacheClip = _listCacheClips.first();
            switchBgToCache();
            cachedSignaler.dispatch();
            
        }
        else
        {
            
            _firstTime                  = false;
            cacheSprite                 = new Sprite();
            if( _mc.currentFrame == 1 )
            {
                
                _scope.addChildAt( _mcPreCache, 1 );
                
            }
            else
            {
                
                cacheSprite.visible     = false;
                
            }
            
            cacheSprite.addChild( new Bitmap( copyToBitmap( _mc ) ) );
            _listCacheClips.add( cacheSprite );
            _mcPreCache.addChild( cacheSprite );
            
            _frame++;
            trace( _frame );
            if( _frame > _mc.totalFrames ){ _frame = 1; }
            _mc.gotoAndStop( _frame );
            
            
        }
        
    }
    
    
    private function switchBgToCache()
    {
        
        _scope.removeChild( _mc );
        
        _mc                     = null;
        _currCacheClip.visible  = false;
        _cacheItter             = _listCacheClips.iterator();
        _currCacheClip          = _cacheItter.next();
        _currCacheClip.visible  = true;
        
        _mcPreCache.addEventListener( Event.ENTER_FRAME, loopCacheFrames );
        
    }
    
    
    private function loopCacheFrames( e: Event )
    {
        if( _toggle == true )
        {
            _currCacheClip.visible  = false;
        
            if( _cacheItter.hasNext() == false )
            {
                _cacheItter         = _listCacheClips.iterator();
            }
        
            _currCacheClip          = _cacheItter.next();
            _currCacheClip.visible  = true;
            
        }
        _toggle = !_toggle;
        
    }
    
    
    public function copyToBitmap( mc: MovieClip ): BitmapData
    {
        
        mc.cacheAsBitmap                = true;
       
        var wide:       Int             = Std.int( mc.width );
        var hi:         Int             = Std.int( mc.height );
        var point:      Point           = new Point( 0, 0);
        var rect:       Rectangle       = new Rectangle( 0 , 0, wide, hi);
        var abitmap:    BitmapData      = new BitmapData( wide, hi, false, 0x000000 );
        abitmap.draw( mc );
        abitmap.copyPixels( abitmap, rect, point, abitmap, point, false );
        
        return abitmap;
        
    }
    
    
}

On 29 Jun 2010, at 06:31, Tony Polinelli wrote:


Flash is the most common way to produce animations for the swf format. If you havent played with it much, i'd definately look at that first. You can export an asset as a class, and then access it at runtime, either by assigning a class of the same name (and package) - if you use the -swf-lib, or by finding the class in its loader domain (getDefinition) and instantiating it, if it is in the same domain, then use Type.createInstance. 

once you have the animation, you can choose to keep it as vector (if that is what it is), or cache its frames to bitmaps. If you precache all of the frames then things will run faster. 

This is one approach, another would be to load in spritesheets. I have found that having a Bitmap object, and switching its bitmapData each frame is very fast, no slower than copypixels. Here's a link link (again.. i know...) to a test http://blog.touchmypixel.com/2008/11/caching-animation-frames-vs-spritesheets/ - it is in as3, but we have a haxe version on the tmp googlecode, i'm not sure if it works tho - just an example, i'm sure you can use these techniques to become less 'hardcoded' too - but you might want to experiment with the basics if you havent already first. 




On Tue, Jun 29, 2010 at 3:08 PM, James W. Hofmann <[hidden email]> wrote:


Nathan Huesken wrote:
>
> Hi,
>
> Looking around how people do animations in haXe/flash, it seems a
> common practice is to hardcode them.
>
> I do not really like that approach, I prefer a more data driven
> approach.
>

Making any data-driven approach work is a slippery problem. The Flash APIs
are already designed to be a domain-level solution for graphics and
animation, so anything you add on top will have to improve iteration times
or portability to be a gain over hard-coded behavior, and that usually means
doing something very focused and narrow(thus non-reusable). I've done a lot
of work on the pipeline/import stage, which I'll describe below.


Nathan Huesken wrote:
>
> In C++ I would write a sprite class, which defines a set of images and
> animations (series of images) that can be loaded from an XML file. It
> than supports a "setAnimation(name)" and "update(time)" function.
>
> I am new to haXe and flash, and the way things are done in haXe/flash
> are new to me. So I am wondering if people could give some insights on
> how to do it in haXe/flash (or even point me to an implementation i
> missed googling).
>
> So, would you derive the class from Bitmap and set BitmapData whenever
> the current image changes? Or would you derive it from Sprite and add
> the current image as the child?
>
> Then I am thinking, it is possible to define an animated object in an
> extern swf file (even create it with the flash IDE), is it not?
> Then the class should also support loading a swf file and provide the
> same interface as if a XML was loaded, but I have no Idea how one would
> do that.
>

First you will have to decide how your art pipeline is going to work, and
whether you're distributing a single swf or a multi-load. If you want vector
assets, you can build in Flash IDE, export individual swfs, and then combine
them into a library with swfmill or SamHaXe. If you want bitmaps, you can
start from PNG spritesheets and slice them up at runtime. That gets you a
collection of images. But then you have to consider how you want to animate
at runtime. You can attach them to the stage, attach outside the stage and
draw() later, draw() to a Bitmap and copyPixels(), etc. There are tradeoffs
to each of these in how much you're letting Flash do for you vs. how much
you can optimize later.

Let me describe the system for my "Fireball" engine. It has fast,
pre-transformed bitmap sprites that use only copyPixels at runtime, like
those in Flixel. This is probably most similar to how you would envision it
in C++, in fact:

1. Transformation functions are defined that assign ms timings and calculate
different scaling, rotation, alpha, etc.

2. A sprite with indexed values is composed from these transformation
functions - a nested list structure which requires the user to have implicit
knowledge of the order and type of transformations. For example, if I have a
sprite with 1000 ms of animation, an optional horizontal mirroring, and 10
levels of scaling, I do a lookup by passing in a list of three floating
point values, one for each of the parameters. Thus, it's no trouble for me
to cache my transformations upfront - a major problem of the native Flash
API.

3. I define animations more conveniently in a JSON data format, which
detects my use of the various parameters, sets up the transformations for
me, and enforces a conventional ordering of the various transformation
types. This format is supposed to be "good enough" for most uses. It's not
perfect by any means, but in my test cases it seems to have worked pretty
well.

4. I defer actual rendering calls until the end of a frame, so that sprite
draw order is not tangled with other aspects of entity updates.

You can see this implementation here:

http://bitbucket.org/triplefox/fireball/src/tip/fireball/gfx/sprite/

and an example of the anim data format:

http://bitbucket.org/triplefox/fireball/src/tip/nina/src/data/sprites.kfj

Some things that I haven't done yet: I haven't done anything for packed
spritesheets(the goal of the currently unused Atlas and AtlasFrame classes),
I haven't really fleshed out the usage of hotpoints or pivots, I don't have
a way to define anims of multiple sprites(skeleton or particle stuff), and
I've done nothing for timeline-based scripting and tweening, a feature of
Flash IDE that would be desirable to reproduce in a more portable way.

Also, note that the whole point of Fireball is to have an engine capable of
runtime asset iteration, so I have a huge infrastructure built up around
that, which the anim code is layered on. All the stuff with asset embedding
is a non-issue, just drop files in /src/data and they appear as a Hash key,
so long as the extension is recognized. I haven't written a lot about
Fireball on this list, but maybe I should. It's getting good enough to be
really useful, I just haven't done much to document it yet. (I'm going to go
through the bug tracker this evening and update it, I put a lot of notes and
musings in there.)
--
View this message in context: http://haxe.1354130.n2.nabble.com/Designing-a-sprite-class-in-haXe-flash-tp5233469p5233724.html
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Designing a sprite class in haXe/flash

Nathan Huesken
In reply to this post by James W. Hofmann
Hey,

Thanks for sharing:

> Making any data-driven approach work is a slippery problem. The Flash
> APIs are already designed to be a domain-level solution for graphics
> and animation, so anything you add on top will have to improve
> iteration times or portability to be a gain over hard-coded behavior,
> and that usually means doing something very focused and narrow(thus
> non-reusable).

You mean, I should be careful not to reinvent the wheel?
I have not used flash before, so I might oversee something.
I just feel a need for a common interface to animated objects, behind
which any way of animating (hardcoded animations, defined in an XML
file) can be implemented. So that when I decide in the middle of
development, that I want to change the way I (or the artist) makes the
graphics, I do not have to change my code (besides the point where the
sprites are loaded/created).
 
> First you will have to decide how your art pipeline is going to work,
> and whether you're distributing a single swf or a multi-load.

That is exactly what I do not want to decide beforehand.

> 2. A sprite with indexed values is composed from these transformation
> functions - a nested list structure which requires the user to have
> implicit knowledge of the order and type of transformations. For
> example, if I have a sprite with 1000 ms of animation, an optional
> horizontal mirroring, and 10 levels of scaling, I do a lookup by
> passing in a list of three floating point values, one for each of the
> parameters. Thus, it's no trouble for me to cache my transformations
> upfront - a major problem of the native Flash API.

I am not sure I understand what you mean. Do you pre-render the frames
knowing the parameters with which they will be shown beforehand?

> Also, note that the whole point of Fireball is to have an engine
> capable of runtime asset iteration,

Aeh, what is "runtime asset iteration"?

Fireball looks promising. Do example applications using it exit?

Thanks!
Nathan

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Designing a sprite class in haXe/flash

Niel Drummond-3
hello,

On Tue, Jun 29, 2010 at 09:43:21PM -0400, Nathan Huesken wrote:
>
> You mean, I should be careful not to reinvent the wheel?
> I have not used flash before, so I might oversee something.
> I just feel a need for a common interface to animated objects, behind
> which any way of animating (hardcoded animations, defined in an XML
> file) can be implemented. So that when I decide in the middle of
> development, that I want to change the way I (or the artist) makes the
> graphics, I do not have to change my code (besides the point where the
> sprites are loaded/created).

flash is an immediate mode rendering interface, what you describe is typically used in silverlight and other retained mode rendering interfaces. the benefits of the former is flexibility, the benefits of the latter is usually speed. Having said this, there are some libraries that implement flash layout using XML.

- Niel

>  
> > First you will have to decide how your art pipeline is going to work,
> > and whether you're distributing a single swf or a multi-load.
>
> That is exactly what I do not want to decide beforehand.
>
> > 2. A sprite with indexed values is composed from these transformation
> > functions - a nested list structure which requires the user to have
> > implicit knowledge of the order and type of transformations. For
> > example, if I have a sprite with 1000 ms of animation, an optional
> > horizontal mirroring, and 10 levels of scaling, I do a lookup by
> > passing in a list of three floating point values, one for each of the
> > parameters. Thus, it's no trouble for me to cache my transformations
> > upfront - a major problem of the native Flash API.
>
> I am not sure I understand what you mean. Do you pre-render the frames
> knowing the parameters with which they will be shown beforehand?
>
> > Also, note that the whole point of Fireball is to have an engine
> > capable of runtime asset iteration,
>
> Aeh, what is "runtime asset iteration"?
>
> Fireball looks promising. Do example applications using it exit?
>
> Thanks!
> Nathan
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Designing a sprite class in haXe/flash

James W. Hofmann
In reply to this post by Nathan Huesken
Nathan Huesken wrote
Hey,

Thanks for sharing:

> Making any data-driven approach work is a slippery problem. The Flash
> APIs are already designed to be a domain-level solution for graphics
> and animation, so anything you add on top will have to improve
> iteration times or portability to be a gain over hard-coded behavior,
> and that usually means doing something very focused and narrow(thus
> non-reusable).

You mean, I should be careful not to reinvent the wheel?
I have not used flash before, so I might oversee something.
I just feel a need for a common interface to animated objects, behind
which any way of animating (hardcoded animations, defined in an XML
file) can be implemented. So that when I decide in the middle of
development, that I want to change the way I (or the artist) makes the
graphics, I do not have to change my code (besides the point where the
sprites are loaded/created).
No, this is not what I meant. This is the problem I'm bringing up: that your solution may not solve anything if it's underspecified(which seems to be what you are preferring). The possible approaches for art integration tasks are numerous; if the amount of configuration required is more than the time it takes to hardcode and recompile, you've failed to make any gains. And if the way the art is made changes mid-project, that's a catastrophic failure of project management, and it is not supposed to be resolved with technology. That is why I say "decide what the art pipeline is, and decide how the data gets loaded." Within the scope of one project you can't expect to have all the answers, but you will learn what is absolutely necessary. Therefore, you have the highest chance of success to start with the simple things and work up from there, testing your guesses with actual integration efforts (rather than trying to code to cover fantasy situations).

If you were intending something simple anyway, my apologies for being abrupt :)

Nathan Huesken wrote
 
> 2. A sprite with indexed values is composed from these transformation
> functions - a nested list structure which requires the user to have
> implicit knowledge of the order and type of transformations. For
> example, if I have a sprite with 1000 ms of animation, an optional
> horizontal mirroring, and 10 levels of scaling, I do a lookup by
> passing in a list of three floating point values, one for each of the
> parameters. Thus, it's no trouble for me to cache my transformations
> upfront - a major problem of the native Flash API.

I am not sure I understand what you mean. Do you pre-render the frames
knowing the parameters with which they will be shown beforehand?
Yes, that is what the configuration data lets me do. Knowing the frames I want to use turns it into a simple lookup. Previously I loaded only the raw images and transformed it in code when the need arised. It can make the code messy very quickly.

Nathan Huesken wrote
 
> Also, note that the whole point of Fireball is to have an engine
> capable of runtime asset iteration,

Aeh, what is "runtime asset iteration"?

Fireball looks promising. Do example applications using it exit?

Thanks!
Nathan
"Runtime asset iteration," at least the way I implemented it, means that while the game runs, it polls a local development server running in the background and downloads new data, which - depending on how you've integrated it - can cause changes to the game's assets immediately, after resets, or after reloading the page. I also let the server recompile the game when I save changed source files(this might be a matter of taste). In practice I've used this to change level layouts, tune physics parameters, and make small tweaks to art. When the game is put up for release, the development server is discarded and all assets are packed into a single swf with a preloader attached - this is a built-in feature of the framework. The productivity gains are huge, albeit there is still tons of work to be done on the engine proper, which is why I've held off on showing it.

The projects I have done so far with it are included as demos in the current source:

A short puzzle game for the last Ludum Dare 48 hour jam: http://dl.dropbox.com/u/254701/ld17/after/index.html
This was a proof-of-concept that the basic development model worked. I got the game done within the time limit, even while implementing a lot of engine stuff(tile drawing, point-based actor collision, pathfinding). Later I went back and wrote the menu code, which I don't really like but am still reusing.

An unfinished remake of "Action 52 Ninja Assault": http://dl.dropbox.com/u/254701/blog/action52/6_last/index.html
I started working on this for a project on TIGForums to remake all 52 games in the NES "Action 52" cartridge. It grew too ambitious, but along the way I got my sprite pipeline working and did a unique fake-3D collision for beat-em-up projects like this.

I am now working on an untitled commercial project with this framework. It integrates Box2D - and on that subject, I might as well mention something pertinent to the list - for this project I tested Box2D, Nape and Physaxe. You can see in this demo:
http://dl.dropbox.com/u/254701/physcomparison/index.html

Click to fire and press X to cycle through the different engines. I ultimately chose Box2D as it seemed to get the most stable results when I gave it extreme tunings. Nape was a non-starter when I saw balls float through the walls. Physaxe was promising but it has an odd "sliding" behavior.

As I keep going with this current project the engine might change dramatically again - some cool technology hopefully coming soon :)