Rendering Performance on iOS and Android
Monkey Forums/Monkey Programming/Rendering Performance on iOS and Android
| ||
I think that the rendering performance is a tad slow on both iOS and Android with the generated code from Monkey. For example in Pirate Solitaire on one level I am displaying a background image, 5 GUI sprites, 3 DrawTexts (Level, round and score) and about 40 cards... on my iPod I am getting around 25-28FPS. On another level I am displaying 24 and get 40+FPS. Also with the latest changes to the Android code (the buffer change) I have lost around 10FPS... Any way to improve this? |
| ||
Are you using single images or spritesheet? Do create/load images on the fly or before in the OnCreate event? |
| ||
The GUI sprites are single images, the cards are on a spritesheet. Images are created in the OnCreate event. |
| ||
That sounds indeED weird. I will do some tests too. |
| ||
Hmm I made a shoot'ing game with many bullets but I think the number of bullets on the screen is many more than that (100?) and it doesn't lag at all on iOS and Android. But this was since V32 or something, I haven't tried building V40 on mobile devices yet. Will do some tests and get back to you later. |
| ||
Well both your devices outspec ours :P We have a iPod 2nd Gen with a 620MHz CPU, yours is the 4th Gen with a 1GHz (running at 800MHz) And a LG Optimus One P500 with a 600MHz CPU, your Galaxy S has a 1GHz CPU... |
| ||
Hi, It's impossible to say why you're app's slow without being able to see what it's doing - can you post a demo of some kind? > Also with the latest changes to the Android code (the buffer change) I have lost around 10FPS... Bummer, but that's the 'right' way to do it so it stays. |
| ||
I have around 25-30 fps on my Android HTC Desire HD for my turn-based strategy game where the fps really don't matter. I don't do many stuff inside, just painting the map (one single image) and several units (images as well) on it. I think that's quite normal, you can't expect anything beyond 50 fps I guess. |
| ||
Heres a very basic demo: It creates 82 objects in 4 lists (Ships, Asteroids, Aliens and Cards), on my LG Optimus One I get 26 FPS. Tap the screen to create more objects... 82 objects = 26FPS 102 objects = 22FPS 150 objects = 15FPS 210 objects = 11FPS Code and Media here: http://www.therevillsgames.com/monkey/renderTest/RenderSpeedTest.zip Flash: http://www.therevillsgames.com/monkey/renderTest/flash/ HTML5: http://www.therevillsgames.com/monkey/renderTest/html5/ |
| ||
Nexus One: 82 objects = 42 FPS 102 objects = 39 FPS 150 objects = 32 FPS 210 objects = 27 FPS Motorola Xoom: Frame rates fluctuate a lot. 82 objects = 50-60 FPS 102 objects = 40-55 FPS 150 objects = 30 FPS 210 objects = 30 FPS |
| ||
Hi, I'll have a good look later...but first impressions are that there is a LOT going on there so I wouldn't expect stellar performance. For starters, there is a lot of overdraw and this is a real killer for GLES hardware, which is very fill rate sensitive. Also, the use of alpha disables hardware optimizations that help eliminate this fillrate overhead, and also require an extra backbuffer read per pixel. Not saying there aren't tweaks I can't make (in particular, I'm not thrilled about the use of glMatrix to do tforms - doing it manually would probably be faster) but the hardware has it limits. Also, doesn't your phone use a crazy amount of CPU when idle? Or is that just when touch is used? Either way, it wipes out about 30% of performance from the CPU which is gonna hurt. Anyway, will have a better look at work... |
| ||
My Results:Objs | 82 | 102 | 150 | 210 -----+----+-----+-----+----- GLFW | 59 | 59 | 59 | 59 iPad | 59 | 59 | 54 | 45 iPod | 59 | 59 | 53 | 45 Nook | 30 | 28 | 26 | 23See sig for devices. |
| ||
there is a lot of overdraw Overdraw? Whats overdraw? Or is that just when touch is used? Only when you touch the screen - these FPS were taken without touching the screen. I havent tested this on iOS, with Pirates I get around 30FPS on the device (60FPS in the simulator...) |
| ||
@therevills Overdraw? Whats overdraw? Sprites drawn on top of another sprite. Devices prior to iPad 2 are strictly fillrate limited, so you should keep overdraw to be as few as possible. |
| ||
lol... well that could be one reason Pirate Solitare is slow - Ive got cards on top of cards :/ Also arnt you always going to get that if you display a background image!?!? |
| ||
Thanks Hima I will check that in my game also |
| ||
Some testing results I have just been doing:With a background: ------------------ No Alpha, 52 cards all overlapping = 40 FPS Alpha, 52 cards all overlapping = 39-40 FPS No Alpha, 52 cards none overlapping = 41 FPS Alpha, 52 cards none overlapping = 39-40 FPS No background just CLS: ----------------------- No Alpha, 52 cards all overlapping = 42-44 FPS Alpha, 52 cards all overlapping = 39-44 FPS No Alpha, 52 cards none overlapping = 43-45 FPS Alpha, 52 cards none overlapping = 41-45 FPS So going on these, the overlapping (Sprites drawn on top of another sprite) didnt really hurt the framerate, nor the alpha - main performance increase was when we did not display a background image... |
| ||
I've just been playing with an Android framework called Libgdx: http://code.google.com/p/libgdx/ And created a very similar "game", which only diplays the ships with colour tinting, alpha and rendering on a background. I also changed the Monkey version to do the same. This table shows my results (the left column is the number of objects): | Libgdx | Monkey ----+---------+------ 100 | 55FPS | 22FPS 200 | 40FPS | 12FPS 300 | 25FPS | 8FPS 400 | 20FPS | 5FPS Here is the code for the Libgdx version: And the apk if you would like to test: http://www.therevillsgames.com/monkey/renderTest/libgdx/RenderTest-android.apk The project(s) files: http://www.therevillsgames.com/monkey/renderTest/libgdx/renderTestLibgdx.zip |
| ||
My android numbers (Using the LibGDX *.apk from previous post and Monkey implementation found below):Objs | Monkey | Libgdx ------+--------+-------- 100 | 37-38 | 38 200 | 30-31 | 33-34 300 | 25-26 | 29-30 400 | 20-21 | 26 Monkey Implementation: Import mojo.app Import mojo.input Import mojo.graphics Class Sprite Private Field _image:Image Field _xpos#, _ypos#, _angle# Field _r#, _g#, _b#, _a# Field _speed# Field _dx#, _dy# Method _Move:Void() Local x:= _xpos + _dx Local y:= _ypos + _dy If x < 0 Then x = DeviceWidth If x > DeviceWidth Then x = 0 If y < 0 Then y = DeviceHeight If y > DeviceHeight Then y = 0 _xpos = x _ypos = y End Public Method New( image:Image ) _image = image _r = 255.0 * Rnd _g = 255.0 * Rnd _b = 255.0 * Rnd _a = (255.0 * Rnd) + 0.5 _speed = (4.0 * Rnd) + 1.0 End Method SetPosition:Void( xpos#, ypos# ) _xpos = xpos _ypos = ypos End Method SetRotation:Void( angle# ) _angle = angle End Method Update:Void() _dx = (-Sin(_angle) * _speed) _dy = ( Cos(_angle) * _speed) _Move End Method Render:Void() SetAlpha _a SetColor _r, _g, _b DrawImage _image, _xpos, _ypos, _angle, 1, 1 End End Class RenderTest Extends App Private Field _shipList:List<Sprite> Field _background:Image, _ship:Image Field _frameRate, _frameCount, _frameCountStartTime Method _ShowFPS:Void() _frameCount+=1 If _frameCount >= 30 _frameRate = Int(1000.0 / (Float(Millisecs - _frameCountStartTime)/30.0)) _frameCount = 0 _frameCountStartTime = Millisecs End SetAlpha 1.0 SetColor 255,255,255 DrawText _frameRate, 0, DeviceHeight-12 End Public Method OnCreate() _ship = LoadImage( "Ship1.png", 1, Image.MidHandle ) _background = LoadImage( "galaxy2.png" ) _shipList = New List<Sprite> For Local i:= 0 Until 400 Local ship:= New Sprite( _ship ) Local x:= Rnd( DeviceWidth ) Local y:= Rnd( DeviceHeight ) ship.SetPosition( x, y ) ship.SetRotation( 360.0 * Rnd ) _shipList.AddLast( ship ) End SetUpdateRate 60 End Method OnUpdate() #If TARGET="android" If KeyHit( KEY_ESCAPE ) Then Error "" #End For Local ship:= EachIn _shipList ship.Update End End Method OnRender() Cls '<--- Actually improves fps DrawImage _background, 0, 0 For Local ship:= EachIn _shipList ship.Render End _ShowFPS End End Function Main() New RenderTest End |
| ||
Not always practical, but using JPG instead of PNG whenever possible can make a quite a difference depending on the situation/number of images. Also, if the images, need to be "resized" (or any other on-the-fly transformations for that matter) for before drawing then FPS is going to take a hit. Have not tested any of this on the latest versions of Monkey, but this has been my experience. Yeah, probably obvious and once again not always a solution. Far too lazy to post a demo. |
| ||
Samsung Galaxy S2 with Android 2.3.3 using original code: http://www.monkeycoder.co.nz/Community/post.php?topic=869&post=7218 82 - 198 objects = 60 FPS 202 objects = 58 FPS 302 objects = 39 FPS 390 objects = 29 FPS and crash after 30 seconds |
| ||
As has been pointed out, the original code is missing a Cls something that could perhaps be classed an error in mojo given it's ramifications in many EGL environments. |
| ||
@Skid - what ramifications? When testing I came across a strange issue when not using CLS and not displaying a background image - it displayed the view 3 times across the screen (split in 3rds). Ill have to try to see the speed difference with CLS and drawing a background... |
| ||
This is from some apple docs I imagine android EGL stacks are similar: Erase the Renderbuffers At the start of every frame, erase all renderbuffers whose contents from a previous frames are not needed to draw the next frame. Call the glClear function, passing in a bit mask with all of the buffers to clear, as shown in Listing 4-2. Listing 4-2 Erasing the renderbuffers glBindFramebuffer(GL_FRAMEBUFFER, framebuffer); glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT); Not only is using glClear more efficient than erasing the buffers manually, but using glClear hints to OpenGL ES that the existing contents can be discarded. On some graphics hardware, this avoids costly memory operations to load the previous contents into memory. Summary: even if you intend to draw a fullscreen background you should call Cls at the beginning of your OnRender handler. |
| ||
this avoids costly memory operations to load the previous contents into memory I've been having some issues with PS on iOS (getting Program received signal: “0” crash), Mark has sent me some details to help... but I wonder if this will help too. Thanks Skid! [edit] Just looking in mojo's ios code for Cls, it only does the GL_COLOR_BUFFER_BIT, does it need to do the GL_DEPTH_BUFFER_BIT too? [/edit] |
| ||
Just tested the Cls command on the Android version when displaying a background as well. On my phone it wasnt faster, I would say about half to one frame per second slower... (FPS counter shows 21-22) |
| ||
Just looking in mojo's ios code for Cls, it only does the GL_COLOR_BUFFER_BIT, does it need to do the GL_DEPTH_BUFFER_BIT too? Only if you enable depth testing, which is silly for 2D. glEnable(GL_DEPTH_TEST); glDisable(GL_DEPTH_TEST); Edit: http://www.opengl.org/wiki/Depth_Buffer This is done by calling "glEnable(GL_DEPTH_TEST);". By default, depth testing is disabled when you create the GL context. |
| ||
Using v41 I now get 25FPS in the same test as in post #18, so an increase of 3FPS :) Still along way off Libgdx's 55FPS ;) |
| ||
check if anti-aliasing is turned on |
| ||
With v41, I'm seeing: -> *LOSS* of 3-9 FPS using speedtest from post #19 -> *LOSS* of 2-3 FPS in my current app Probably because some OGL hardware handles float operations faster than integer operations and visa-versa. I'll be sticking with the pre-v41 "float" version of 'mojo.android.java' for now as it's faster on the primary android device I'm targeting (i.e. NookColor). |
| ||
Hi. I looked at libgdx (SpriteBatch) and monkey mojo (surfaces), and it seems both are doing sprites the same way. The biggest difference is that libgdx will use OpenGL 2.0 shaders, if available. That may cause a speed increase. But I hear that glDrawTexfOES is the fastest method for Android GL11 (slide 24 onwards): http://www.scribd.com/doc/16917369/Writing-Real-Time-Games-for-Android Other resources for Android speed tests: http://code.google.com/p/apps-for-android/source/browse/trunk/SpriteMethodTest/README.TXT |
| ||
Hi, > With v41, I'm seeing: -> *LOSS* of 3-9 FPS using speedtest from post #19 Hmm, that's a bit weird, it's supposed to be a win on all versions of Android up pre-honeycomb (3). The issue is apparently due to some lazy coding in the implementation of android's floating point vertex buffers. Int buffers don't have this problem (again apparently) so the 'fix' is to convert floats->ints (bitwise), and use int buffers. It's a minor win on my Galaxy S, but I can see how it'd be a loss on devices with 'fixed' float buffers, as the float->int conversion is a call per vertex component. Perhaps some pre-honeycomb devices have this fix in already? My instinct here is to revert to float buffers, as int buffers aren't THAT much of a win, and float buffers will likely perform better on fixed/newer hardware. The latest version of Monkey also includes an optimization for drawing 'non-alpha' images. Previously, ALL images were effectively being blended to the back buffer. Now, mojo checks image format/alpha and turns off blending when possible. Seems to work pretty well with large-ish images, not all that much difference with lots of small ones. I also can't get any results from Cls-ing. I was thinking perhaps depth buffer may have to be turned on for it to work (ie: to make use of hierarchical z-buffers?), but that didn't seem to help either. |
| ||
@DGuy - when you say pre-v41 what version did you test with? V38 had the buffers as: gxtkGraphics(){ vertices=FloatBuffer.allocate(MAX_VERTICES*2); texcoords=FloatBuffer.allocate(MAX_VERTICES*2); colors=IntBuffer.allocate(MAX_VERTICES); } v39c had the buffers as gxtkGraphics(){ ByteBuffer buf; buf=ByteBuffer.allocateDirect(MAX_VERTICES*2*4); buf.order(ByteOrder.nativeOrder()); vertices=buf.asFloatBuffer(); buf=ByteBuffer.allocateDirect(MAX_VERTICES*2*4); buf.order(ByteOrder.nativeOrder()); texcoords=buf.asFloatBuffer(); buf=ByteBuffer.allocateDirect(MAX_VERTICES*4); buf.order(ByteOrder.nativeOrder()); colors=buf.asIntBuffer(); } ^ this code is meant to be the "right" way of doing it (this is what I was talking about in the other thread: http://www.monkeycoder.co.nz/Community/posts.php?topic=941 ) When moving from v38 to v39, I lost about 10FPS, with v41 (int buffers) I had an increase of 3FPS. So from moving between v38 and v41 I lost around 7FPS. But in v38 I couldnt use the SDCard stuff and other features... |
| ||
(Remember I provided the same exact fix before I realized Mark has already done so .. ;) ) Was using v39c prior to v41 (skipped v40) |
| ||
Okay, can you post your results using v38, v39c, v40 and v41 please? (original versions, no "fixes") (Remember I provided the same exact fix before I realized Mark has already done so .. ;) ) lol - I forget who post stuff these days - must be getting old... |
| ||
I saw no performance change between v38 and v39c, and a (I think significant) performance drop with v41 ... |
| ||
Well these are my results using the rendertest (post #18) with 100 objects:| v38 | v39c | v40 | v41 ----+-----+------+-----+----- FPS | 29 | 21 | 21 | 24 |
| ||
Anyone interested in a slightly faster* (+0.5-1 fps) implementation of Android Mojo, look here: <snip> [Edit] Moot as of Monkey v42 ... [/Edit] |
| ||
Hi, More improvements coming, but I'm moving this to programming for now... |
| ||
Tested with a background with alpha and a background without - same FPS in v42:| v38 | v39c | v40 | v41 | v42 ----+-----+------+-----+-----+----- FPS | 29 | 21 | 21 | 24 | 22 So lost 2 FPS this time... |
| ||
Which device/phone is this on? Any chance of posting the same results for different devices/phones? |
| ||
This in on my LG Optimus One P500, using the same phone when using libgdx code I get 55FPS. |
| ||
That's a huge difference therevills... what could be the bottleneck? I've read somewhere that SetColor for images is very slow in monkey Btw, DGuy's number's seem very close to the ones got by the other lib... what is he doing in his own monkey impl? |
| ||
what could be the bottleneck? Wish I knew! SetColor for images is very slow in monkey SetColor is very slow for HTML5, it doesnt have that much affect on performance for Android. DGuy's number's seem very close to the ones got by the other lib I believe his numbers where taken before he changed his monkey impl - the performance is device based - I think David is testing on his NookColor, which has a better CPU/GPU than my phone. |
| ||
Hi, > Tested with a background with alpha and a background without - same FPS in v42: Can you try the mak/bouncyaliens test? Click in the middle 3rd of the screen to toggle between alpha aliens and solid aliens. |
| ||
<snip> [Edit] See this post for updated/more valid info: http://www.monkeycoder.co.nz/Community/post.php?topic=869&post=8371 [/Edit] |
| ||
Hi, On android? |
| ||
Yep, on Android ... :) |
| ||
Hi, > NOTE: I didn't really see any difference, fps-wise, between tranparent and non-transparent versions of the test. That's weird - I get an approx 30% speed up with opaque images (Galaxy S). |
| ||
Hi, The LG Optimus one has a weird GPU... http://en.wikipedia.org/wiki/LG_Optimus_One So none of the PowerVR opts are likely to help. Is the NookColor PowerVR? Next step would probably be to try some native c++ code, but that's a bigger project. I'd also like to be optimizing MORE for PowerVR though, I kind of think this should be the priority. |
| ||
I would say PowerVR and Adreno GPUs are just as popular in the android world. I think both deserve the same attention when optimizing (though PowerVR might be easier due to the fact that iOS devices also use them and there might be more info on optimizations) Also, nVidia is pushing Tegra 2 (and soon Kal-El) so that might become a major player soon. Good news is nVidia's offer is quite a lot more powerful than the competition, and since monkey is hardly aimed at high-end 3D graphics, their GPUs shouldn't be a target for optimizations anytime soon. Adreno devices: http://developer.qualcomm.com/devices PowerVR SGX devices: http://en.wikipedia.org/wiki/List_of_PowerVR_products#Series5_.28SGX.29 |
| ||
Well the LG Optimus One plays Angry Birds fine and even Raging Thunder 2 is playable... I've tested quite a few Android games on it and it plays most of them well - thats why I raised this issue. Bouncy Aliens Testing: | v38 | v41 | v42 ----+-----+-----+------ 100 | 24 | 21 | 19 200 | 14 | 12 | 11 300 | 10 | 8 | 7 400 | 7 | 6 | 6 And little or no difference with or without alpha... |
| ||
Next step would probably be to try some native c++ code, but that's a bigger project. I tried replacing a lot of the IntBuffer stuff with the libgdx native code. There really wasn't that much of an improvement. I have a tilemap demo that runs at about 4fps on the Nexus One, but with native calls and a bunch of other small optimisations I got it to 8fps. |
| ||
The biggest difference is that libgdx will use OpenGL 2.0 shaders, if available. That may cause a speed increase. Oh BTW this is false, libgdx will only use OpenGL 2.0 if you set it in the initialize method. Here is my Android main class for libgdx: Notice the initialize parameters - new Game and false - the false is a flag to tell LibGdx to use OpenGL 2.0 or not: |
| ||
Ok, here some values from my HTC Desire HD:| v38 | v41 | v42 ----+-----+-----+------ 100 | 60 | 50 | 51 200 | 55 | 30 | 31 300 | 41 | 22 | 22 400 | 32 | 17 | 17 But I noticed that v41 and v42 seems to run in higher resolution mode, at least the font is smaller which could be the reason for the lower fps. |
| ||
Since v39 the Android manifest was changed to include the minimum sdk and target sdk, which makes your game use different resolutions... Oh BTW you guys have too much money ;) |
| ||
dupe |
| ||
dupe |
| ||
dupe |
| ||
dupe |
| ||
dupe |
| ||
dupe |
| ||
dupe |
| ||
Since v39 the Android manifest was changed to include the minimum sdk and target sdk, which makes your game use different resolutions... Good spot. This may well be contributing to the issue, the debug text is much smaller since v39 on my device so it must be running in a higher resolution? If monkey is pushing, say, twice as many pixels as libgdx then it's not really as valid a comparison. Anyway, here are the results of the (£99 pay as you go Android phone) ZTE Blade jury. The ZTE Blade uses a Qualcomm MSM7227 600 MHz CPU with Adreno 200 GPU. My device is running the CyanogenMod 7 firmware, not sure if that affects performance? libgdx: using apk from post 18 monkey: using code from post 19, assets from post 9, code built in release mode over USB direct to device. | Libgdx | v38 | v41 | v42 -----+--------+--------+-------+-------- 100 | 61 FPS | 36 FPS | 30 FPS | 30 FPS 200 | 61 FPS | 21 FPS | 17 FPS | 17 FPS 300 | 61 FPS | 14 FPS | 12 FPS | 12 FPS 400 | 54 FPS | 11 FPS | 9 FPS | 9 FPS 600 | 42 FPS | 7 FPS | 6 FPS | 6 FPS 1000 | 29 FPS | 4 FPS | 3 FPS | 3 FPS Interesting that there's no (measurable) difference on my phone between v41 and v42? |
| ||
Some NookColor Specs: CPU Processor: ARM Cortex A8-based Ti OMAP 3621 @ 800 MHz (same processor as Droid 2 and Droid X) GPU Processor: PowerVR SGX530 Graphics Rendering: Open GLES1.1/2.0 (same GPU as Droid 2 and Droid X) |
| ||
Just so that we're all on the same page, I re-ran the "mak/bouncyaliens" test using the v42 version. NOTES: - Monkey v42 - Run on Android - 1024x600 screen size | w/ Alpha | w/o Alpha ----+----------+---------- 100 | 19-20 | 47 200 | 12 | 36-37 300 | 8 | 29-30 400 | 6 | 23-24 With the larger sprites (and thus more alpha-pixels), the new blending optimizations really shine. |
| ||
I might not be understanding, but what's so shiny about 6fps? o.O |
| ||
What's shiny are the numbers in the "w/o Alpha" column ... :) Monkey used to have alpha-blending turned on all the time, thus the numbers in the "w/ Alpha" column were all there was, but now it's optimized its' usage of alpha-blending to apply it only when needed. |
| ||
Ahhhh! That's for the clarification. Those are pretty shiny numbers. :) |
| ||
Wow, thats a great performance increase on your Nook! But the only images I can really see this optimization helping is background images... @David, could you test the code in #19 using the resources in #9 and post your results - then change the background image so it doesnt have alpha please? When I did this I saw minimum improvements (<1FPS). |
| ||
Hi, The 'new style' manifest added in V39 is definitely making everything run higher-res here. Stuff that used to run 320x533(?) now runs 480x800. Is it happening on everyone's phones? You can quick test by nuking the 'min-sdk/max-sdk' stuff in the manifest. If so, this would probably account for the 10-ish% slowdown from v38-v39, which would mean it wasn't the new style vertex buffer allocation. |
| ||
I added the new style vertex buffer stuff using DGuy's code to v38 (so before the min-sdk/target-sdk) and it wiped 10FPS off my game. http://www.monkeycoder.co.nz/Community/posts.php?topic=768 Also my phone's native resolution is 320x480. |
| ||
Meh, was worth a shot... |
| ||
As requested by Therevills: Using speedtest from #19 & Resources from #9: NOTES: - Monkey v42 - Run on android - 1024x600 resolution TEST: A - Background & Ship w/ Alpha B - Background w/o Alpha; Ship w/ Alpha C - Background & Ship w/o Alpha | A | B | C ----+-------+-------+------- 100 | 41 | 42-43 | 48-49 200 | 32-33 | 34 | 43-44 300 | 27 | 27-28 | 32 400 | 21-22 | 22-23 | 24 I'm sure the reason there is only a 1-2 fps increase between test A & B is because the hundreds of alpha blended sprites are affecting FPS far more than the single background image. |
| ||
@Therevills: I added the new style vertex buffer stuff using DGuy's code to v38 (so before the min-sdk/target-sdk) and it wiped 10FPS off my game. Note, that "new style" is actually for the slower "old style" non-interleaved-arrays method that Mark stopped using, so I'm not surprised you saw a FPS drop. v42 uses interleaved arrays now. |
| ||
The 'new style' manifest added in V39 is definitely making everything run higher-res here. Stuff that used to run 320x533(?) now runs 480x800. Is it happening on everyone's phones? You can quick test by nuking the 'min-sdk/max-sdk' stuff in the manifest. v39+ is definitely now running at my phones native resolution. |
| ||
New results for v43 - rendertest (post #18) with 100 objects:| v38 | v39c | v40 | v41 | v42 | v43 ----+-----+------+-----+-----+-----+----- FPS | 29 | 21 | 21 | 24 | 22 | 44 Doubled the FPS :) \o/ YEAH!!! WOOOWHO!!! |
| ||
@therevills: on Android or iOS? not sure what have changed, but my game has huge FPS drop on Android Galaxy Tab (7") from nice 35-40FPS to 18-20FPS. Nothing changed beside Monkey upgrade from v42b to v43. I'm gonna cry... |
| ||
On Android. |
| ||
So it's for the version with libgdx? Haven't tried that yet, but official drivers/libs noticed huge drop in frame rate. |
| ||
The comparison benchmarks in posts 18 & 19 have some major flaws. The update function is called multiple times on the monkey version of the performance comparison (posts 18 & 19), where on the libgdk it is called once per render. The sin and cos functions are not that cheap, and with 400 objects they are being called 1600 more times per frame. You should move the update function into the monkey render loop and update it with a delta to make it a fair comparison. Next, the logic for wrapping their coordinates around the screen is bad on the libgdk version (when wrapping for the right/bottom of the screen they are waiting until the x > screen width + image width, which is a bug that means they use less fillrate than they should. The monkey version uses much simpler logic, which has the opposite bug, when wrapping across the right/bottom it just sets the coords to 0 which uses more fillrate than it should. |
| ||
I agree we need a better benchmark. Any volunteers? ;) |
| ||
@anawiki - no the results shown are for the latest Monkey version, running on Android. Yes Monkey does do multiple updates, but it is the rendering which is the problem. Sin and Cos are not the problem, if you comment out all the drawing of the images Monkey will run at 60FPS ;) - I have tested this. |
| ||
Using the "mak/bouncyaliens" demo ... NOTES: - Run on Android - 1024x600 screen size v42 | w/ Alpha | w/o Alpha ----+----------+---------- 100 | 19-20 | 47 200 | 12 | 36-37 300 | 8 | 29-30 400 | 6 | 23-24 v43 | w/ Alpha | w/o Alpha ----+-----------------+------------- 100 | 31 (+10-11) | 48 (+1) 200 | 20-21 (+8-9) | 42 (+5-6) 300 | 15 (+7) | 31-32 (+2-3) 400 | 12 (+6) | 26 (+2-4) NOTE: HICOLOR_TEXTURE [True|False] had no effect performance-wise As with Therevills, I'm seeing FPS increases across the board, particularly with alpha sprites: Nicly Done, Mark! |
| ||
@therevills I am not talking about what is slow in mojo, just how you would make a fair comparison between mojo to libgdx. Mojo should continue to be optimized until it is at least as fast as libgdx. |