Re: RE: A couple of newb questions (gershon)

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

Re: RE: A couple of newb questions (gershon)

Richard Stranberg
Hi Gershon,

I agree with you 100% -  games should be as much fun to play as they are to
write!

When I think of Sprites, I think of the old Commodore 64 days, when you had
8 hardware sprites that you could program.  I just feel like after browsing
through the mail messages a lot, that there were several ways to move
graphics and sprites didn't seem to be on the top of the list.  Also, I feel
like I've read that animating sprites is difficult as well.    The
information that you and Joacim have provided is very valuable.  Again, I
don't know why there was this big disconnect in my head for not considering
the AS3 APIs.  I guess I was just thinking of Java or something where the
stuff is right there; you just have to import it.

Rick

> 2D Games have been with us for about 3 decades, so most of the things
you've
> mentioned have already been named in the "jargon"...
> "Graphically moving about", can range from "jumping" from tile to tile on
> the screen, in constant gird-sized steps, to "simple" movement
(sprite.x++),
> and complex parametric physical simulations, using floating-point values
and
> sub-pixel rendering...
>
> Sprite in the old (non-flash) sense, usually meant you'd have a so called
> "Sprite-sheet" (http://www.freewebs.com/hadouken_dude/DBZvegetassj2.gif),
> from which parts would be cropped in accordance to a specific action \
> frame, those are just bitmaps.
>
> Sprite in flash's sense (which i'm guessing is the platform we're talking
> about) is a much more generic thing, which does'nt necessarily contain
color
> bits,  but can also hold parametric curves ("Vectors" in designer's
jargon)
> and surfaces.
>
> Regarding (3), there's more than one way to go about this, the simplest
> being "Tile-Based", found in most "Side-Scrolling Platforms" (mario clones
> :)), much like you've said, usually a 2D int array is used
> (Array<Array<Int>>) where the indices specify offset from the top left,
and
> the value an offset in a sprite-sheet:
> 00000000000
> 00000000010
> 00100001110
> 22222222222
>
> Tile sized is costant, usually 2^n, 32x32, 64x64... Values can be, 0 -
Sky,
> 1 - Rock, 2 - Ground...
> The simplest form of collision detection is called "Bounding-Box Collision
> Detection", and is still used as a primary stage to minimize cpu cycles
when
> doing more complex "Pixel-Perfect Collision Detection".
>
> One last thing i'd like to mention, regards AI, "Pathfinding" is used when
> the baddie chases the player (http://lib.haxe.org/p/aPath for haxe is
> sweet), "Line-of-Sight" is when those nasties shoot at you :)
>
> Best of luck, and remember than writing the thing should be at least as
fun
> as playing it.
>
>
> On Mon, Nov 23, 2009 at 1:34 AM, Richard Stranberg
<[hidden email]
> wrote:
>>
>>
>> Thanks a lot, Joacim!  That's exactly what I was looking for.  I was over
>> at
>> Nicolas's blog yesterday looking at PhysaXe.  Pretty impressive!  I think
>> I'm starting to get the big picture in this now.  For a while I had a big
>> "disconnect" in my head.  I didn't understand why people would refer to
the
>> adobe AS3 (or whichever) API documentation; I always thought that "haXe
is

>> it's own language, where are its' APIs?"  I don't know why it took me so
>> long to understand that just like any language, you have the language
>> itself
>> that you develop in and the API's to the machine that you're working on -
>> in
>> this case Adobe's Flash engine.  I just don't do this enough...!
>>
>> Thanks again!
>>
>> Rick
>>
>>
>>
>>
>> Hi Rick,
>>
>> When you deal with graphics in flash, pretty much everything will be a
>> Sprite object, or something else derived from the DisplayObject class. Of
>> course, you could write your own graphics engine that render to a
>> BitmapData
>> instance for more specialized graphics. But in most cases using the
>> built-in
>> Sprite class will do just fine.
>>
>> If you need advanced animation, such as animating the limbs of your
>> character etc, you can do that in the flash authoring app and import the
>> swf
>> using --swf-lib in the hxml file. Then you can use the library from that
>> swf
>> like so: mcFromFlash:MovieClip =
flash.Lib.attach("NameOfObjectInLibrary");
>>
>> Moving Sprites around and doing hit testing is easy since this is also
>> built
>> in. If you only have a few moving objects, simply doing
>> "mySprite.hitTestPoint(x, y, true);" will work for pixel perfect
collision
>> detection. Then you can have all your walls and non-walk-through stuff in
a
>> single Sprite, and hit test against that sprite. Check out the
>> documentation
>> for the Sprite class:
>>
>>
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/Spri
>>
te.html<http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/disp
lay/Spri%0Ate.html>
>>
>> An other way of animating your world and achieving collision detection is
>> to
>> use a physics lib such as Box2D or PhysaXe. PhysaXe is really fast if you
>> only need collision detection. Box2D is slower, but has more features and
>> is
>> better documented. The downside of this approach is that everything in
your

>> world needs to be a polygon. Google these for more info.
>>
>> /J
>>
>> On 22 nov 2009, at 06:24, Richard Stranberg wrote:
>>
>> > Hello Everyone,
>> >
>> > I have a couple of newb questions.
>> >
>> > I'm interested in developing a 2D games in haxe that have a lot of
>> objects
>> > in them.  Most of them are stationary but some will move and be
animated.

>> I
>> > guess what I want to know is:
>> >
>> > 1)  What's the best way to move graphics around?  I've seen a lot of
>> things
>> > about sprites and even some code examples, but then I've also read that
>> it's
>> > hard to animate sprites.
>> >
>> > Also, when I move characters around the screen, there'll be a lot of
>> > stationary objects.
>> > 2)  Should these be sprties also?  Or simply bitmaps?  Or something
else?
>> >
>> > And finally, collision detection,
>> > 3)  I would like to navigate my character through a path with walls and
>> not
>> > being able to go through the walls.  Do I just make the walls separate
>> > objects, create a coarse array that will contain whether a wall object
>> > exists there or not and check the x and y coordiantes of my character
>> when
>> > it comes close to a corresponding wall object within that particular
part

>> of
>> > the array?  Or is there a better way?
>> >
>> > Thanks a lot for answering my newb questions.
>> > Rick
>> >
>> >
>> >
>> >
>> > --
>> > haXe - an open source web programming language
>> > http://haxe.org
>>
>>
>>
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>-------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
http://lists.motion-twin.com/pipermail/haxe/attachments/20091123/36e6207a/at
tachment-0001.htm

>------------------------------



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

Re: Re: RE: A couple of newb questions (gershon)

jlm@justinfront.net
Rick

Just thought it might be useful to mention, sprites don't have a  
timeline (often over looked by coders new to flash) and are not  
dynamic... that is to say traditionally flash coders sometimes use  
MovieClip's and then optimize to Sprites.  With MovieClips you can add  
variables and methods to instances directly and haXe will not type  
check, this makes them easier to prototype and easier to treat a set  
of different objects the same - if they happen to all be cast as  
MovieClips, sprites have a slightly lower overhead but for rapid  
development, MovieClips are worth using, and I often find if you are  
using both it can be simpler to just use MovieClips and only optimize  
if needed.

Cheers ;j




On 24 Nov 2009, at 02:50, Richard Stranberg wrote:

