iMiniB3D slow on 3GS
BlitzMax Forums/MiniB3D Module/iMiniB3D slow on 3GS
| ||
| I have written a simple demo that runs fine in the Simulator. On my 3GS it runs at about 10-11 frames per second. Are there any tips on things to avoid in iMiniB3D that heavily impact performance on a real device? |
| ||
| what is the polycount in the scene? |
| ||
| Simulator only simulates code execution, but it's running on the desktop hardware so has no connection when it coms to performance. Sometimes it's worse, usually it's a lot better. Biggest thing in general is remember its a mobile platform, that means : much slower processor. Much less ram. Everything needs to be trimmed accordingly: loops, allocations and releases, object count (this is the hardest one for me usually), mesh complexity, texture size, etc. If you're using thing outside of iminib3d there are plenty of chances for that to impact performance. Timers in particular add up pretty quick... Sometimes your allocations can have a big impact if you make and especially if you're auto releasing things every frame. Depends on your structure but allocating some work objects and recycling them can be a big gain. Last edited 2012 |
| ||
| The code I was testing had a lot of looping, and was quite inefficient, so I have changed that and things have improved. iMiniB3D really improves your coding, reminds me of the old Z80 days for the Spectrum ;-) Thanks for all your help Rob |
| ||
| I can't even remember how many ways there are to loop things in Objective C... all with varying pros and cons. Simple rule of thumb for anything with tight hardware requirements: if it *can* be tighter it probably *needs* to be :0) That's why Android bothers me so much, automatic garbage collection is great if you're lazy but what if you want to make sure the memory doesn't thrash in the middle of a render call... SOL. I'll take the hassle of managing things myself and knowing what is happening when... it's easier to snipe leaks than duel with the system over basic functionality. Manual management becomes second nature quite quickly, then it feels weird to go back to a managed environment... "so... I can just sort of leave that there and it will be ok? handy... but now I'm scared" There is one lazy trick that I do use a lot in iOS as relates to looping... If you have to modify a grouping *while* iterating it, iterate a copy. You incur the overhead of making a copy every pass but if you make a lot of changes it makes life SOOOO much easier... e.g.
for (BadGuy *onBadguy in [[badguys copy] autorelease]) {
if(onBadguy.Update()) {
// if the update returns true the badguy died
[badguys removeObject:onBadguy]; // since he's dead we don't need him anymore, since we're actually itterating a copy of the badguys array it's safe to modify the real one...
}
}
you can tighten it a little by creating the list, then iterating it, then releasing it so you're not using autorelease, but it's nice to have it all in one line somtimes... also it's nice to have the cleanup of the badguy objects that get dropped along with the array copy happen on the cycle cap rather than mid update... Last edited 2012 |
| ||
I found the bottleneck was in my "workaround" for the gimbal lock problem, using RotateMesh but this is incredibly slow :-(sphere->RotateMesh(fPitch,fYaw,fRoll); Will try to find another workaround |
| ||
| Might I suggest using the following library: http://code.google.com/p/vfpmathlibrary/ Also remember that the arm processor in iOS devices is slow as shit when handling lots of floating points. I use bytes and shorts where possible. Be sure to implement delta timing for those times when the cpu cycles drop way down. Animation on multiple entities will drop your cpu performance pretty badly, be sure to space out updates on that. Finally I cap the frame rate at 30fps which seems to help give some breathing room, and if you use delta timed movement you dont notice it anyways. Best of luck speeding your code up! |
| ||
| Thanks for the tips Is there a way to cap the framerate in iMiniB3D? |
| ||
| You may already know this, but use texture atlases for your sprites. The less texture switching, the faster the app will be. This includes fonts, and UI. |
| ||
| Iminin3d calls its update method with an NSTimer in its eaglview subclass. It either has a method to start the timer delay or there's a constant... I haven't used the base on in a while so I don't recall exactly :0). It can't render faster than the timer fires. If the main thread is engaged while the timer wants to fire (for example it's already processing a fire...) then it gets skipped and you drop a frame, hence tweening comes in handy. If you can keep it above your target frame rate, since iOS devices are static hardware with little to no actual background tasks, you can cheat and skip tweening more safely than a desktop. Buts it's still better to do it right... Plus if you tween you can raise your frame rate on faster devices without recoding... |
| ||
| Enable VBOs if you haven't already. Gerball went from 30-40FPS to 60FPS on a 3GS when I enabled VBOs. I use RotateMesh in gerball by the way - it's not that slow! How many vertices does your mesh have? Try to limit the number of vertices. |
| ||
| CreateSphere(64) |
   |