NME rotation best practices

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

NME rotation best practices

alexbor
Hi, List.

I'm porting a flash game to iPhone for the first time and would like to ask you guys, how do you rotate images?

There are 3 ways to implement rotation that come to my mind:

1. Changing rotation property of a vector image;
2. Doing the same with a bitmap;
3. Creating a tilesheet with prerendered rotated states of an image.

Rotating vectors is inacceptable due to low performance, rotating bitmaps is much faster. Using tilesheets to render game scene gives the best performance, but it may require a lot of memory, since you will have to generate a huge tilesheet for each rotatable game object.

What technic do you use? And how do you think is it possible that generating a lot of huge tilesheets may lead to problems?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

bubblebenj
You could also use the transform matrix.

Ben

On Tue, Oct 11, 2011 at 12:03 PM, alexbor <[hidden email]> wrote:
Hi, List.

I'm porting a flash game to iPhone for the first time and would like to ask
you guys, how do you rotate images?

There are 3 ways to implement rotation that come to my mind:

1. Changing rotation property of a vector image;
2. Doing the same with a bitmap;
3. Creating a tilesheet with prerendered rotated states of an image.

Rotating vectors is inacceptable due to low performance, rotating bitmaps is
much faster. Using tilesheets to render game scene gives the best
performance, but it may require a lot of memory, since you will have to
generate a huge tilesheet for each rotatable game object.

What technic do you use? And how do you think is it possible that generating
a lot of huge tilesheets may lead to problems?

Thanks.

--
View this message in context: http://haxe.1354130.n2.nabble.com/NME-rotation-best-practices-tp6880337p6880337.html
Sent from the Haxe mailing list archive at Nabble.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: NME rotation best practices

alexbor
Does using matrix improve performance in nme?
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

Missile Mike
First of all, if you plan to have your app run on the iPhone 3g, you HAVE to use sprite sheets, because each texture switch incurs a penalty.  But here's the problem with rotation using sprite sheets in NME: the clipping rectangle is set on the destination surface, so you will see pieces of the adjacent images on your sprite sheet when doing rotation.

To get around it, I use a sprite sheet with drawtriangles() instead, works well- it's just a little more complicated.
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

alexbor
Missile Mike wrote
First of all, if you plan to have your app run on the iPhone 3g, you HAVE to use sprite sheets, because each texture switch incurs a penalty.  But here's the problem with rotation using sprite sheets in NME: the clipping rectangle is set on the destination surface, so you will see pieces of the adjacent images on your sprite sheet when doing rotation.

To get around it, I use a sprite sheet with drawtriangles() instead, works well- it's just a little more complicated.
Thanks for the advice. I sorted out how to use drawTriangles method, but it is not quite clear how to use it with tilesheets.

As far as I understand workflow is following:
1. create BitmapData;
2. create Tilesheet with this BitmapData (to transfer image bytes into GPU memory);
3. call beginBitmapFill() passing BitmapData as a parameter (shouldn't be transferred to GPU since it's already there);
4. call drawTriangles()
5. call endFill()

Am I right (especially regarding image uploads to GPU)?
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

alexbor
alexbor wrote
Missile Mike wrote
First of all, if you plan to have your app run on the iPhone 3g, you HAVE to use sprite sheets, because each texture switch incurs a penalty.  But here's the problem with rotation using sprite sheets in NME: the clipping rectangle is set on the destination surface, so you will see pieces of the adjacent images on your sprite sheet when doing rotation.

To get around it, I use a sprite sheet with drawtriangles() instead, works well- it's just a little more complicated.
Thanks for the advice. I sorted out how to use drawTriangles method, but it is not quite clear how to use it with tilesheets.

As far as I understand workflow is following:
1. create BitmapData;
2. create Tilesheet with this BitmapData (to transfer image bytes into GPU memory);
3. call beginBitmapFill() passing BitmapData as a parameter (shouldn't be transferred to GPU since it's already there);
4. call drawTriangles()
5. call endFill()