> Hi Gershon,
>
> I agree with you 100% -  games should be as much fun to play as they  
> are to
> write!
>
> When I think of Sprites, I think of the old Commodore 64 days, when  
> you had
> 8 hardware sprites that you could program.  I just feel like after  
> browsing
> through the mail messages a lot, that there were several ways to move
> graphics and sprites didn't seem to be on the top of the list.  
> Also, I feel
> like I've read that animating sprites is difficult as well.    The
> information that you and Joacim have provided is very valuable.  
> Again, I
> don't know why there was this big disconnect in my head for not  
> considering
> the AS3 APIs.  I guess I was just thinking of Java or something  
> where the
> stuff is right there; you just have to import it.
>
> Rick
>
>> 2D Games have been with us for about 3 decades, so most of the things
> you've
>> mentioned have already been named in the "jargon"...
>> "Graphically moving about", can range from "jumping" from tile to  
>> tile on
>> the screen, in constant gird-sized steps, to "simple" movement
> (sprite.x++),
>> and complex parametric physical simulations, using floating-point  
>> values
> and
>> sub-pixel rendering...
>>
>> Sprite in the old (non-flash) sense, usually meant you'd have a so  
>> called
>> "Sprite-sheet" (http://www.freewebs.com/hadouken_dude/DBZvegetassj2.gif 
>> ),
>> from which parts would be cropped in accordance to a specific  
>> action \
>> frame, those are just bitmaps.
>>
>> Sprite in flash's sense (which i'm guessing is the platform we're  
>> talking
>> about) is a much more generic thing, which does'nt necessarily  
>> contain
> color
>> bits,  but can also hold parametric curves ("Vectors" in designer's
> jargon)
>> and surfaces.
>>
>> Regarding (3), there's more than one way to go about this, the  
>> simplest
>> being "Tile-Based", found in most "Side-Scrolling Platforms" (mario  
>> clones
>> :)), much like you've said, usually a 2D int array is used
>> (Array<Array<Int>>) where the indices specify offset from the top  
>> left,
> and
>> the value an offset in a sprite-sheet:
>> 00000000000
>> 00000000010
>> 00100001110
>> 22222222222
>>
>> Tile sized is costant, usually 2^n, 32x32, 64x64... Values can be,  
>> 0 -
> Sky,
>> 1 - Rock, 2 - Ground...
>> The simplest form of collision detection is called "Bounding-Box  
>> Collision
>> Detection", and is still used as a primary stage to minimize cpu  
>> cycles
> when
>> doing more complex "Pixel-Perfect Collision Detection".
>>
>> One last thing i'd like to mention, regards AI, "Pathfinding" is  
>> used when
>> the baddie chases the player (http://lib.haxe.org/p/aPath for haxe is
>> sweet), "Line-of-Sight" is when those nasties shoot at you :)
>>
>> Best of luck, and remember than writing the thing should be at  
>> least as
> fun
>> as playing it.
>>
>>
>> On Mon, Nov 23, 2009 at 1:34 AM, Richard Stranberg
> <[hidden email]
>> wrote:
>>>
>>>
>>> Thanks a lot, Joacim!  That's exactly what I was looking for.  I  
>>> was over
>>> at
>>> Nicolas's blog yesterday looking at PhysaXe.  Pretty impressive!  
>>> I think
>>> I'm starting to get the big picture in this now.  For a while I  
>>> had a big
>>> "disconnect" in my head.  I didn't understand why people would  
>>> refer to
> the
>>> adobe AS3 (or whichever) API documentation; I always thought that  
>>> "haXe
> is
>>> it's own language, where are its' APIs?"  I don't know why it took  
>>> me so
>>> long to understand that just like any language, you have the  
>>> language
>>> itself
>>> that you develop in and the API's to the machine that you're  
>>> working on -
>>> in
>>> this case Adobe's Flash engine.  I just don't do this enough...!
>>>
>>> Thanks again!
>>>
>>> Rick
>>>
>>>
>>>
>>>
>>> Hi Rick,
>>>
>>> When you deal with graphics in flash, pretty much everything will  
>>> be a
>>> Sprite object, or something else derived from the DisplayObject  
>>> class. Of
>>> course, you could write your own graphics engine that render to a
>>> BitmapData
>>> instance for more specialized graphics. But in most cases using the
>>> built-in
>>> Sprite class will do just fine.
>>>
>>> If you need advanced animation, such as animating the limbs of your
>>> character etc, you can do that in the flash authoring app and  
>>> import the
>>> swf
>>> using --swf-lib in the hxml file. Then you can use the library  
>>> from that
>>> swf
>>> like so: mcFromFlash:MovieClip =
> flash.Lib.attach("NameOfObjectInLibrary");
>>>
>>> Moving Sprites around and doing hit testing is easy since this is  
>>> also
>>> built
>>> in. If you only have a few moving objects, simply doing
>>> "mySprite.hitTestPoint(x, y, true);" will work for pixel perfect
> collision
>>> detection. Then you can have all your walls and non-walk-through  
>>> stuff in
> a
>>> single Sprite, and hit test against that sprite. Check out the
>>> documentation
>>> for the Sprite class:
>>>
>>>
> http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/Spri
>>>
> te.html<http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/disp
> lay/Spri%0Ate.html>
>>>
>>> An other way of animating your world and achieving collision  
>>> detection is
>>> to
>>> use a physics lib such as Box2D or PhysaXe. PhysaXe is really fast  
>>> if you
>>> only need collision detection. Box2D is slower, but has more  
>>> features and
>>> is
>>> better documented. The downside of this approach is that  
>>> everything in
> your
>>> world needs to be a polygon. Google these for more info.
>>>
>>> /J
>>>
>>> On 22 nov 2009, at 06:24, Richard Stranberg wrote:
>>>
>>>> Hello Everyone,
>>>>
>>>> I have a couple of newb questions.
>>>>
>>>> I'm interested in developing a 2D games in haxe that have a lot of
>>> objects
>>>> in them.  Most of them are stationary but some will move and be
> animated.
>>> I
>>>> guess what I want to know is:
>>>>
>>>> 1)  What's the best way to move graphics around?  I've seen a lot  
>>>> of
>>> things
>>>> about sprites and even some code examples, but then I've also  
>>>> read that
>>> it's
>>>> hard to animate sprites.
>>>>
>>>> Also, when I move characters around the screen, there'll be a lot  
>>>> of
>>>> stationary objects.
>>>> 2)  Should these be sprties also?  Or simply bitmaps?  Or something
> else?
>>>>
>>>> And finally, collision detection,
>>>> 3)  I would like to navigate my character through a path with  
>>>> walls and
>>> not
>>>> being able to go through the walls.  Do I just make the walls  
>>>> separate
>>>> objects, create a coarse array that will contain whether a wall  
>>>> object
>>>> exists there or not and check the x and y coordiantes of my  
>>>> character
>>> when
>>>> it comes close to a corresponding wall object within that  
>>>> particular
> part
>>> of
>>>> the array?  Or is there a better way?
>>>>
>>>> Thanks a lot for answering my newb questions.
>>>> Rick
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>
>>>
>>>
>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
> http://lists.motion-twin.com/pipermail/haxe/attachments/20091123/36e6207a/at
> tachment-0001.htm
>
>> ------------------------------
>
>
>
> --
> 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: Re: RE: A couple of newb questions (gershon)

gershon
Another approach, which might be more coder oriented, is using haxe's resource compiling, the -resource switch can be used to embed a sprite-sheet into the swf,
-resource SHEET1.JPG@sheet1
grab it with something like haxe.Resource.getBytes("sheet1")
this makes it very easy, and old-school to embed bitmaps
other advantages of using bitmaps and bitmapdata, is that they are fast and reusable (sprites have to be cloned, multiple bitmaps can share same bitmapdata)
flash does'nt really need double buffering, but offscreen drawing to a bitmapdata then blitting is the old-school way to avoid flickering due to vsync...

just to mention another great thing about haxe that i just thought of, having multiple targets, your "backend" stuff does'nt have to be all flashy, even though the "frontend" (game) is...
i'll give the 2 examples that i thought of, a small nekol commandline tool, to take multiple tiles and joint them into a single tilemap, the other can be a level editor, in html+js, can elaborate if needed...

good day, gershon

On Tue, Nov 24, 2009 at 5:38 AM, Justin Lawerance Mills <[hidden email]> wrote:
Rick

Just thought it might be useful to mention, sprites don't have a timeline (often over looked by coders new to flash) and are not dynamic... that is to say traditionally flash coders sometimes use MovieClip's and then optimize to Sprites.  With MovieClips you can add variables and methods to instances directly and haXe will not type check, this makes them easier to prototype and easier to treat a set of different objects the same - if they happen to all be cast as MovieClips, sprites have a slightly lower overhead but for rapid development, MovieClips are worth using, and I often find if you are using both it can be simpler to just use MovieClips and only optimize if needed.

Cheers ;j





On 24 Nov 2009, at 02:50, Richard Stranberg wrote:

Hi Gershon,

I agree with you 100% -  games should be as much fun to play as they are to
write!

When I think of Sprites, I think of the old Commodore 64 days, when you had
8 hardware sprites that you could program.  I just feel like after browsing
through the mail messages a lot, that there were several ways to move
graphics and sprites didn't seem to be on the top of the list.  Also, I feel
like I've read that animating sprites is difficult as well.    The
information that you and Joacim have provided is very valuable.  Again, I
don't know why there was this big disconnect in my head for not considering
the AS3 APIs.  I guess I was just thinking of Java or something where the
stuff is right there; you just have to import it.

Rick

2D Games have been with us for about 3 decades, so most of the things
you've
mentioned have already been named in the "jargon"...
"Graphically moving about", can range from "jumping" from tile to tile on
the screen, in constant gird-sized steps, to "simple" movement
(sprite.x++),
and complex parametric physical simulations, using floating-point values
and
sub-pixel rendering...

Sprite in the old (non-flash) sense, usually meant you'd have a so called
"Sprite-sheet" (http://www.freewebs.com/hadouken_dude/DBZvegetassj2.gif),
from which parts would be cropped in accordance to a specific action \
frame, those are just bitmaps.

Sprite in flash's sense (which i'm guessing is the platform we're talking
about) is a much more generic thing, which does'nt necessarily contain
color
bits,  but can also hold parametric curves ("Vectors" in designer's
jargon)
and surfaces.

