Anyone have experience of any performance hit when using complex custom collision actors?
Japster
Member Posts: 672
Hi guys! - my latest WIP game is using one large actor with custom collider info as a level, and I notice on slower devices as soon as I collide with the 'level' actor the whole thing stutters REALLY badly - fine on iPhone 6, etc, but on iPad 2/3, it's really noticeable? - and after adding more stuff to the game, the same thing happens in Creator on certain levels, so I'm guessing it's using a lot of the CPU time...
So my question is, even though I took the easy option of creating a custom collider (manually tweaked) for the level, and it probably contains about 150-200 nodes / maybe 40-50 polygons, should this normally be a realistic sort of collider count given other game logic running etc? - or should I be resorting to adding collider actors instead, along the walls? - I doubt that'd be faster, but you never know in the world of GS! 
For reference, here's a video of the game in action - the Youtube video, as usual, is nowhere near as smooth as the real thing, but hopefully this will give an idea of the complexity? - I AM using some timers, and I know I have to get rid of them (just struggling to make the none-timer based equivalents work for me), but disabling those same timer rules didn't seem to make a difference anyway?...
Any experience with performance/expectations would be appreciated guys, cheers!
One video shows a level pan for 1m30s (You can hopefully see that the level is quite angular, and I've made it the minimum possible nodes for the shape of it), then follows a demo of the gameplay, while the other video shows a rescue mission - both have quite a bit going on I guess, and run very smoothly in the creator and on the iPhone 6 (despite the video being jerky), but again, the ONLY slowdown is when I hit the custom collider for the 'level' actor?
Comments
I had this problem before and asked in the forums cause I remember others also had the issue of stuttering , we got a reply from codewizard which explained it.
more detailed explanation here
http://forums.gamesalad.com/discussion/91905/stable-release-1-25-is-available/p3
I reported the bug , sent 2 projects but no response so I just do my games now without worrying about it
Ah it wont let me edit the comment above , sorry for double posting but i forgot to mention GREAT game you have there ! i love it .. as for the performance and stuttering , it usually happened when I had many particles or trig functions.. but it is not consistent i cant tell what was the main cause .. and no need to get rid of timers , they dont cause performance issues, it might have years ago but not anymore
Thanks @Icebox , much appreciated, and gives me ideas to try... Sounds like what I was dreading though, with using a big custom collider... Looks like a shedload of optimisation is going to be required.... :frowning:
Timers not affecting performance badly sounds fantastic! - deffo the case?
That'll be one less headache if so, and easier to maintain code/logic... 
Thanks for the kind words, btw! - nice of you to say...
Your own game looks great too, and getting even better with every post! - I commented earlier this week... 
PS - Worryingly, I notice from that post you referred to, that they'd had an issue with actors 'sticking' to each other - I got that EVERY time (bullets vibrating/just sticking to walls, following the outline, or obstacles, etc, and not rebounding, tried LOADS of stuff to sort it, but no joy, so I couldn't let the physics engine control the correct deflection - REALLY annoying - I ended up having to pick random angles to deflect at, crap in comparison), but it's ironic that post mentioned they'd had a problem, which I seem to have got despite the workaround to the colliders that they've done...
..and in addition my little 'astronuts' can't be rotated to follow slopes etc, as they simply end up falling over, but hey, that might be me expecting too much of the physics - seems crazy though, they literally worked fine for ages, then at some point one or more of them teeters over, and breaks the level completion (short of shooting 'em!
) - I tried limiting the rotation attribute, lowering the centre of mass, friction, density, etc, etc, but no joy getting it to work reliably.... 
Had an interesting idea to spread the workload though - might be worth my having certain checks firing off at alternative cycles/frames to others - i.e. ID cycles up and resets - 1,2,3,1,2,3,1,2,3....) 'then 1 frame for movement logic, second for colision, then another (3rd) one runs for firing, and if firing three bullets at once, stagger the spawn over 3 frames, reducing the CPU usage per frame, but adjusting start X/Y to still spawn them in the correct formation, and up the alpha on them all once enough time has elapsed for all 3 are spawned... Hmm... optmisation thinking cap on...
@Japster, the "actor sticking to walls at low angles of incidence" is a Box2D problem.
Turning friction off on both colliding actors helps. If your game allows, you can also make sure that the speed of the moving actor stays high, as the problem mostly occurs when the colliding actor moves slowly.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
@Hopscotch Thanks for responding mate, but in that case, I think I'm boned... :frowning: - My little Astronuts stop, tap their feet, wave, etc in amongst running around... :frowning: ...and actually, thinking about it, they were falling over even before I stopped them running to do these things! :frowning:
I lowered/turned friction off too, but then they just slide down a slope when waving etc, and struggle to walk up it... argh...
...and can't really make the move/walk faster (they also run too, in certain scenarios (player lands on pad, etc), as it would look like they're on speed, or in a Benny Hill movie! :frowning:
Darn it...