I am working on a endless scroll , where my hero is moving infinitely on y-axis in upward direction and i’m updating the world for hero as he moves in upward direction , the updation procedure does not create any sprite or asset it just moves the exisiting assets up on the y-axis as hero moves upward on y-axis , so from hero’s perpective it looks that those are new enemy but they are the same old one with different(new) positions on the y-axis in the world.
I want to know is this architecture good enough for endless scroll because its causing frustrating lag issue on old android devices even though game is not heavy just 7-8 sprites in total created one time , Update loop is just changing position of sprite not creating anything new .
I have a similar thing with a horizontal endless scroll - with tens of sprites, GL texture drawing (for a surface) and parallax effects with background objects - and I’m getting no performance issues on Mac or IOS - haven’t tried on Android but what you describe should be fine on all but the most low-end devices I would think!
@Maxxx thanks for replying , even in my case when i’m running game on my system (linux 3.19.0-30-generic x86_64 , 4gb of primary memory) and on a good android device i’m having no performance issue but it lags very bad when i’m running it on some of my old android devices , my point of concern is that there are many other games with similar gameplay ( dont know about their engines ) on playstore which runs smoothly on those android devices but mine lags even though mine looks much lighter , what could be the possible problem ? have you tried running your game on older ios devices with low specs ?
I used to test my stuff on an original iPad - but performance seemed to get worse with newer versions of cocos - so you may be experiencing a similar issue.
I started to look at the different versions to see if I could track the problem down - but honestly gave up as it was taking too much time I could spend adding more weapons to PooperPig!
I’m not sure what to suggest - other than trying to produce a very simplified version and see if that suffers the same problem - then possibly you could post code here to see if anyone can suggest how to improve it - or whether ti’s just ‘how it is’
If you have access to earlier versions of Cocos it may also be worth trying it with them - see my issues at v3.7 speed compared with 3.6
@Maxxx So i should try compiling my code with cocos v3.6 currently i’m using v3.8 ? also my code is doing nothing special so i dont think i need to post my code here cause it is doing no such thing which should create bottleneck , i’ll think of sharing it here if people really want to examine my code.
Anyway thanks lets see if somebody else notices this thread and gives a valuable feedback
Hi. This is a right approach. Reuse sprites better than create them.
but for the performance here is some tips.
1- change texture of sprites with very low res and small textures. if the bottleneck is here then use smaller textures in size and depth (16 bit textures).
2- use and “do not use” spritesheets. Check the difference. (sometimes you get better performance if you do not use them!)
3- if you use physics turn it off. if the bottleneck is here maybe you not use physics correctly.
4- try the release version vs debug version.
5- turn sounds and music off and remove them and even not loading them. sometimes bottleneck is here.
6- Don’t render and update any texts and labels and check it.
@amin13a Thanks those some must try tips , i’m not sure how am i going to test without using physics cause my hero is moving up on the screen using hero->getPhysicsBody()->setVelocity() and falls down by the effect of world’s gravity , i’m confused how can i recreate this and test without using physics , can you give me any advice ? also i’v never tested my build in release mode i always do it in debug mode perhaps i should try it in release mode
@Maxxx@amin13a is hero->getPhysicsBody()->setVelocity() proper way to move a sprite ? cause it is giving more generic / realistic movement as compared to MoveBy() or should i create a separate thread to discuss this ?