Regarding (3), there's more than one way to go about this, the simplest
being "Tile-Based", found in most "Side-Scrolling Platforms" (mario clones
:)), much like you've said, usually a 2D int array is used
(Array<Array<Int>>) where the indices specify offset from the top left,
and
the value an offset in a sprite-sheet:
00000000000
00000000010
00100001110
22222222222

Tile sized is costant, usually 2^n, 32x32, 64x64... Values can be, 0 -
Sky,
1 - Rock, 2 - Ground...
The simplest form of collision detection is called "Bounding-Box Collision
Detection", and is still used as a primary stage to minimize cpu cycles
when
doing more complex "Pixel-Perfect Collision Detection".

One last thing i'd like to mention, regards AI, "Pathfinding" is used when
the baddie chases the player (http://lib.haxe.org/p/aPath for haxe is
sweet), "Line-of-Sight" is when those nasties shoot at you :)

Best of luck, and remember than writing the thing should be at least as
fun
as playing it.


On Mon, Nov 23, 2009 at 1:34 AM, Richard Stranberg
<[hidden email]
wrote:


Thanks a lot, Joacim!  That's exactly what I was looking for.  I was over
at
Nicolas's blog yesterday looking at PhysaXe.  Pretty impressive!  I think
I'm starting to get the big picture in this now.  For a while I had a big
"disconnect" in my head.  I didn't understand why people would refer to
the
adobe AS3 (or whichever) API documentation; I always thought that "haXe
is
it's own language, where are its' APIs?"  I don't know why it took me so
long to understand that just like any language, you have the language
itself
that you develop in and the API's to the machine that you're working on -
in
this case Adobe's Flash engine.  I just don't do this enough...!

Thanks again!

Rick




Hi Rick,

When you deal with graphics in flash, pretty much everything will be a
Sprite object, or something else derived from the DisplayObject class. Of
course, you could write your own graphics engine that render to a
BitmapData
instance for more specialized graphics. But in most cases using the
built-in
Sprite class will do just fine.

If you need advanced animation, such as animating the limbs of your
character etc, you can do that in the flash authoring app and import the
swf
using --swf-lib in the hxml file. Then you can use the library from that
swf
like so: mcFromFlash:MovieClip =
flash.Lib.attach("NameOfObjectInLibrary");

Moving Sprites around and doing hit testing is easy since this is also
built
in. If you only have a few moving objects, simply doing
"mySprite.hitTestPoint(x, y, true);" will work for pixel perfect
collision
detection. Then you can have all your walls and non-walk-through stuff in
a
single Sprite, and hit test against that sprite. Check out the
documentation
for the Sprite class:


http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/Spri

te.html<http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/disp
lay/Spri%0Ate.html>

An other way of animating your world and achieving collision detection is
to
use a physics lib such as Box2D or PhysaXe. PhysaXe is really fast if you
only need collision detection. Box2D is slower, but has more features and
is
better documented. The downside of this approach is that everything in
your
world needs to be a polygon. Google these for more info.

/J

On 22 nov 2009, at 06:24, Richard Stranberg wrote:

Hello Everyone,

I have a couple of newb questions.

I'm interested in developing a 2D games in haxe that have a lot of
objects
in them.  Most of them are stationary but some will move and be
animated.
I
guess what I want to know is:

1)  What's the best way to move graphics around?  I've seen a lot of
things
about sprites and even some code examples, but then I've also read that
it's
hard to animate sprites.

Also, when I move characters around the screen, there'll be a lot of
stationary objects.
2)  Should these be sprties also?  Or simply bitmaps?  Or something
else?

And finally, collision detection,
3)  I would like to navigate my character through a path with walls and
not
being able to go through the walls.  Do I just make the walls separate
objects, create a coarse array that will contain whether a wall object
exists there or not and check the x and y coordiantes of my character
when
it comes close to a corresponding wall object within that particular
part
of
the array?  Or is there a better way?

Thanks a lot for answering my newb questions.
Rick




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





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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.motion-twin.com/pipermail/haxe/attachments/20091123/36e6207a/at
tachment-0001.htm

------------------------------



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


--
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: Re: RE: A couple of newb questions (gershon)

Richard Stranberg
In reply to this post by Richard Stranberg
Hi Justin,

Thanks for the tip; I'll definitely keep that in mind.

Rick


>Rick
>
>Just thought it might be useful to mention, sprites don't have a
>timeline (often over looked by coders new to flash) and are not
>dynamic... that is to say traditionally flash coders sometimes use
>MovieClip's and then optimize to Sprites.  With MovieClips you can add
>variables and methods to instances directly and haXe will not type
>check, this makes them easier to prototype and easier to treat a set
>of different objects the same - if they happen to all be cast as
>MovieClips, sprites have a slightly lower overhead but for rapid
>development, MovieClips are worth using, and I often find if you are
>using both it can be simpler to just use MovieClips and only optimize
>if needed.
>
>Cheers ;j
>
>


On 24 Nov 2009, at 02:50, Richard Stranberg wrote:

> Hi Gershon,
>
> I agree with you 100% -  games should be as much fun to play as they
> are to
> write!
>
> When I think of Sprites, I think of the old Commodore 64 days, when
> you had
> 8 hardware sprites that you could program.  I just feel like after
> browsing
> through the mail messages a lot, that there were several ways to move
> graphics and sprites didn't seem to be on the top of the list.
> Also, I feel
> like I've read that animating sprites is difficult as well.    The
> information that you and Joacim have provided is very valuable.
> Again, I
> don't know why there was this big disconnect in my head for not
> considering
> the AS3 APIs.  I guess I was just thinking of Java or something
> where the
> stuff is right there; you just have to import it.
>
> Rick
>
>> 2D Games have been with us for about 3 decades, so most of the things
> you've
>> mentioned have already been named in the "jargon"...
>> "Graphically moving about", can range from "jumping" from tile to
>> tile on
>> the screen, in constant gird-sized steps, to "simple" movement
> (sprite.x++),
>> and complex parametric physical simulations, using floating-point
>> values
> and
>> sub-pixel rendering...
>>
>> Sprite in the old (non-flash) sense, usually meant you'd have a so
>> called
>> "Sprite-sheet" (http://www.freewebs.com/hadouken_dude/DBZvegetassj2.gif
>> ),
>> from which parts would be cropped in accordance to a specific
>> action \
>> frame, those are just bitmaps.
>>
>> Sprite in flash's sense (which i'm guessing is the platform we're
>> talking
>> about) is a much more generic thing, which does'nt necessarily
>> contain
> color
>> bits,  but can also hold parametric curves ("Vectors" in designer's
> jargon)
>> and surfaces.
>>
>> Regarding (3), there's more than one way to go about this, the
>> simplest
>> being "Tile-Based", found in most "Side-Scrolling Platforms" (mario
>> clones
>> :)), much like you've said, usually a 2D int array is used
>> (Array<Array<Int>>) where the indices specify offset from the top
>> left,
> and
>> the value an offset in a sprite-sheet:
>> 00000000000
>> 00000000010
>> 00100001110
>> 22222222222
>>
>> Tile sized is costant, usually 2^n, 32x32, 64x64... Values can be,
>> 0 -
> Sky,
>> 1 - Rock, 2 - Ground...
>> The simplest form of collision detection is called "Bounding-Box
>> Collision
>> Detection", and is still used as a primary stage to minimize cpu
>> cycles
> when
>> doing more complex "Pixel-Perfect Collision Detection".
>>
>> One last thing i'd like to mention, regards AI, "Pathfinding" is
>> used when
>> the baddie chases the player (http://lib.haxe.org/p/aPath for haxe is
>> sweet), "Line-of-Sight" is when those nasties shoot at you :)
>>
>> Best of luck, and remember than writing the thing should be at
>> least as
> fun
>> as playing it.
>>
>>
>> On Mon, Nov 23, 2009 at 1:34 AM, Richard Stranberg
> <[hidden email]
>> wrote:
>>>
>>>
>>> Thanks a lot, Joacim!  That's exactly what I was looking for.  I
>>> was over
>>> at
>>> Nicolas's blog yesterday looking at PhysaXe.  Pretty impressive!
>>> I think
>>> I'm starting to get the big picture in this now.  For a while I
>>> had a big
>>> "disconnect" in my head.  I didn't understand why people would
>>> refer to
> the
>>> adobe AS3 (or whichever) API documentation; I always thought that
>>> "haXe
> is
>>> it's own language, where are its' APIs?"  I don't know why it took
>>> me so
>>> long to understand that just like any language, you have the
>>> language
>>> itself
>>> that you develop in and the API's to the machine that you're
>>> working on -
>>> in
>>> this case Adobe's Flash engine.  I just don't do this enough...!
>>>
>>> Thanks again!
>>>
>>> Rick
>>>
>>>
>>>
>>>
>>> Hi Rick,
>>>
>>> When you deal with graphics in flash, pretty much everything will
>>> be a
>>> Sprite object, or something else derived from the DisplayObject
>>> class. Of
>>> course, you could write your own graphics engine that render to a
>>> BitmapData
>>> instance for more specialized graphics. But in most cases using the
>>> built-in
>>> Sprite class will do just fine.
>>>
>>> If you need advanced animation, such as animating the limbs of your
>>> character etc, you can do that in the flash authoring app and
>>> import the
>>> swf
>>> using --swf-lib in the hxml file. Then you can use the library
>>> from that
>>> swf
>>> like so: mcFromFlash:MovieClip =
> flash.Lib.attach("NameOfObjectInLibrary");
>>>
>>> Moving Sprites around and doing hit testing is easy since this is
>>> also
>>> built
>>> in. If you only have a few moving objects, simply doing
>>> "mySprite.hitTestPoint(x, y, true);" will work for pixel perfect
> collision
>>> detection. Then you can have all your walls and non-walk-through
>>> stuff in
> a
>>> single Sprite, and hit test against that sprite. Check out the
>>> documentation
>>> for the Sprite class:
>>>
>>>
>
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/Spri
>>>
>
te.html<http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/disp

