# NME rotation best practices

33 messages
12
Open this post in threaded view
|

## NME rotation best practices

 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.
Open this post in threaded view
|

## Re: NME rotation best practices

 You could also use the transform matrix.Ben On Tue, Oct 11, 2011 at 12:03 PM, alexbor 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
Open this post in threaded view
|

## Re: NME rotation best practices

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

## Re: NME rotation best practices

 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.
Open this post in threaded view
|

## Re: NME rotation best practices

 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)?
Open this post in threaded view
|

## Re: NME rotation best practices

 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?
Open this post in threaded view
|

## Re: NME rotation best practices

 Can you provide the source for those of us interested alex?On 12 October 2011 13:26, alexbor 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 Cannhttp://www.mikecann.co.uk/@mikeysee -- haXe - an open source web programming language http://haxe.org
Open this post in threaded view
|

## Re: NME rotation best practices

 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 -- 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.
Open this post in threaded view
|

## Re: NME rotation best practices

 Sure mail me now if you want ;)On 12 October 2011 15:02, alexbor wrote: Michael Cann wrote: > > Can you provide the source for those of us interested alex? > > On 12 October 2011 13:26, alexbor <alexbormail@> 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. -- 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 Cannhttp://www.mikecann.co.uk/@mikeysee -- haXe - an open source web programming language http://haxe.org
Open this post in threaded view
|

## Re: NME rotation best practices

 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).
Open this post in threaded view
|

## Re: NME rotation best practices

 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
Open this post in threaded view
|

## Re: NME rotation best practices

 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
Open this post in threaded view
|

## Re: NME rotation best practices

 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
Open this post in threaded view
|

## Re: NME rotation best practices

 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.
Open this post in threaded view
|

## Re: NME rotation best practices

 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
Open this post in threaded view
|

## Re: NME rotation best practices

 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. :)
Open this post in threaded view
|

## Re: NME rotation best practices

 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 Pixelhttp://www.touchmypixel.com/phone: +61 3 8060 5321 _______________________ On Thu, Oct 13, 2011 at 5:22 PM, alexbor 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
Open this post in threaded view
|

## Re: NME rotation best practices

 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.
Open this post in threaded view
|

## Re: NME rotation best practices

 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 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: +61 3 8060 5321 > _______________________ > > > On Thu, Oct 13, 2011 at 5:22 PM, alexbor <alexbormail@> 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 Cannhttp://www.mikecann.co.uk/@mikeysee -- haXe - an open source web programming language http://haxe.org