Am I right (especially regarding image uploads to GPU)?
Well, due to tests results I'm wrong. :) Creating tilesheet doesn't influence performance at all. I created a test app rotating 100 images and using drawTriangles() shows the same FPS as changing rotation property of Bitmaps. Performance is improved if beginBitmapFill() smooth parameter is set to false, but quality is inacceptable.

Mike, did you mean something else?
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

Michael Cann
Can you provide the source for those of us interested alex?

On 12 October 2011 13:26, alexbor <[hidden email]> wrote:

alexbor wrote:
>
>
> Missile Mike wrote:
>>
>> First of all, if you plan to have your app run on the iPhone 3g, you HAVE
>> to use sprite sheets, because each texture switch incurs a penalty.  But
>> here's the problem with rotation using sprite sheets in NME: the clipping
>> rectangle is set on the destination surface, so you will see pieces of
>> the adjacent images on your sprite sheet when doing rotation.
>>
>> To get around it, I use a sprite sheet with drawtriangles() instead,
>> works well- it's just a little more complicated.
>>
>
> Thanks for the advice. I sorted out how to use drawTriangles method, but
> it is not quite clear how to use it with tilesheets.
>
> As far as I understand workflow is following:
> 1. create BitmapData;
> 2. create Tilesheet with this BitmapData (to transfer image bytes into GPU
> memory);
> 3. call beginBitmapFill() passing BitmapData as a parameter (shouldn't be
> transferred to GPU since it's already there);
> 4. call drawTriangles()
> 5. call endFill()
>
> Am I right (especially regarding image uploads to GPU)?
>

Well, due to tests results I'm wrong. :) Creating tilesheet doesn't
influence performance at all. I created a test app rotating 100 images and
using drawTriangles() shows the same FPS as changing rotation property of
Bitmaps. Performance is improved if beginBitmapFill() smooth parameter is
set to false, but quality is inacceptable.

Mike, did you mean something else?


--
View this message in context: http://haxe.1354130.n2.nabble.com/NME-rotation-best-practices-tp6880337p6884771.html
Sent from the Haxe mailing list archive at Nabble.com.

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



--
Mike Cann
http://www.mikecann.co.uk/


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

Re: NME rotation best practices

alexbor
Michael Cann wrote
Can you provide the source for those of us interested alex?

On 12 October 2011 13:26, alexbor <[hidden email]> wrote:

>
> alexbor wrote:
> >
> >
> > Missile Mike wrote:
> >>
> >> First of all, if you plan to have your app run on the iPhone 3g, you
> HAVE
> >> to use sprite sheets, because each texture switch incurs a penalty.  But
> >> here's the problem with rotation using sprite sheets in NME: the
> clipping
> >> rectangle is set on the destination surface, so you will see pieces of
> >> the adjacent images on your sprite sheet when doing rotation.
> >>
> >> To get around it, I use a sprite sheet with drawtriangles() instead,
> >> works well- it's just a little more complicated.
> >>
> >
> > Thanks for the advice. I sorted out how to use drawTriangles method, but
> > it is not quite clear how to use it with tilesheets.
> >
> > As far as I understand workflow is following:
> > 1. create BitmapData;
> > 2. create Tilesheet with this BitmapData (to transfer image bytes into
> GPU
> > memory);
> > 3. call beginBitmapFill() passing BitmapData as a parameter (shouldn't be
> > transferred to GPU since it's already there);
> > 4. call drawTriangles()
> > 5. call endFill()
> >
> > Am I right (especially regarding image uploads to GPU)?
> >
>
> Well, due to tests results I'm wrong. :) Creating tilesheet doesn't
> influence performance at all. I created a test app rotating 100 images and
> using drawTriangles() shows the same FPS as changing rotation property of
> Bitmaps. Performance is improved if beginBitmapFill() smooth parameter is
> set to false, but quality is inacceptable.
>
> Mike, did you mean something else?
>
>
> --
> View this message in context:
> http://haxe.1354130.n2.nabble.com/NME-rotation-best-practices-tp6880337p6884771.html
> Sent from the Haxe mailing list archive at Nabble.com.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
*Mike Cann*
http://www.mikecann.co.uk/
@mikeysee <http://www.twitter.com/mikeysee>

--
haXe - an open source web programming language
http://haxe.org
No problem, I just want to wait for answer regarding using of drawTriangles with Tilesheets. If it is possible then it will be the most interesting part of the code. :)

Currently I have a project testing rotation using:
1. vector graphics with software/hardware rendering,
2. Bitmaps,
3. Tilesheets,
4. drawTriangles method without using of Tilesheets.

I can mail you unfinished project if you like.
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

Michael Cann
Sure mail me now if you want ;)