> lay/Spri%0Ate.html>
>>>
>>> An other way of animating your world and achieving collision
>>> detection is
>>> to
>>> use a physics lib such as Box2D or PhysaXe. PhysaXe is really fast
>>> if you
>>> only need collision detection. Box2D is slower, but has more
>>> features and
>>> is
>>> better documented. The downside of this approach is that
>>> everything in
> your
>>> world needs to be a polygon. Google these for more info.
>>>
>>> /J
>>>
>>> On 22 nov 2009, at 06:24, Richard Stranberg wrote:
>>>
>>>> Hello Everyone,
>>>>
>>>> I have a couple of newb questions.
>>>>
>>>> I'm interested in developing a 2D games in haxe that have a lot of
>>> objects
>>>> in them.  Most of them are stationary but some will move and be
> animated.
>>> I
>>>> guess what I want to know is:
>>>>
>>>> 1)  What's the best way to move graphics around?  I've seen a lot
>>>> of
>>> things
>>>> about sprites and even some code examples, but then I've also
>>>> read that
>>> it's
>>>> hard to animate sprites.
>>>>
>>>> Also, when I move characters around the screen, there'll be a lot
>>>> of
>>>> stationary objects.
>>>> 2)  Should these be sprties also?  Or simply bitmaps?  Or something
> else?
>>>>
>>>> And finally, collision detection,
>>>> 3)  I would like to navigate my character through a path with
>>>> walls and
>>> not
>>>> being able to go through the walls.  Do I just make the walls
>>>> separate
>>>> objects, create a coarse array that will contain whether a wall
>>>> object
>>>> exists there or not and check the x and y coordiantes of my
>>>> character
>>> when
>>>> it comes close to a corresponding wall object within that
>>>> particular
> part
>>> of
>>>> the array?  Or is there a better way?
>>>>
>>>> Thanks a lot for answering my newb questions.
>>>> Rick
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>
>>>
>>>
>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>
http://lists.motion-twin.com/pipermail/haxe/attachments/20091123/36e6207a/at
> tachment-0001.htm
>
>> ------------------------------
>
>
>
> --
> 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: Re: Re: RE: A couple of newb questions (gershon)

Martijn Loots
Hi Justin.

I read your remark before and read it again now.

I'm rather new to Flash and it seems important to understand
what you were telling here, but the essence of your story
escapes me and it keeps nagging me...

Please, would you be so kind and elaborate on it, preferably
with a little example, so a newbie flash coder like me can
catch its meaning ??

(at this moment, I'm on a piece of 12000+ lines of code,
  most displayable objects subclassed from Sprite; it would
  be nice to know if this was the right design choice...)

TIA,
--
-Martijn


On Sat, 28 Nov 2009, Richard Stranberg wrote:

> Hi Justin,
>
> Thanks for the tip; I'll definitely keep that in mind.
>
> Rick
>
>
>> Rick
>>
>> Just thought it might be useful to mention, sprites don't have a
>> timeline (often over looked by coders new to flash) and are not
>> dynamic... that is to say traditionally flash coders sometimes use
>> MovieClip's and then optimize to Sprites.  With MovieClips you can add
>> variables and methods to instances directly and haXe will not type
>> check, this makes them easier to prototype and easier to treat a set
>> of different objects the same - if they happen to all be cast as
>> MovieClips, sprites have a slightly lower overhead but for rapid
>> development, MovieClips are worth using, and I often find if you are
>> using both it can be simpler to just use MovieClips and only optimize
>> if needed.
>>
>> Cheers ;j
>>
>>
>
>
> On 24 Nov 2009, at 02:50, Richard Stranberg wrote:
>
>> Hi Gershon,
>>
>> I agree with you 100% -  games should be as much fun to play as they
>> are to
>> write!
>>
>> When I think of Sprites, I think of the old Commodore 64 days, when
>> you had
>> 8 hardware sprites that you could program.  I just feel like after
>> browsing
>> through the mail messages a lot, that there were several ways to move
>> graphics and sprites didn't seem to be on the top of the list.
>> Also, I feel
>> like I've read that animating sprites is difficult as well.    The
>> information that you and Joacim have provided is very valuable.
>> Again, I
>> don't know why there was this big disconnect in my head for not
>> considering
>> the AS3 APIs.  I guess I was just thinking of Java or something
>> where the
>> stuff is right there; you just have to import it.
>>
>> Rick
>>
>>> 2D Games have been with us for about 3 decades, so most of the things
>> you've
>>> mentioned have already been named in the "jargon"...
>>> "Graphically moving about", can range from "jumping" from tile to
>>> tile on
>>> the screen, in constant gird-sized steps, to "simple" movement
>> (sprite.x++),
>>> and complex parametric physical simulations, using floating-point
>>> values
>> and
>>> sub-pixel rendering...
>>>
>>> Sprite in the old (non-flash) sense, usually meant you'd have a so
>>> called
>>> "Sprite-sheet" (http://www.freewebs.com/hadouken_dude/DBZvegetassj2.gif
>>> ),
>>> from which parts would be cropped in accordance to a specific
>>> action \
>>> frame, those are just bitmaps.
>>>
>>> Sprite in flash's sense (which i'm guessing is the platform we're
>>> talking
>>> about) is a much more generic thing, which does'nt necessarily
>>> contain
>> color
>>> bits,  but can also hold parametric curves ("Vectors" in designer's
>> jargon)
>>> and surfaces.
>>>
>>> Regarding (3), there's more than one way to go about this, the
>>> simplest
>>> being "Tile-Based", found in most "Side-Scrolling Platforms" (mario
>>> clones
>>> :)), much like you've said, usually a 2D int array is used
>>> (Array<Array<Int>>) where the indices specify offset from the top
>>> left,
>> and
>>> the value an offset in a sprite-sheet:
>>> 00000000000
>>> 00000000010
>>> 00100001110
>>> 22222222222
>>>
>>> Tile sized is costant, usually 2^n, 32x32, 64x64... Values can be,
>>> 0 -
>> Sky,
>>> 1 - Rock, 2 - Ground...
>>> The simplest form of collision detection is called "Bounding-Box
>>> Collision
>>> Detection", and is still used as a primary stage to minimize cpu
>>> cycles
>> when
>>> doing more complex "Pixel-Perfect Collision Detection".
>>>
>>> One last thing i'd like to mention, regards AI, "Pathfinding" is
>>> used when
>>> the baddie chases the player (http://lib.haxe.org/p/aPath for haxe is
>>> sweet), "Line-of-Sight" is when those nasties shoot at you :)
>>>
>>> Best of luck, and remember than writing the thing should be at
>>> least as
>> fun
>>> as playing it.
>>>
>>>
>>> On Mon, Nov 23, 2009 at 1:34 AM, Richard Stranberg
>> <[hidden email]
>>> wrote:
>>>>
>>>>
>>>> Thanks a lot, Joacim!  That's exactly what I was looking for.  I
>>>> was over
>>>> at
>>>> Nicolas's blog yesterday looking at PhysaXe.  Pretty impressive!
>>>> I think
>>>> I'm starting to get the big picture in this now.  For a while I
>>>> had a big
>>>> "disconnect" in my head.  I didn't understand why people would
>>>> refer to
>> the
>>>> adobe AS3 (or whichever) API documentation; I always thought that
>>>> "haXe
>> is
>>>> it's own language, where are its' APIs?"  I don't know why it took
>>>> me so
>>>> long to understand that just like any language, you have the
>>>> language
>>>> itself
>>>> that you develop in and the API's to the machine that you're
>>>> working on -
>>>> in
>>>> this case Adobe's Flash engine.  I just don't do this enough...!
>>>>
>>>> Thanks again!
>>>>
>>>> Rick
>>>>
>>>>
>>>>
>>>>
>>>> Hi Rick,
>>>>
>>>> When you deal with graphics in flash, pretty much everything will
>>>> be a
>>>> Sprite object, or something else derived from the DisplayObject
>>>> class. Of
>>>> course, you could write your own graphics engine that render to a
>>>> BitmapData
>>>> instance for more specialized graphics. But in most cases using the
>>>> built-in
>>>> Sprite class will do just fine.
>>>>
>>>> If you need advanced animation, such as animating the limbs of your
>>>> character etc, you can do that in the flash authoring app and
>>>> import the
>>>> swf
>>>> using --swf-lib in the hxml file. Then you can use the library
>>>> from that
>>>> swf
>>>> like so: mcFromFlash:MovieClip =
>> flash.Lib.attach("NameOfObjectInLibrary");
>>>>
>>>> Moving Sprites around and doing hit testing is easy since this is
>>>> also
>>>> built
>>>> in. If you only have a few moving objects, simply doing
>>>> "mySprite.hitTestPoint(x, y, true);" will work for pixel perfect
>> collision
>>>> detection. Then you can have all your walls and non-walk-through
>>>> stuff in
>> a
>>>> single Sprite, and hit test against that sprite. Check out the
>>>> documentation
>>>> for the Sprite class:
>>>>
>>>>
>>
> http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/Spri
>>>>
>>
> te.html<http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/disp
>> lay/Spri%0Ate.html>
>>>>
>>>> An other way of animating your world and achieving collision
>>>> detection is
>>>> to
>>>> use a physics lib such as Box2D or PhysaXe. PhysaXe is really fast
>>>> if you
>>>> only need collision detection. Box2D is slower, but has more
>>>> features and
>>>> is
>>>> better documented. The downside of this approach is that
>>>> everything in
>> your
>>>> world needs to be a polygon. Google these for more info.
>>>>
>>>> /J
>>>>
>>>> On 22 nov 2009, at 06:24, Richard Stranberg wrote:
>>>>
>>>>> Hello Everyone,
>>>>>
>>>>> I have a couple of newb questions.
>>>>>
>>>>> I'm interested in developing a 2D games in haxe that have a lot of
>>>> objects
>>>>> in them.  Most of them are stationary but some will move and be
>> animated.
>>>> I
>>>>> guess what I want to know is:
>>>>>
>>>>> 1)  What's the best way to move graphics around?  I've seen a lot
>>>>> of
>>>> things
>>>>> about sprites and even some code examples, but then I've also
>>>>> read that
>>>> it's
>>>>> hard to animate sprites.
>>>>>
>>>>> Also, when I move characters around the screen, there'll be a lot
>>>>> of
>>>>> stationary objects.
>>>>> 2)  Should these be sprties also?  Or simply bitmaps?  Or something
>> else?
>>>>>
>>>>> And finally, collision detection,
>>>>> 3)  I would like to navigate my character through a path with
>>>>> walls and
>>>> not
>>>>> being able to go through the walls.  Do I just make the walls
>>>>> separate
>>>>> objects, create a coarse array that will contain whether a wall
>>>>> object
>>>>> exists there or not and check the x and y coordiantes of my
>>>>> character
>>>> when
>>>>> it comes close to a corresponding wall object within that
>>>>> particular
>> part
>>>> of
>>>>> the array?  Or is there a better way?
>>>>>
>>>>> Thanks a lot for answering my newb questions.
>>>>> Rick
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> haXe - an open source web programming language
>>>>> http://haxe.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>> -------------- next part --------------
>>>> An HTML attachment was scrubbed...
>>>> URL:
>>
> http://lists.motion-twin.com/pipermail/haxe/attachments/20091123/36e6207a/at
>> tachment-0001.htm
>>
>>> ------------------------------
>>
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
>
>
> ------------------------------
>
>
>

