 I can bumb up this figure to 30.000 if you wish, the app can easily handle that without dropping below the 50fps mark.
 I can bumb up this figure to 30.000 if you wish, the app can easily handle that without dropping below the 50fps mark. 
 Is 3000+ sprites normal? :)
Is 3000+ sprites normal? :) I can bumb up this figure to 30.000 if you wish, the app can easily handle that without dropping below the 50fps mark.
 I can bumb up this figure to 30.000 if you wish, the app can easily handle that without dropping below the 50fps mark. 




 on this board for quite some time.<br><br>BTW, let me take a guess @ the 3000 sprite puzzle: sprite routines w/ ARM asm?
 on this board for quite some time.<br><br>BTW, let me take a guess @ the 3000 sprite puzzle: sprite routines w/ ARM asm? I'll try to write the tutorial on Monday. Apparently no one is going to guess how this works.
 I'll try to write the tutorial on Monday. Apparently no one is going to guess how this works.  You'll hate me so much once I tell you how it's done.
 You'll hate me so much once I tell you how it's done.
 <br></div>
<br></div>
 <br>Here's the trick: Basically, you're watching a flipbook with eight pages. Each page is initially empty, but I use the first 8 frames to draw one sprite on each of them, each time on a slightly different position. Flipping these 8 pages makes the 'sprite' move, without the need to actually draw the thing. When I run out of my 8 pages, I return to page one. This page contains already one sprite, at it's initial position. Now I draw a second sprite. During frame 10 - 16 I add a sprite to page 2 - 8, so that each page contains two srpites, and flipping these pages makes it look like I'm now moving two sprites.<br><br>I hope you get the idea by now. In sprites unlimited, sprites are drawn along a fixed trajectory (wave spiral (circle with slowly decreasing radius, radius is multiplied by a sine to get the waves)) and a second plain spiral path. That's all.<br><br>So, sorry Carp, you can't use this in Argentum. It's just a trick.<br><br>Anyway. I'll try to explain it better in tutorial six.
<br>Here's the trick: Basically, you're watching a flipbook with eight pages. Each page is initially empty, but I use the first 8 frames to draw one sprite on each of them, each time on a slightly different position. Flipping these 8 pages makes the 'sprite' move, without the need to actually draw the thing. When I run out of my 8 pages, I return to page one. This page contains already one sprite, at it's initial position. Now I draw a second sprite. During frame 10 - 16 I add a sprite to page 2 - 8, so that each page contains two srpites, and flipping these pages makes it look like I'm now moving two sprites.<br><br>I hope you get the idea by now. In sprites unlimited, sprites are drawn along a fixed trajectory (wave spiral (circle with slowly decreasing radius, radius is multiplied by a sine to get the waves)) and a second plain spiral path. That's all.<br><br>So, sorry Carp, you can't use this in Argentum. It's just a trick.<br><br>Anyway. I'll try to explain it better in tutorial six.  <br><br>Have a nice weekend,<br><br>- Jacco.<br>
<br><br>Have a nice weekend,<br><br>- Jacco.<br>
 <br><br>I managed to get a bit over 1500 alpha blended sprites per frame at 50hz using C code on my iPaq.  My test sprite was a anti-aliased filled circle that fit inside an 8x8 pixel rectangle (r = 4 pixels).  I think your demo used something similar but it was hard to tell since I couldn't stop the animation in your demo.  This number also includes having to copy a 240x320 backbuffer to the front buffer each frame, but there's nothing else going on (no positioning logic) - just blits and flips.<br><br>Still, 1500 per frame is pretty good for a handheld device and would make a nice particle animation demo.  If you don't need alpha blending the number jumps to 3800 at 50hz.  Now THAT is sassy.<br><br>I also made an attempt at hand-coding a compiled sprite, but since the majority of pixels are opaque within the 8x8 rect, there wasn't a perf win.<br><br>BTW, the Playstation 2 claims 18.75 million 8x8 pixel sprites per second.  That's 100 times what I'm getting on my iPaq.<br><br><br><br>
<br><br>I managed to get a bit over 1500 alpha blended sprites per frame at 50hz using C code on my iPaq.  My test sprite was a anti-aliased filled circle that fit inside an 8x8 pixel rectangle (r = 4 pixels).  I think your demo used something similar but it was hard to tell since I couldn't stop the animation in your demo.  This number also includes having to copy a 240x320 backbuffer to the front buffer each frame, but there's nothing else going on (no positioning logic) - just blits and flips.<br><br>Still, 1500 per frame is pretty good for a handheld device and would make a nice particle animation demo.  If you don't need alpha blending the number jumps to 3800 at 50hz.  Now THAT is sassy.<br><br>I also made an attempt at hand-coding a compiled sprite, but since the majority of pixels are opaque within the 8x8 rect, there wasn't a perf win.<br><br>BTW, the Playstation 2 claims 18.75 million 8x8 pixel sprites per second.  That's 100 times what I'm getting on my iPaq.<br><br><br><br> <br><br>BTW, now that every PPC will have an ARM in the near future, it's time we dive in some serious ASM people...
<br><br>BTW, now that every PPC will have an ARM in the near future, it's time we dive in some serious ASM people...  I'm going to do GBA coding for my boss, so I'll build some ARM knowledge while I'm at the office. Lucky me.
 I'm going to do GBA coding for my boss, so I'll build some ARM knowledge while I'm at the office. Lucky me.