On 12 October 2011 15:02, alexbor <[hidden email]> wrote:

Michael Cann wrote:
>
> Can you provide the source for those of us interested alex?
>
> On 12 October 2011 13:26, alexbor &lt;alexbormail@&gt; wrote:
>
>>
>> alexbor wrote:
>> >
>> >
>> > Missile Mike wrote:
>> >>
>> >> First of all, if you plan to have your app run on the iPhone 3g, you
>> HAVE
>> >> to use sprite sheets, because each texture switch incurs a penalty.
>> But
>> >> here's the problem with rotation using sprite sheets in NME: the
>> clipping
>> >> rectangle is set on the destination surface, so you will see pieces of
>> >> the adjacent images on your sprite sheet when doing rotation.
>> >>
>> >> To get around it, I use a sprite sheet with drawtriangles() instead,
>> >> works well- it's just a little more complicated.
>> >>
>> >
>> > Thanks for the advice. I sorted out how to use drawTriangles method,
>> but
>> > it is not quite clear how to use it with tilesheets.
>> >
>> > As far as I understand workflow is following:
>> > 1. create BitmapData;
>> > 2. create Tilesheet with this BitmapData (to transfer image bytes into
>> GPU
>> > memory);
>> > 3. call beginBitmapFill() passing BitmapData as a parameter (shouldn't
>> be
>> > transferred to GPU since it's already there);
>> > 4. call drawTriangles()
>> > 5. call endFill()
>> >
>> > Am I right (especially regarding image uploads to GPU)?
>> >
>>
>> Well, due to tests results I'm wrong. :) Creating tilesheet doesn't
>> influence performance at all. I created a test app rotating 100 images
>> and
>> using drawTriangles() shows the same FPS as changing rotation property of
>> Bitmaps. Performance is improved if beginBitmapFill() smooth parameter is
>> set to false, but quality is inacceptable.
>>
>> Mike, did you mean something else?
>>
>>
>> --
>> View this message in context:
>> http://haxe.1354130.n2.nabble.com/NME-rotation-best-practices-tp6880337p6884771.html
>> Sent from the Haxe mailing list archive at Nabble.com.
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
>
>
> --
> *Mike Cann*
> http://www.mikecann.co.uk/
> @mikeysee &lt;http://www.twitter.com/mikeysee&gt;
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

No problem, I just want to wait for answer regarding using of drawTriangles
with Tilesheets. If it is possible then it will be the most interesting part
of the code. :)

Currently I have a project testing rotation using:
1. vector graphics with software/hardware rendering,
2. Bitmaps,
3. Tilesheets,
4. drawTriangles method without using of Tilesheets.

I can mail you unfinished project if you like.

--
View this message in context: http://haxe.1354130.n2.nabble.com/NME-rotation-best-practices-tp6880337p6885123.html
Sent from the Haxe mailing list archive at Nabble.com.

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



--
Mike Cann
http://www.mikecann.co.uk/


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

Re: NME rotation best practices

Chman
In reply to this post by alexbor
alexbor wrote
No problem, I just want to wait for answer regarding using of drawTriangles with Tilesheets. If it is possible then it will be the most interesting part of the code. :)

Currently I have a project testing rotation using:
1. vector graphics with software/hardware rendering,
2. Bitmaps,
3. Tilesheets,
4. drawTriangles method without using of Tilesheets.

I can mail you unfinished project if you like.
I would be very interested in this as well, as I'm working on iOS too and I'm looking for the most efficient way to draw sprites and still be able to rotate them.