--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

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

Re: Re: Re: RE: A couple of newb questions (gershon)

jlm@justinfront.net
Martijn

Not sure if this explains better??

I am sure your probably very advanced its probably more a matter of a difference of approaches.

I extend EventDispatcher rather than Sprite as I prefer composition rather than inheritance when it comes to views rarely do I need access to all the properties of a Sprite or MovieClip, this is a personal choice and many may disagree, obviously with something like HSL you don't even need to extend EventDispatcher and I mean to look at HSL in more depth.   Since I load a layout at runtime created in Flash IDE to avoid cross compiling symbols in the library just extend MovieClip and I divert the events of the MovieClip to the composite view controlling them  ( sometimes using callback if there are several doing similar so I can pass and index to the event ), this allows a more coarse oop where you may have one class dealing with several MovieClips needed to make a scrollbar or several MovieClips used in a video player controller view.

Mixing MovieClips and Sprite is a pain they are more or less the same but its tricky to create code that works the same for both especially if your more designer than coder coder, it has been argued that there was no need to invent Sprites they only offer a small perfomance gain but compexify the language.  MovieClips are dynamic so they are really easy to add properties directly to, you don't have to create a class just to store/add a property.  I learnt flash from AS1 where we regularly add function to MovieClips as methods and even properties to functions so instead of phototyping classes your adding funtionality and properties to instances... I am not saying its not hacky but it allows for fast development and testing of concepts, the idea of classes is not always valid with view objects as you are often dealing with lots of different instances of MovieClip and to create a different class for each one is maybe redundant, I guess you could call it decorating instances, so while I am mostly coding more strict I like to keep some of that fast hack power to hand.

Anyway a MovieClip allows you to add a property on the fly without having to create a new class, while for planned code this is maybe bad, for fixing something fast like a special case it can be ideal.

As a simple example here is a simple slider bar class, it happens to be AS3 but I could easily port it to haXe, if I need to.   Because I am using MovieClips I can dump a property on the _slidee or _sliderBar, I could also have a timeline or use buttonMode ( and use labeled keyframes 'up', 'over' and 'down' and let flash auto control going to the states ) for different visual states for instance you may have a simple timeline pulsating glow.  Sprites are just not as flexible, and if suddenly you find you need to convert a Sprite to a MovieClip you may have to modify your code in lots of places or if you have some sprites and some movieclips real pain, so unless its really makes a difference in speed, like particles or 3d, then MovieClips are quicker for development, I think you can use class higher up the chain but then there are issues with limiting to classes that are allowed to be added to stage etc..., and you may have to do lots of casts - as more generic display objects may not have functionality you know you have so you have to recast them back up to a MovieClip.

The example below of a simple view, uses MovieClips so you can modify them as needed and does not tie creation or physical structure too closely to the view so these could use MovieClips in separate places so you can put masks on top of one etc...  I have found that Sprite inheritance ties the oop logic to the visual structure and can make the logic more convolutde, and can cause all sorts of hoop jumping also I often prefer to layout structures in Flash IDE and then add logic in haXe or AS3 ( I use a 2 or more movie approach - code movie, graphics movie, xml, +loadable images/video/collada).