Right now I'm using Bitmaps with shared BitmapData reference (when possible) as they are the most convenient to use and I can literally spawn HUNDREDS of them (with rotation and random alpha values) at 60fps, but I only have an iPad 2 to test on, so I'm not sure about the performances on other devices (mainly iPhone 3GS+ and iPad 1, to be honest I don't really care about the 2G and 3G anymore).
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

Gamehaxe
If you are happy to rotate the bitmap (rather than the vectors),
I was thinking of adding optional scale, rotation and maybe color
to the inXYID array of Graphics.drawTiles.
This would make a pretty simple API.

Hugh


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

Re: NME rotation best practices

Chman
Gamehaxe wrote
If you are happy to rotate the bitmap (rather than the vectors),
I was thinking of adding optional scale, rotation and maybe color
to the inXYID array of Graphics.drawTiles.
This would make a pretty simple API.
This would be great, but how would you handle the reference point for rotations and scales (top left corner, center, arbitrary point) ?

Also, quick question about the magical drawTiles function : I understand it's great for batch rendering of many sprites sharing the same tilesheet (particles, tilemaps etc), but is it smart enough to detect when the same tilesheet is used consecutively and do only one texture binding on the GPU ? Or does it do the binding anyway ?

If it's not clear, consider the following code :

graphic.drawTiles(tilesheet1, ...); // Line 1
graphic.drawTiles(tilesheet1, ...); // Line 2
graphic.drawTiles(tilesheet2, ...); // Line 3

Is there a texture switch between line 1 and 2 ?

- Tom
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

Gamehaxe
Hi,

> This would be great, but how would you handle the reference point for
> rotations and scales (top left corner, center, arbitrary point) ?

Tiles already have a "hot spot" co-ordinate defined.

>
> Also, quick question about the magical drawTiles function : I understand
> it's great for batch rendering of many sprites sharing the same tilesheet
> (particles, tilemaps etc), but is it smart enough to detect when the same
> tilesheet is used consecutively and do only one texture binding on the  
> GPU ?
> Or does it do the binding anyway ?

I think it binds anyway, but in opengl binding to the same texture should
be free - I may even have some explicit caching in there - can't quite
remember.

Hugh

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

Re: NME rotation best practices

alexbor
In reply to this post by Gamehaxe
Gamehaxe wrote
If you are happy to rotate the bitmap (rather than the vectors),
I was thinking of adding optional scale, rotation and maybe color
to the inXYID array of Graphics.drawTiles.
This would make a pretty simple API.
I agree to Chman, rotation and scale would be great.
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

Michael Baczynski-2
In reply to this post by Gamehaxe
great idea!

On 12.10.2011 17:24, Gamehaxe wrote:
> If you are happy to rotate the bitmap (rather than the vectors),
> I was thinking of adding optional scale, rotation and maybe color
> to the inXYID array of Graphics.drawTiles.
> This would make a pretty simple API.
>
> Hugh
>
>


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

Re: NME rotation best practices

alexbor
In reply to this post by Chman

For everyone who is interested in tests.

Here: http://dl.dropbox.com/u/41785156/rotation-test.zip you may download the project.

It's a flash develop project with the following tests:
1. Rotation of bitmaps added to stage by changing rotation property;
2. Rotation using tilesheet with prerendered rotated states of an image (one per degree, 360 in total);
3. The same as previous but instead of using one huge tilesheet, separate tilesheet is created for every state (360 tilesheets in total);
4. Rotation using drawTriangles method with beginBitmapFill (WITHOUT smoothing);
5. The same as previous but WITH smoothing;
6. Rotation of vector images added to stage by changing rotation property;
7. The same as previous but with anti-aliasing (software rendering).

Results for IPhone 3GS (rotation of 300 images with 60 fps set):
1. Bitmaps on stage - 25 fps;
2. Huge tilesheet - 44 fps;
3. Many tilesheets - 47 fps;
4. drawTriangles - 43 fps;
5. drawTriangles with smoothing - 40 fps;
6. Vector images on stage - 30 fps;
7. Vector images on stage (anti-aliasing) - 1 fps.

Results for windows, 4GB DDR2, Intel Core i3, ATI Mobility Radeon HD 5650 (rotation of 5000 images with 60 fps set):
1. Bitmaps on stage - 41 fps;
2. Huge tilesheet - 60 fps;
3. Many tilesheets - 60 fps;
4. drawTriangles - 55 fps;
5. drawTriangles with smoothing - 55 fps;
6. Vector images on stage - 25 fps;
7. Vector images on stage (anti-aliasing) - 1 fps.

So, using tilesheets gives the best performance (and quality!), but there is a problem. To get smooth rotation you have to create huge (or many) tilesheets.

I created another app (http://dl.dropbox.com/u/41785156/memory-test.zip) to test how many tilesheets can be created. App creates many tilesheets with 100x100 images. On windows test crashes when creating more than 361000 (360 x 100) tilesheets, on iphone with more than 36100 (360 x 10). It means that on IPhone 3GS you can create only 10 rotatable game objects using tilesheet rotation.

So the best choise currently is to use drawTriangles() with smoothing (both quality and performance are acceptable).

That’s it. :)
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

Tarwin Stroh-Spijer
360 degrees of rotation may be overkill. If you need blazingly fast speed and rotation why not try simply 8, or 16 rotations? At 16 rotations things will look pretty good, except when rotating slowly.

Come to think of it (and I just had a look at a video) Sonic on the Genesis only had a few rotations and I never noticed it until just then!

Regards,


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Thu, Oct 13, 2011 at 5:22 PM, alexbor <[hidden email]> wrote:

For everyone who is interested in tests.

Here: http://dl.dropbox.com/u/41785156/rotation-test.zip you may download
the project.

It's a flash develop project with the following tests:
1. Rotation of bitmaps added to stage by changing rotation property;
2. Rotation using tilesheet with prerendered rotated states of an image (one
per degree, 360 in total);
3. The same as previous but instead of using one huge tilesheet, separate
tilesheet is created for every state (360 tilesheets in total);
4. Rotation using drawTriangles method with beginBitmapFill (WITHOUT
smoothing);
5. The same as previous but WITH smoothing;
6. Rotation of vector images added to stage by changing rotation property;
7. The same as previous but with anti-aliasing (software rendering).

Results for IPhone 3GS (rotation of 300 images with 60 fps set):
1. Bitmaps on stage -                                                   25 fps;
2. Huge tilesheet -                                                     44 fps;
3. Many tilesheets -                                                    47 fps;
4. drawTriangles -                                                              43 fps;
5. drawTriangles with smoothing -                               40 fps;
6. Vector images on stage -                                     30 fps;
7. Vector images on stage (anti-aliasing) -     1 fps.

Results for windows, 4GB DDR2, Intel Core i3, ATI Mobility Radeon HD 5650
(rotation of 5000 images with 60 fps set):
1. Bitmaps on stage -                                                   41 fps;
2. Huge tilesheet -                                                     60 fps;
3. Many tilesheets -                                                    60 fps;
4. drawTriangles -                                                              55 fps;
5. drawTriangles with smoothing -                               55 fps;
6. Vector images on stage -                                     25 fps;
7. Vector images on stage (anti-aliasing) -     1 fps.

So, using tilesheets gives the best performance (and quality!), but there is
a problem. To get smooth rotation you have to create huge (or many)
tilesheets.

I created another app (http://dl.dropbox.com/u/41785156/memory-test.zip) to
test how many tilesheets can be created. App creates many tilesheets with
100x100 images. On windows test crashes when creating more than 361000 (360
x 100) tilesheets, on iphone with more than 36100 (360 x 10). It means that
on IPhone 3GS you can create only 10 rotatable game objects using tilesheet
rotation.

So the best choise currently is to use drawTriangles() with smoothing (both
quality and performance are acceptable).

That’s it. :)


--
View this message in context: http://haxe.1354130.n2.nabble.com/NME-rotation-best-practices-tp6880337p6887790.html
Sent from the Haxe mailing list archive at Nabble.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: NME rotation best practices

alexbor
Tarwin Stroh-Spijer wrote
360 degrees of rotation may be overkill. If you need blazingly fast speed
and rotation why not try simply 8, or 16 rotations? At 16 rotations things
will look pretty good, except when rotating slowly.

Come to think of it (and I just had a look at a video) Sonic on the Genesis
only had a few rotations and I never noticed it until just then!

Regards,


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Thu, Oct 13, 2011 at 5:22 PM, alexbor <[hidden email]> wrote:

>
> For everyone who is interested in tests.
>
> Here: http://dl.dropbox.com/u/41785156/rotation-test.zip you may download
> the project.
>
> It's a flash develop project with the following tests:
> 1. Rotation of bitmaps added to stage by changing rotation property;
> 2. Rotation using tilesheet with prerendered rotated states of an image
> (one
> per degree, 360 in total);
> 3. The same as previous but instead of using one huge tilesheet, separate
> tilesheet is created for every state (360 tilesheets in total);
> 4. Rotation using drawTriangles method with beginBitmapFill (WITHOUT
> smoothing);
> 5. The same as previous but WITH smoothing;
> 6. Rotation of vector images added to stage by changing rotation property;
> 7. The same as previous but with anti-aliasing (software rendering).
>
> Results for IPhone 3GS (rotation of 300 images with 60 fps set):
> 1. Bitmaps on stage -                                                   25
> fps;
> 2. Huge tilesheet -                                                     44
> fps;
> 3. Many tilesheets -                                                    47
> fps;
> 4. drawTriangles -
>      43 fps;
> 5. drawTriangles with smoothing -                               40 fps;
> 6. Vector images on stage -                                     30 fps;
> 7. Vector images on stage (anti-aliasing) -     1 fps.
>
> Results for windows, 4GB DDR2, Intel Core i3, ATI Mobility Radeon HD 5650
> (rotation of 5000 images with 60 fps set):
> 1. Bitmaps on stage -                                                   41
> fps;
> 2. Huge tilesheet -                                                     60
> fps;
> 3. Many tilesheets -                                                    60
> fps;
> 4. drawTriangles -
>      55 fps;
> 5. drawTriangles with smoothing -                               55 fps;
> 6. Vector images on stage -                                     25 fps;
> 7. Vector images on stage (anti-aliasing) -     1 fps.
>
> So, using tilesheets gives the best performance (and quality!), but there
> is
> a problem. To get smooth rotation you have to create huge (or many)
> tilesheets.
>
> I created another app (http://dl.dropbox.com/u/41785156/memory-test.zip)
> to
> test how many tilesheets can be created. App creates many tilesheets with
> 100x100 images. On windows test crashes when creating more than 361000 (360
> x 100) tilesheets, on iphone with more than 36100 (360 x 10). It means that
> on IPhone 3GS you can create only 10 rotatable game objects using tilesheet
> rotation.
>
> So the best choise currently is to use drawTriangles() with smoothing (both
> quality and performance are acceptable).
>
> That’s it. :)
>
>
> --
> View this message in context:
> http://haxe.1354130.n2.nabble.com/NME-rotation-best-practices-tp6880337p6887790.html
> Sent from the Haxe mailing list archive at Nabble.com.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
I'm porting physics based game, so smooth rotation is a must. For such scenario even 2 degrees step may be inacceptable.
Reply | Threaded
Open this post in threaded view
|

Re: NME rotation best practices

Michael Cann
Wow thanks for that alexor! You should post this on a blog or something. 

Really good to know!

On 13 October 2011 09:34, alexbor <[hidden email]> wrote:

Tarwin Stroh-Spijer wrote:
>
> 360 degrees of rotation may be overkill. If you need blazingly fast speed
> and rotation why not try simply 8, or 16 rotations? At 16 rotations things
> will look pretty good, except when rotating slowly.
>
> Come to think of it (and I just had a look at a video) Sonic on the
> Genesis
> only had a few rotations and I never noticed it until just then!
>
> Regards,
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321">+61 3 8060 5321
> _______________________
>
>
> On Thu, Oct 13, 2011 at 5:22 PM, alexbor &lt;alexbormail@&gt; wrote:
>
>>
>> For everyone who is interested in tests.
>>
>> Here: http://dl.dropbox.com/u/41785156/rotation-test.zip you may download
>> the project.
>>
>> It's a flash develop project with the following tests:
>> 1. Rotation of bitmaps added to stage by changing rotation property;
>> 2. Rotation using tilesheet with prerendered rotated states of an image
>> (one
>> per degree, 360 in total);
>> 3. The same as previous but instead of using one huge tilesheet, separate
>> tilesheet is created for every state (360 tilesheets in total);
>> 4. Rotation using drawTriangles method with beginBitmapFill (WITHOUT
>> smoothing);
>> 5. The same as previous but WITH smoothing;
>> 6. Rotation of vector images added to stage by changing rotation
>> property;
>> 7. The same as previous but with anti-aliasing (software rendering).
>>
>> Results for IPhone 3GS (rotation of 300 images with 60 fps set):
>> 1. Bitmaps on stage -
>> 25
>> fps;
>> 2. Huge tilesheet -
>> 44
>> fps;
>> 3. Many tilesheets -
>> 47
>> fps;
>> 4. drawTriangles -
>>      43 fps;
>> 5. drawTriangles with smoothing -                               40 fps;
>> 6. Vector images on stage -                                     30 fps;
>> 7. Vector images on stage (anti-aliasing) -     1 fps.
>>
>> Results for windows, 4GB DDR2, Intel Core i3, ATI Mobility Radeon HD 5650
>> (rotation of 5000 images with 60 fps set):
>> 1. Bitmaps on stage -
>> 41
>> fps;
>> 2. Huge tilesheet -
>> 60
>> fps;
>> 3. Many tilesheets -
>> 60
>> fps;
>> 4. drawTriangles -
>>      55 fps;
>> 5. drawTriangles with smoothing -                               55 fps;
>> 6. Vector images on stage -                                     25 fps;
>> 7. Vector images on stage (anti-aliasing) -     1 fps.
>>
>> So, using tilesheets gives the best performance (and quality!), but there
>> is
>> a problem. To get smooth rotation you have to create huge (or many)
>> tilesheets.
>>
>> I created another app (http://dl.dropbox.com/u/41785156/memory-test.zip)
>> to
>> test how many tilesheets can be created. App creates many tilesheets with
>> 100x100 images. On windows test crashes when creating more than 361000
>> (360
>> x 100) tilesheets, on iphone with more than 36100 (360 x 10). It means
>> that
>> on IPhone 3GS you can create only 10 rotatable game objects using
>> tilesheet
>> rotation.
>>
>> So the best choise currently is to use drawTriangles() with smoothing
>> (both
>> quality and performance are acceptable).
>>
>> That’s it. :)
>>
>>
>> --
>> View this message in context:
>> http://haxe.1354130.n2.nabble.com/NME-rotation-best-practices-tp6880337p6887790.html
>> Sent from the Haxe mailing list archive at Nabble.com.
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

I'm porting physics based game, so smooth rotation is a must. For such
scenario even 2 degrees step may be inacceptable.

--
View this message in context: http://haxe.1354130.n2.nabble.com/NME-rotation-best-practices-tp6880337p6888094.html
Sent from the Haxe mailing list archive at Nabble.com.

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



--
Mike Cann
http://www.mikecann.co.uk/


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

Re: NME rotation best practices

Gamehaxe
In reply to this post by alexbor
Hi,
If you are after exact vector rotations on bitmaps, you could also  
consider only
doing 0...90, because 90 degree rotations should still maintain
pixel-perfect results.  The BitmapData matrices would be easy to calculate.

Hugh
>
> I'm porting physics based game, so smooth rotation is a must. For such
> scenario even 2 degrees step may be inacceptable.
>

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