But this is my approach (http://haxe.org/doc/flash/compositeflashgraphicswithhaxe) and it may not suit other coders.

Cheers

;j

Simple example of a useful but simple view (as3)

package net.justinfront.utils
{

   
import flash.display.*;
   
import flash.filters.*;
   
import flash.display.Stage;
   
import flash.events.*;
   
import flash.geom.*;
   
   
import net.justinfront.events.SliderBarEvent;
   
   
public class SliderBar extends EventDispatcher
    {
       
       
// TODO: abstract to vert version
       
       
private var _slidee:            MovieClip;
       
private var _sliderBar:         MovieClip;
       
private var _min:               Number;
       
private var _max:               Number;
       
private var _range:             Number;
       
private var _y:                 Number;
       
private var _x:                 Number;
       
private var _width:             Number;
       
public static var DX:           Number      = 3;
       
private var _ratio:             Number;
       
private var _val:               Number;
       
private var _dragging:          Boolean     = false;
       
       
public function set value( val_ : Number ):void
        {
           
           
_val            = val_;
           
_slidee.x       = _x + _val/_ratio - _min/_ratio + _slidee.width/2;
           
        }
       
       
       
public function get value(): Number
        {
           
           
return _val;
           
        }
       
       
       
       
public function SliderBar(
                                    slidee_
:        MovieClip,
                                    sliderBar_
:     MovieClip,
                                    min_
:           Number,
                                    max_
:           Number,
                                    val_
:           Number
                                )
        {
           
           
super();
           
_slidee         = slidee_;
           
_sliderBar      = sliderBar_;
           
_min            = min_;
           
_max            = max_;
           
           
_y              = _slidee.y;
           
_x              = _sliderBar.x + DX;
           
_width          = _sliderBar.width - 2*DX - _slidee.width/2;
           
_range          = _max - _min;
           
_ratio          = _range/_width;
           
           
value           = val_;
           
           
init();
           
        }
       
       
       
private function init():void
        {
           
           
_slidee.addEventListener( MouseEvent.MOUSE_DOWN,    dragMe );
           
_slidee.addEventListener( MouseEvent.MOUSE_UP,      dragEnd );
           
_slidee.stage.addEventListener( MouseEvent.MOUSE_UP, dragEnd );
           
_slidee.mouseChildren   = false;
           
_slidee.buttonMode      = true;
           
           
        }
       
       
       
private function update( e: Event ):void
        {
           
           
_val = (_slidee.x - _x )*_ratio + _min;
           
dispatchEvent( new SliderBarEvent( SliderBarEvent.CHANGE,
                                               
true,
                                               
false
                                            ))
;
        }
       
       
       
private function dragMe( e: Event )
        {
           
_dragging = true;
           
_slidee.startDrag( false, new Rectangle( _x, _y, _width, 0 ) );
           
_slidee.addEventListener( MouseEvent.MOUSE_MOVE, update );
           
        }
       
       
       
private function dragEnd( e: Event )
        {
           
if( _dragging == true )
            {
               
               
_slidee.stopDrag();
               
_slidee.addEventListener( MouseEvent.MOUSE_MOVE, update );
               
               
dispatchEvent( new SliderBarEvent( SliderBarEvent.CHANGE_FINISH,
                                               
true,
                                               
false
                                            ))
;
                                           
_dragging = false;
            }
        }
       
       
    }
   
   
}

On 29 Nov 2009, at 12:24, Martijn Loots wrote:

Hi Justin.

I read your remark before and read it again now.

I'm rather new to Flash and it seems important to understand
what you were telling here, but the essence of your story
escapes me and it keeps nagging me...

Please, would you be so kind and elaborate on it, preferably
with a little example, so a newbie flash coder like me can
catch its meaning ??

(at this moment, I'm on a piece of 12000+ lines of code,
most displayable objects subclassed from Sprite; it would
be nice to know if this was the right design choice...)

TIA,
--
-Martijn


On Sat, 28 Nov 2009, Richard Stranberg wrote:

Hi Justin,

Thanks for the tip; I'll definitely keep that in mind.

Rick


Rick

Just thought it might be useful to mention, sprites don't have a
timeline (often over looked by coders new to flash) and are not
dynamic... that is to say traditionally flash coders sometimes use
MovieClip's and then optimize to Sprites.  With MovieClips you can add
variables and methods to instances directly and haXe will not type
check, this makes them easier to prototype and easier to treat a set
of different objects the same - if they happen to all be cast as
MovieClips, sprites have a slightly lower overhead but for rapid
development, MovieClips are worth using, and I often find if you are
using both it can be simpler to just use MovieClips and only optimize
if needed.

Cheers ;j




On 24 Nov 2009, at 02:50, Richard Stranberg wrote:

Hi Gershon,

I agree with you 100% -  games should be as much fun to play as they
are to
write!

When I think of Sprites, I think of the old Commodore 64 days, when
you had
8 hardware sprites that you could program.  I just feel like after
browsing
through the mail messages a lot, that there were several ways to move
graphics and sprites didn't seem to be on the top of the list.
Also, I feel
like I've read that animating sprites is difficult as well.    The
information that you and Joacim have provided is very valuable.
Again, I
don't know why there was this big disconnect in my head for not
considering
the AS3 APIs.  I guess I was just thinking of Java or something
where the
stuff is right there; you just have to import it.

Rick

2D Games have been with us for about 3 decades, so most of the things
you've
mentioned have already been named in the "jargon"...
"Graphically moving about", can range from "jumping" from tile to
tile on
the screen, in constant gird-sized steps, to "simple" movement
(sprite.x++),
and complex parametric physical simulations, using floating-point
values
and
sub-pixel rendering...

Sprite in the old (non-flash) sense, usually meant you'd have a so
called
"Sprite-sheet" (http://www.freewebs.com/hadouken_dude/DBZvegetassj2.gif
),
from which parts would be cropped in accordance to a specific
action \
frame, those are just bitmaps.

Sprite in flash's sense (which i'm guessing is the platform we're
talking
about) is a much more generic thing, which does'nt necessarily
contain
color
bits,  but can also hold parametric curves ("Vectors" in designer's
jargon)
and surfaces.

Regarding (3), there's more than one way to go about this, the
simplest
being "Tile-Based", found in most "Side-Scrolling Platforms" (mario
clones
:)), much like you've said, usually a 2D int array is used
(Array<Array<Int>>) where the indices specify offset from the top
left,
and
the value an offset in a sprite-sheet:
00000000000
00000000010
00100001110
22222222222

Tile sized is costant, usually 2^n, 32x32, 64x64... Values can be,
0 -
Sky,
1 - Rock, 2 - Ground...
The simplest form of collision detection is called "Bounding-Box
Collision
Detection", and is still used as a primary stage to minimize cpu
cycles
when
doing more complex "Pixel-Perfect Collision Detection".

One last thing i'd like to mention, regards AI, "Pathfinding" is
used when
the baddie chases the player (http://lib.haxe.org/p/aPath for haxe is
sweet), "Line-of-Sight" is when those nasties shoot at you :)

Best of luck, and remember than writing the thing should be at
least as
fun
as playing it.


On Mon, Nov 23, 2009 at 1:34 AM, Richard Stranberg
<[hidden email]
wrote:


Thanks a lot, Joacim!  That's exactly what I was looking for.  I
was over
at
Nicolas's blog yesterday looking at PhysaXe.  Pretty impressive!
I think
I'm starting to get the big picture in this now.  For a while I
had a big
"disconnect" in my head.  I didn't understand why people would
refer to
the
adobe AS3 (or whichever) API documentation; I always thought that
"haXe
is
it's own language, where are its' APIs?"  I don't know why it took
me so
long to understand that just like any language, you have the
language
itself
that you develop in and the API's to the machine that you're
working on -
in
this case Adobe's Flash engine.  I just don't do this enough...!

Thanks again!

Rick




Hi Rick,

When you deal with graphics in flash, pretty much everything will
be a
Sprite object, or something else derived from the DisplayObject
class. Of
course, you could write your own graphics engine that render to a
BitmapData
instance for more specialized graphics. But in most cases using the
built-in
Sprite class will do just fine.

If you need advanced animation, such as animating the limbs of your
character etc, you can do that in the flash authoring app and
import the
swf
using --swf-lib in the hxml file. Then you can use the library
from that
swf
like so: mcFromFlash:MovieClip =
flash.Lib.attach("NameOfObjectInLibrary");

Moving Sprites around and doing hit testing is easy since this is
also
built
in. If you only have a few moving objects, simply doing
"mySprite.hitTestPoint(x, y, true);" will work for pixel perfect
collision
detection. Then you can have all your walls and non-walk-through
stuff in
a
single Sprite, and hit test against that sprite. Check out the
documentation
for the Sprite class:



http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/Spri


te.html<http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/disp
lay/Spri%0Ate.html>

An other way of animating your world and achieving collision
detection is
to
use a physics lib such as Box2D or PhysaXe. PhysaXe is really fast
if you
only need collision detection. Box2D is slower, but has more
features and
is
better documented. The downside of this approach is that
everything in
your
world needs to be a polygon. Google these for more info.

/J

On 22 nov 2009, at 06:24, Richard Stranberg wrote:

Hello Everyone,

I have a couple of newb questions.

I'm interested in developing a 2D games in haxe that have a lot of
objects
in them.  Most of them are stationary but some will move and be
animated.
I
guess what I want to know is:

1)  What's the best way to move graphics around?  I've seen a lot
of
things
about sprites and even some code examples, but then I've also
read that
it's
hard to animate sprites.

Also, when I move characters around the screen, there'll be a lot
of
stationary objects.
2)  Should these be sprties also?  Or simply bitmaps?  Or something
else?

And finally, collision detection,
3)  I would like to navigate my character through a path with
walls and
not
being able to go through the walls.  Do I just make the walls
separate
objects, create a coarse array that will contain whether a wall
object
exists there or not and check the x and y coordiantes of my
character
when
it comes close to a corresponding wall object within that
particular
part
of
the array?  Or is there a better way?

Thanks a lot for answering my newb questions.
Rick




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





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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

http://lists.motion-twin.com/pipermail/haxe/attachments/20091123/36e6207a/at
tachment-0001.htm

------------------------------



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




------------------------------




--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

--
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: Re: Re: RE: A couple of newb questions (gershon)

Martijn Loots
Thank you for the exhaustive reply... _O_  :)

I think I understand it better now and it tells me that my
earlier choice to move nearly all MovieClips to Sprite subclasses
in my project was IMHO correct.

The dynamic nature as you described for the MCs is of no
importance to me; I like to specify all ins and outs clearly
in the classes concerned. It may be slower to develop, but
is probably less error prone in the long run. The strict
nature of haXe has cleaned my mindset too... ;-)

As for composition vs. inheritance: I just like the nature of
Sprites to be able to resize, depending on the content. It is
a very important property to most of my classes, so I don't
feel much need to develop an even more slender Sprite by means
of composition of e.g. EventDispatcher. The Sprite just suits
my basic needs nicely I think. And so they end up to be compo-
sited into horrible big subclasses... :)

Anyways, I learned a thing or two again. Thank you very much.

Keep up the good work !

Happily haxing into 2010, greetings,
--
-Martijn

On Mon, 30 Nov 2009, Justin Lawerance Mills wrote:

> Martijn
>
> Not sure if this explains better??
>
> I am sure your probably very advanced its probably more a matter of a
> difference of approaches.
>
> I extend EventDispatcher rather than Sprite as I prefer composition rather
> than inheritance when it comes to views rarely do I need access to all the
> properties of a Sprite or MovieClip, this is a personal choice and many may
> disagree, obviously with something like HSL you don't even need to extend
> EventDispatcher and I mean to look at HSL in more depth.   Since I load a
> layout at runtime created in Flash IDE to avoid cross compiling symbols in
> the library just extend MovieClip and I divert the events of the MovieClip to
> the composite view controlling them  ( sometimes using callback if there are
> several doing similar so I can pass and index to the event ), this allows a
> more coarse oop where you may have one class dealing with several MovieClips
> needed to make a scrollbar or several MovieClips used in a video player
> controller view.
>
> Mixing MovieClips and Sprite is a pain they are more or less the same but its
> tricky to create code that works the same for both especially if your more
> designer than coder coder, it has been argued that there was no need to
> invent Sprites they only offer a small perfomance gain but compexify the
> language.  MovieClips are dynamic so they are really easy to add properties
> directly to, you don't have to create a class just to store/add a property.
> I learnt flash from AS1 where we regularly add function to MovieClips as
> methods and even properties to functions so instead of phototyping classes
> your adding funtionality and properties to instances... I am not saying its
> not hacky but it allows for fast development and testing of concepts, the
> idea of classes is not always valid with view objects as you are often
> dealing with lots of different instances of MovieClip and to create a
> different class for each one is maybe redundant, I guess you could call it
> decorating instances, so while I am mostly coding more strict I like to keep
> some of that fast hack power to hand.
>
> Anyway a MovieClip allows you to add a property on the fly without having to
> create a new class, while for planned code this is maybe bad, for fixing
> something fast like a special case it can be ideal.
>
> As a simple example here is a simple slider bar class, it happens to be AS3
> but I could easily port it to haXe, if I need to.   Because I am using
> MovieClips I can dump a property on the _slidee or _sliderBar, I could also
> have a timeline or use buttonMode ( and use labeled keyframes 'up', 'over'
> and 'down' and let flash auto control going to the states ) for different
> visual states for instance you may have a simple timeline pulsating glow.
> Sprites are just not as flexible, and if suddenly you find you need to
> convert a Sprite to a MovieClip you may have to modify your code in lots of
> places or if you have some sprites and some movieclips real pain, so unless
> its really makes a difference in speed, like particles or 3d, then MovieClips
> are quicker for development, I think you can use class higher up the chain
> but then there are issues with limiting to classes that are allowed to be
> added to stage etc..., and you may have to do lots of casts - as more generic
> display objects may not have functionality you know you have so you have to
> recast them back up to a MovieClip.
>
> The example below of a simple view, uses MovieClips so you can modify them as
> needed and does not tie creation or physical structure too closely to the
> view so these could use MovieClips in separate places so you can put masks on
> top of one etc...  I have found that Sprite inheritance ties the oop logic to
> the visual structure and can make the logic more convolutde, and can cause
> all sorts of hoop jumping also I often prefer to layout structures in Flash
> IDE and then add logic in haXe or AS3 ( I use a 2 or more movie approach -
> code movie, graphics movie, xml, +loadable images/video/collada).
>
> But this is my approach
> (http://haxe.org/doc/flash/compositeflashgraphicswithhaxe) and it may not
> suit other coders.
>
> Cheers
>
> ;j
>
> Simple example of a useful but simple view (as3)
>
> package net.justinfront.utils
> {
>
>   import flash.display.*;
>   import flash.filters.*;
>   import flash.display.Stage;
>   import flash.events.*;
>   import flash.geom.*;
>
>   import net.justinfront.events.SliderBarEvent;
>
>   public class SliderBar extends EventDispatcher
>   {
>
>       // TODO: abstract to vert version
>
>       private var _slidee:            MovieClip;
>       private var _sliderBar:         MovieClip;
>       private var _min:               Number;
>       private var _max:               Number;
>       private var _range:             Number;
>       private var _y:                 Number;
>       private var _x:                 Number;
>       private var _width:             Number;
>       public static var DX:           Number      = 3;
>       private var _ratio:             Number;
>       private var _val:               Number;
>       private var _dragging:          Boolean     = false;
>
>       public function set value( val_ : Number ):void
>       {
>
>           _val            = val_;
>           _slidee.x       = _x + _val/_ratio - _min/_ratio +
> _slidee.width/2;
>
>       }
>
>
>       public function get value(): Number
>       {
>
>           return _val;
>
>       }
>
>
>
>       public function SliderBar(
>                                   slidee_:        MovieClip,
>                                   sliderBar_:     MovieClip,
>                                   min_:           Number,
>                                   max_:           Number,
>                                   val_:           Number
>                               )
>       {
>
>           super();
>           _slidee         = slidee_;
>           _sliderBar      = sliderBar_;
>           _min            = min_;
>           _max            = max_;
>
>           _y              = _slidee.y;
>           _x              = _sliderBar.x + DX;
>           _width          = _sliderBar.width - 2*DX - _slidee.width/2;
>           _range          = _max - _min;
>           _ratio          = _range/_width;
>
>           value           = val_;
>
>           init();
>
>       }
>
>
>       private function init():void
>       {
>
>           _slidee.addEventListener( MouseEvent.MOUSE_DOWN,    dragMe );
>           _slidee.addEventListener( MouseEvent.MOUSE_UP,      dragEnd );
>           _slidee.stage.addEventListener( MouseEvent.MOUSE_UP, dragEnd );
>           _slidee.mouseChildren   = false;
>           _slidee.buttonMode      = true;
>
>
>       }
>
>
>       private function update( e: Event ):void
>       {
>
>           _val = (_slidee.x - _x )*_ratio + _min;
>           dispatchEvent( new SliderBarEvent( SliderBarEvent.CHANGE,
>                                               true,
>                                               false
>                                           ));
>       }
>
>
>       private function dragMe( e: Event )
>       {
>           _dragging = true;
>           _slidee.startDrag( false, new Rectangle( _x, _y, _width, 0 ) );
>           _slidee.addEventListener( MouseEvent.MOUSE_MOVE, update );
>
>       }
>
>
>       private function dragEnd( e: Event )
>       {
>           if( _dragging == true )
>           {
>
>               _slidee.stopDrag();
>               _slidee.addEventListener( MouseEvent.MOUSE_MOVE, update );
>
>               dispatchEvent( new SliderBarEvent(
> SliderBarEvent.CHANGE_FINISH,
>                                               true,
>                                               false
>                                           ));
>                                           _dragging = false;
>           }
>       }
>
>
>   }
>
>
> }
>
> On 29 Nov 2009, at 12:24, Martijn Loots wrote:
>
>> Hi Justin.
>>
>> I read your remark before and read it again now.
>>
>> I'm rather new to Flash and it seems important to understand
>> what you were telling here, but the essence of your story
>> escapes me and it keeps nagging me...
>>
>> Please, would you be so kind and elaborate on it, preferably
>> with a little example, so a newbie flash coder like me can
>> catch its meaning ??
>>
>> (at this moment, I'm on a piece of 12000+ lines of code,
>> most displayable objects subclassed from Sprite; it would
>> be nice to know if this was the right design choice...)
>>
>> TIA,
>> --
>> -Martijn
>>
>>
>> On Sat, 28 Nov 2009, Richard Stranberg wrote:
>>
>>> Hi Justin,
>>>
>>> Thanks for the tip; I'll definitely keep that in mind.
>>>
>>> Rick
>>>
>>>
>>>> Rick
>>>>
>>>> Just thought it might be useful to mention, sprites don't have a
>>>> timeline (often over looked by coders new to flash) and are not
>>>> dynamic... that is to say traditionally flash coders sometimes use
>>>> MovieClip's and then optimize to Sprites.  With MovieClips you can add
>>>> variables and methods to instances directly and haXe will not type
>>>> check, this makes them easier to prototype and easier to treat a set
>>>> of different objects the same - if they happen to all be cast as
>>>> MovieClips, sprites have a slightly lower overhead but for rapid
>>>> development, MovieClips are worth using, and I often find if you are
>>>> using both it can be simpler to just use MovieClips and only optimize
>>>> if needed.
>>>>
>>>> Cheers ;j
>>>>
>>>>
>>>
>>>
>>> On 24 Nov 2009, at 02:50, Richard Stranberg wrote:
>>>
>>>> Hi Gershon,
>>>>
>>>> I agree with you 100% -  games should be as much fun to play as they
>>>> are to
>>>> write!
>>>>
>>>> When I think of Sprites, I think of the old Commodore 64 days, when
>>>> you had
>>>> 8 hardware sprites that you could program.  I just feel like after
>>>> browsing
>>>> through the mail messages a lot, that there were several ways to move
>>>> graphics and sprites didn't seem to be on the top of the list.
>>>> Also, I feel
>>>> like I've read that animating sprites is difficult as well.    The
>>>> information that you and Joacim have provided is very valuable.
>>>> Again, I
>>>> don't know why there was this big disconnect in my head for not
>>>> considering
>>>> the AS3 APIs.  I guess I was just thinking of Java or something
>>>> where the
>>>> stuff is right there; you just have to import it.
>>>>
>>>> Rick
>>>>
>>>>> 2D Games have been with us for about 3 decades, so most of the things
>>>> you've
>>>>> mentioned have already been named in the "jargon"...
>>>>> "Graphically moving about", can range from "jumping" from tile to
>>>>> tile on
>>>>> the screen, in constant gird-sized steps, to "simple" movement
>>>> (sprite.x++),
>>>>> and complex parametric physical simulations, using floating-point
>>>>> values
>>>> and
>>>>> sub-pixel rendering...
>>>>>
>>>>> Sprite in the old (non-flash) sense, usually meant you'd have a so
>>>>> called
>>>>> "Sprite-sheet" (http://www.freewebs.com/hadouken_dude/DBZvegetassj2.gif
>>>>> ),
>>>>> from which parts would be cropped in accordance to a specific
>>>>> action \
>>>>> frame, those are just bitmaps.
>>>>>
>>>>> Sprite in flash's sense (which i'm guessing is the platform we're
>>>>> talking
>>>>> about) is a much more generic thing, which does'nt necessarily
>>>>> contain
>>>> color
>>>>> bits,  but can also hold parametric curves ("Vectors" in designer's
>>>> jargon)
>>>>> and surfaces.
>>>>>
>>>>> Regarding (3), there's more than one way to go about this, the
>>>>> simplest
>>>>> being "Tile-Based", found in most "Side-Scrolling Platforms" (mario
>>>>> clones
>>>>> :)), much like you've said, usually a 2D int array is used
>>>>> (Array<Array<Int>>) where the indices specify offset from the top
>>>>> left,
>>>> and
>>>>> the value an offset in a sprite-sheet:
>>>>> 00000000000
>>>>> 00000000010
>>>>> 00100001110
>>>>> 22222222222
>>>>>
>>>>> Tile sized is costant, usually 2^n, 32x32, 64x64... Values can be,
>>>>> 0 -
>>>> Sky,
>>>>> 1 - Rock, 2 - Ground...
>>>>> The simplest form of collision detection is called "Bounding-Box
>>>>> Collision
>>>>> Detection", and is still used as a primary stage to minimize cpu
>>>>> cycles
>>>> when
>>>>> doing more complex "Pixel-Perfect Collision Detection".
>>>>>
>>>>> One last thing i'd like to mention, regards AI, "Pathfinding" is
>>>>> used when
>>>>> the baddie chases the player (http://lib.haxe.org/p/aPath for haxe is
>>>>> sweet), "Line-of-Sight" is when those nasties shoot at you :)
>>>>>
>>>>> Best of luck, and remember than writing the thing should be at
>>>>> least as
>>>> fun
>>>>> as playing it.
>>>>>
>>>>>
>>>>> On Mon, Nov 23, 2009 at 1:34 AM, Richard Stranberg
>>>> <[hidden email]
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Thanks a lot, Joacim!  That's exactly what I was looking for.  I
>>>>>> was over
>>>>>> at
>>>>>> Nicolas's blog yesterday looking at PhysaXe.  Pretty impressive!
>>>>>> I think
>>>>>> I'm starting to get the big picture in this now.  For a while I
>>>>>> had a big
>>>>>> "disconnect" in my head.  I didn't understand why people would
>>>>>> refer to
>>>> the
>>>>>> adobe AS3 (or whichever) API documentation; I always thought that
>>>>>> "haXe
>>>> is
>>>>>> it's own language, where are its' APIs?"  I don't know why it took
>>>>>> me so
>>>>>> long to understand that just like any language, you have the
>>>>>> language
>>>>>> itself
>>>>>> that you develop in and the API's to the machine that you're
>>>>>> working on -
>>>>>> in
>>>>>> this case Adobe's Flash engine.  I just don't do this enough...!
>>>>>>
>>>>>> Thanks again!
>>>>>>
>>>>>> Rick
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Rick,
>>>>>>
>>>>>> When you deal with graphics in flash, pretty much everything will
>>>>>> be a
>>>>>> Sprite object, or something else derived from the DisplayObject
>>>>>> class. Of
>>>>>> course, you could write your own graphics engine that render to a
>>>>>> BitmapData
>>>>>> instance for more specialized graphics. But in most cases using the
>>>>>> built-in
>>>>>> Sprite class will do just fine.
>>>>>>
>>>>>> If you need advanced animation, such as animating the limbs of your
>>>>>> character etc, you can do that in the flash authoring app and
>>>>>> import the
>>>>>> swf
>>>>>> using --swf-lib in the hxml file. Then you can use the library
>>>>>> from that
>>>>>> swf
>>>>>> like so: mcFromFlash:MovieClip =
>>>> flash.Lib.attach("NameOfObjectInLibrary");
>>>>>>
>>>>>> Moving Sprites around and doing hit testing is easy since this is
>>>>>> also
>>>>>> built
>>>>>> in. If you only have a few moving objects, simply doing
>>>>>> "mySprite.hitTestPoint(x, y, true);" will work for pixel perfect
>>>> collision
>>>>>> detection. Then you can have all your walls and non-walk-through
>>>>>> stuff in
>>>> a
>>>>>> single Sprite, and hit test against that sprite. Check out the
>>>>>> documentation
>>>>>> for the Sprite class:
>>>>>>
>>>>>>
>>>>
>>> http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/Spri
>>>>>>
>>>>
>>> te.html<http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/disp
>>>> lay/Spri%0Ate.html>
>>>>>>
>>>>>> An other way of animating your world and achieving collision
>>>>>> detection is
>>>>>> to
>>>>>> use a physics lib such as Box2D or PhysaXe. PhysaXe is really fast
>>>>>> if you
>>>>>> only need collision detection. Box2D is slower, but has more
>>>>>> features and
>>>>>> is
>>>>>> better documented. The downside of this approach is that
>>>>>> everything in
>>>> your
>>>>>> world needs to be a polygon. Google these for more info.
>>>>>>
>>>>>> /J
>>>>>>
>>>>>> On 22 nov 2009, at 06:24, Richard Stranberg wrote:
>>>>>>
>>>>>>> Hello Everyone,
>>>>>>>
>>>>>>> I have a couple of newb questions.
>>>>>>>
>>>>>>> I'm interested in developing a 2D games in haxe that have a lot of
>>>>>> objects
>>>>>>> in them.  Most of them are stationary but some will move and be
>>>> animated.
>>>>>> I
>>>>>>> guess what I want to know is:
>>>>>>>
>>>>>>> 1)  What's the best way to move graphics around?  I've seen a lot
>>>>>>> of
>>>>>> things
>>>>>>> about sprites and even some code examples, but then I've also
>>>>>>> read that
>>>>>> it's
>>>>>>> hard to animate sprites.
>>>>>>>
>>>>>>> Also, when I move characters around the screen, there'll be a lot
>>>>>>> of
>>>>>>> stationary objects.
>>>>>>> 2)  Should these be sprties also?  Or simply bitmaps?  Or something
>>>> else?
>>>>>>>
>>>>>>> And finally, collision detection,
>>>>>>> 3)  I would like to navigate my character through a path with
>>>>>>> walls and
>>>>>> not
>>>>>>> being able to go through the walls.  Do I just make the walls
>>>>>>> separate
>>>>>>> objects, create a coarse array that will contain whether a wall
>>>>>>> object
>>>>>>> exists there or not and check the x and y coordiantes of my
>>>>>>> character
>>>>>> when
>>>>>>> it comes close to a corresponding wall object within that
>>>>>>> particular
>>>> part
>>>>>> of
>>>>>>> the array?  Or is there a better way?
>>>>>>>
>>>>>>> Thanks a lot for answering my newb questions.
>>>>>>> Rick
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> haXe - an open source web programming language
>>>>>>> http://haxe.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> haXe - an open source web programming language
>>>>>> http://haxe.org
>>>>>>
>>>>>> -------------- next part --------------
>>>>>> An HTML attachment was scrubbed...
>>>>>> URL:
>>>>
>>> http://lists.motion-twin.com/pipermail/haxe/attachments/20091123/36e6207a/at
>>>> tachment-0001.htm
>>>>
>>>>> ------------------------------
>>>>
>>>>
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>>
>>>
>>
>> --
>> -Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
>> -          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
>> -         ( >__< )  ----------------------------------------
>> -         ^^^  ^^^  (   Netwerken, Security, Open Source   )
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>

--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

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