Performance Issues in Mobile...and im giving up

[DonFrag]

Im sorry but this is breaking my head so much i cant understand

im making a game and in pc i get 60 fps sometimes slowdown to 56. I.m making a block puzzle game with arcade physics.

in mobilecgives me an average of 30 (26-> 34 fps) testes on samgung galaxy s4 with chrome.

 i have read thread about performance. im reusing sprites killed, using arcade physics, blocks are extended sprites that call collision on update only when they fall...even so my perfomance is poor, and this is like 30% of what i want to be my final game.

i'm giving the link to the game so if you can help because now i'm in a bottleneck and really don't know how to improve performance in mobile.

 

http://www.abstractpixel.cl/test/

 

 

the js files are here

 

http://www.abstractpixel.cl/test/js/

[bruno_]

Are you running in the browser or an app like cordova or cocoonjs?

[jmp909]

I've not really done anything with Phaser physics yet but ,..

 

CODE STRUCTURE

* well the first bit of fun is it says here don't use "prototype" in your code

http://www.html5gamedevs.com/topic/9931-mobile-performance-tips-tricks/

but let's ignore that for the time being as obviously a lot of people do. 

 

 

GAME LAYOUT

* do you really need your game to be 700x1100?

 

 

PHYSICS

• i think your physics is possibly broken. i pushed a block through the left wall (see screenshot). (and the same on the right wall) should I be able to do that? Why are you setting up the left wall as a collidable physics object anyway? can't you collide with world bounds? if not see my point below anyway about avoiding horizontal collision (I don't know any other way)
   
• I can also push objects side to side. are you meant to be able to do that? maybe you could set the body offset so the left/right edges don't collide with each other (slightly different example here http://phaser.io/examples/v2/arcade-physics/vertical-collision), but set the offset to non zero and a smaller width to match
   
• you've got every single block class running a .collide() function. would setting a group-to-group collision (to itself) be faster? 
  
  i just run this in my update function, which makes sure each block in the blockGroup collides with the other block

  create() {    // create enemy group with physics    this.enemiesGroup = this.game.add.group()    this.enemiesGroup.enableBody = true;    this.enemiesGroup.physicsBodyType = Phaser.Physics.ARCADE;    // add enemies to group    for(var i=0; i < 10; i++) {        var enemy:Phaser.Sprite = this.enemiesGroup.create(...)        enemy.body.collideWorldBounds=true;        enemy.body.allowGravity=true     }update() {    // etc    // all blocks collide with each other with a single collide call    // i don't know if this is optimal, but the collision works    this.game.physics.arcade.collide(blockGroup, blockGroup, this.groupCollisionHandler, null, this);}

  note what it says here again..
  http://www.html5gamedevs.com/topic/9931-mobile-performance-tips-tricks/
   

  don't call  game.physics.arcade.collide   20 times in the update loop.. try to do the same thing with 5 calls ;-)

   

  i'm guessing group-group collision is optimised internally. Where where I'm calling one collide, you're calling it at least 66 times on those blocks (that said, I haven't tested my prototype on mobile)
  
  (but yes maybe only still only call that group collide when the game state is set to allow falling)

 

 

just some pointers off the top of my head. again I'm new to this so I can't give you any exact advice!

 

regards

J

[vohogames]

I am no expert and just learning. I have samsung s4 and same problem.

here are the my humble suggestions. 

I had the performance problem with default browser. And then i switched to Intel XDK and deploy application using Crosswalk. It makes huge performance difference. ( Also, i used ionic with crosswalk, it didnt work)

You can open the game here on browser http://www.oyunta.com/animal-puzzle-hayvanlari-kurtar/Oyna/

when clicking animals, it shows stars. These stars fall down really slow on default browser. with crosswalk, there is no lag. 

 

I hope it may be useful.

[jmp909]

in fact I'm not sure my collide is ideal either

 

"If two arrays are passed, the contents of the first parameter will be tested against all contents of the 2nd parameter"

 

that does mean I'm essentially checking everything against everything ... which is a waste of processing .. for a game like yours, if it was only vertical movement I should only need to check the blocks above and below. in which case I guess it would be right to put the collision update in the Block class.. i suggest you try and modify your setup so you're only needing to check blocks that are even likely to be touching. Again it would help to know what's *actually* meant to happen, as in whether blocks are meant to stick to a grid and only move vertically or not

[DonFrag]

I've not really done anything with Phaser physics yet but ,..

 

CODE STRUCTURE

* well the first bit of fun is it says here don't use "prototype" in your code

http://www.html5gamedevs.com/topic/9931-mobile-performance-tips-tricks/

but let's ignore that for the time being as obviously a lot of people do. 

 

 

GAME LAYOUT

* do you really need your game to be 700x1100?

 

 

PHYSICS

• i think your physics is possibly broken. i pushed a block through the left wall (see screenshot). (and the same on the right wall) should I be able to do that? Why are you setting up the left wall as a collidable physics object anyway? can't you collide with world bounds? if not see my point below anyway about avoiding horizontal collision (I don't know any other way)

   

• I can also push objects side to side. are you meant to be able to do that? maybe you could set the body offset so the left/right edges don't collide with each other (slightly different example here http://phaser.io/examples/v2/arcade-physics/vertical-collision), but set the offset to non zero and a smaller width to match

   

• you've got every single block class running a .collide() function. would setting a group-to-group collision (to itself) be faster? 

  i just run this in my update function, which makes sure each block in the blockGroup collides with the other block

  create() {    // create enemy group with physics    this.enemiesGroup = this.game.add.group()    this.enemiesGroup.enableBody = true;    this.enemiesGroup.physicsBodyType = Phaser.Physics.ARCADE;    // add enemies to group    for(var i=0; i < 10; i++) {        var enemy:Phaser.Sprite = this.enemiesGroup.create(...)        enemy.body.collideWorldBounds=true;        enemy.body.allowGravity=true     }update() {    // etc    // all blocks collide with each other with a single collide call    // i don't know if this is optimal, but the collision works    this.game.physics.arcade.collide(blockGroup, blockGroup, this.groupCollisionHandler, null, this);}

  note what it says here again..

  http://www.html5gamedevs.com/topic/9931-mobile-performance-tips-tricks/

   

  i'm guessing group-group collision is optimised internally. Where where I'm calling one collide, you're calling it at least 66 times on those blocks (that said, I haven't tested my prototype on mobile)

  (but yes maybe only still only call that group collide when the game state is set to allow falling)

 

 

just some pointers off the top of my head. again I'm new to this so I can't give you any exact advice!

 

regards

J

 

 im running in a browser. chrome.

 

1-CODE STRUCTURE:

I just follow the advice of solarJS.in fact i asked for twitter this. The gamemanager code i made it without prototypes but the extended sprite i dont know how to do it without prototypes (in fact at the end of that thread that question has been made)

 

2-GAME LAYOUT

The reason for that is a company decision because that size would work with most mobile device in portrait mode

 

3-PHYSICS

the idea is that tha character destroy every block that touch if it is beside him. blocks should only move down when base collapse and gravity make them fall. teh borders colliders are designed for restraining the character movement (right side wil have the Game's UI)

 

you are suposse to destroy blocks down left and right of you if they are closer. this is a beta and i haven't worked further in mechanics because the performance has stopped me.

 

4-  i just read your second reply. in fact the block update

Block.prototype.update=function() {		if(this.alive)		{				if(this.y<game.world.height)			{			 this.visible=true;			    			}		else			this.visible=false;									}		 			     		    switch(this.state)		    {				        case STATES.FALLING: 				            		           		           		            game.physics.arcade.collide(this, game.gm.blocksList,this.OnCollide,function(block1,block2){		            	 return true;		            			            			            },this);				            						            break;		            		            		            		        case STATES.NORMAL:		           // this.body.velocity.y=UP_SPEED;				         //   game.physics.arcade.overlap(this, game.gm.player.sprite,null,null,this);		          		            break;		         		            		        case STATES.STOP:		           		          		            break;		            		        		   }		    		    // /debug		   var over='';		    if(this.upBlock)		        over=this.upBlock.n;		    else		        over='';						    		    this.text.text='N:'+this.n +' \n O:'+over;		    		    		    				}

the blocks make the collide check only when the FALLLING flag is on.

the default state NORMAL doesnt make any collision check.

 

 

@vohogames

im using the browser without crosswalk because the client want the game in his portal and be opened from any device without extra plugins.

 

 

 

[jmp909]

the blocks make the collide check only when the FALLLING flag is on.

 

 

but you're still checking every falling block against every other block I think? no block can be colliding with a block that is more than "BLOCK_HEIGHT" or "BLOCK_WIDTH" away from it.. therefore i'm wondering if it can be optimized to only check those around it .. then you'd save on over 50 collide checks *per falling block* ..

 

I've got a feeling you can just check a block's collision on *only* the block below it, *BUT* you need to keep track of what the block below it will be, given any gaps in any of the rows (it might not necessarily be directly below)

 

in my screenshot 

 

N11.downBlock => N17  (N11 not visible on screenshot)

N17.downBlock => N23

N23.downBlock => N29

N29.downBlock => N59

 

what other collide's do you actually need to make in that situation? 

 

that's, for example, 4 collides instead of about 200.

[DonFrag]

Well that makes sense. When a Block is destroyed his column should make the check. So somehow i must extract all blocks with the same x that the destroyed Block and that subgroup makes the check.

I find your point accurate. ..however i was thinking...when the game start even if there is no Block destroyed ( no checking collisions then) the fps are low.

Your solution will help a lot indeed but...What causes fps loss when no Block is killed?

[chg]

Your solution will help a lot indeed but...What causes fps loss when no Block is killed?

This is really something you should try to figure out using profiling.

I had a quick look and at least on my PC you seem to be spending an most of your time in _renderCanvas(), so for a wild stab in the dark... if you comment out the debug text on the blocks, does the frame rate when this.state==STATES.NORMAL improve? (ie. drawing less)

[DonFrag]

This is really something you should try to figure out using profiling.

I had a quick look and at least on my PC you seem to be spending an most of your time in _renderCanvas(), so for a wild stab in the dark... if you comment out the debug text on the blocks, does the frame rate when this.state==STATES.NORMAL improve? (ie. drawing less)

I commented that line and the lines that create text added as child in the Block constructor and fps raised to 50 55 .you nailed it!

[jmp909]

Good spot chg ! I was going to mention text is slow in my original reply, but I was only looking at the fps counter and that's bitmap text. It totally went over my head that all those text blocks had text fields on :S

[DonFrag]

Good spot chg ! I was going to mention text is slow in my original reply, but I was only looking at the fps counter and that's bitmap text. It totally went over my head that all those text blocks had text fields on :S

well now im going to apply the changes and i post the results

[jmp909]

This isn't directly related to your example, but it's worth a read

http://ra3s.com/wordpress/dysfunctional-programming/pruning-collision-detection-with-a-1d-sort/

[chg]

This isn't directly related to your example, but it's worth a read

http://ra3s.com/wordpress/dysfunctional-programming/pruning-collision-detection-with-a-1d-sort/

I would hope Phaser's Arcade Physics collide() method handles it's own broadphase algorithm to avoid something in the order of n-squared AABB comparisons, and if so you would hope you wouldn't see much potential for performance gain by hacking in another layer of broadphase pruning yourself...

If you want to beat a general case algorithm you would presumably need to optimize for your special cases or at least tune it carefully to the average and worst cases you are seeing in-game.

Should you do this? Probably not, not unless you have to in order to get the performance you are targeting (**Disclaimer: I am not a Phaser guy, I am making assumptions based on general principles, though my curiosity got the better of me and I peaked at the source - it looks like Phaser does currently use a spatial hash for broadphase on groups or hierarchies of sprites)

[mwatt]

Just scanned this thread, didn't read it carefully.  But I did see Android and performance issues.  Somebody recommended Crosswalk.   I can confirm that this helps tremendously.  Apple is still faster, but Crosswalk on Android closes the gap to a large extent.

[DonFrag]

well i made some changes trying to get some fps.

 

in the block update i added this

  game.gm.blocksList.forEachAlive(function(block){		        	   		        	   if(block.x==this.x)		        		  game.physics.arcade.collide(this, block,this.OnCollide,function(block1,block2){			            	 return true;			            				            				            },this);

so in theory reduce the collision checks.

 

y changed the border collision with a condition on the player update

if(this.x<32)this.x=32;	  

and i got some fps, but then i started to add the hear of the game. More blocks that are going up (thats how the game works) and the performance went down again.

:/

 

 

I Insist: I cant use cordova because im not trying to do a hybrid app.

im trying to make a browser game for a specifc site who demands that the game load on any pc and cellphone browser.

[jmp909]

This is what I would do

* look for existing games running at 60fps in the browser at around 700x1100 size with physics. Are there any anyway?

* consider setting the desired fps to 30

* improve your optimisation on your collision routines.... As far as I can see you're still checking collisions on blocks that you don't need to

* take a step back from your specific game and just set up some basic performance demos to test

* consider what's causing the slowdowns. I can run 3000 non colliding sprites in the pixi bunnymark demo at 60fps. Therefore I'm assuming physics is a big slow down. Do you actually really need physics ?

* are you using PNG's rather than Phaser.Graphics?. The latter is slow. If that's what you're using are you caching as bitmap at least?

Again I'm new to phaser so please don't take this as "expert advice". I'm in the same place as you are, trying to work out the capabilities of the system and how to make optimisations

J

[jmp909]

Chg... If I collide my group with itself and there are, say, 20 Sprites in the group what is the maximum number of collisions it'll check make without prior optimisation by myself?

Are you saying there's an implementation to reject a lot of collision checks, by eg distance? (QuadTrees etc). I vaguely know about those sort of algorithms but haven't implemented any previously.

Essentially, how can you actually improve on the provided internal routines anyway?

Thanks

J

[DonFrag]

well considering your proposal...

 

what do you think that is a good size for a portrait mode game considering that must work in pc browsers and cellphone and tablet browsers?

the only reason im using collision its because somehow i need to manage the blocks falling and stop when touch another block. thats all.

overlap tends to let one block slightly over other, and there is a example about overlap without physics but that relies in the fact that you must know who are the two objects who are colliding.

 

the blocks are a single white png tinted with a color when they are created and revived (because im using kill and reset reusing with  groups for perfomance).

 

i have tried profiling with chrome but most of the profiling info it's related to the phaser library ( and i think that its because most of the game objects are reference or call to the phaser lib obviously) so or im profiling wrong or there is a better way to catch the exact script line that is causing slowdowns (im using multiple js files with beefy as you can see).

 

right now im trying to raise performance beyond overall considering that the game it's supposed to be infinite down, and if i have this performance issues now i can't imagine what will come later...this it is just a prototype.

 

im considering using ES6 if that could benefit performance, but as i said, i'm testing every posibility.

 

Finally, maybe you are not a expert, but you guys have helped me a lot so that means a lot for me

thank you guys

[jmp909]

by the way.. look at this for example.. no physics, just tweens (although again the performance tips say watch out for doing too many parallel tweens.. again a new problem, needing another solution!)

http://robowhale.com/html5/salazar/

 

and ES6 currently compiles to normal JS. I doubt it'd give extra performance?

 

I'm also interested in how to resolve this as I'd like to make a physics-based Match3. I hope somebody who's already made some mobile-friendly web games can answer.

 

I know you've given access to the source, but I would consider getting your basic protoype code somewhere it's easier for people to download and play with.

 

J

 

update: just seen your new demo, and understand what you're trying to do now. I'm still wondering if a non physics approach would be better.. even using TileSprites maybe for the main board until something gets removed (then convert to normal sprites and tween down.. although that's getting more complex to manage). Again I would take a step back from your main code and try and get the core block movement/rendering functionality optimized as a separate demo that you can then re-integrate into your original code. It keeps the mind clearer!

 

 

screenshots:

 

* some issue with slight vertical block shifting

* what i was suggesting about vertical collisions only

[bruno_]

ES6 today has the same performance that ES5. No need to change if its just for performance reasons.

[DonFrag]

by the way.. look at this for example.. no physics, just tweens (although again the performance tips say watch out for doing too many parallel tweens.. again a new problem, needing another solution!)

http://robowhale.com/html5/salazar/

 

and ES6 currently compiles to normal JS. I doubt it'd give extra performance?

 

I'm also interested in how to resolve this as I'd like to make a physics-based Match3. I hope somebody who's already made some mobile-friendly web games can answer.

 

I know you've given access to the source, but I would consider getting your basic protoype code somewhere it's easier for people to download and play with.

 

J

 

update: just seen your new demo, and understand what you're trying to do now. I'm still wondering if a non physics approach would be better.. even using TileSprites maybe for the main board until something gets removed (then convert to normal sprites and tween down.. although that's getting more complex to manage). Again I would take a step back from your main code and try and get the core block movement/rendering functionality optimized as a separate demo that you can then re-integrate into your original code. It keeps the mind clearer!

 

 

screenshots:

 

* some issue with slight vertical block shifting

* what i was suggesting about vertical collisions only

the problem i see with vertical collisions only is that if the character gets in the middle of a group of blocks, if it moves right or left he moves through the blocks

[jmp909]

you don't need to collide the other blocks with each other horizontally though? just the character. or can the blocks move horizontally?

 

also please try and reduce the quotes to what's relevant for other people reading

 

ps watch out for this if you've destroyed upBlock (although I'm sure it's too early to be testing!)

Uncaught TypeError: this.upBlock.FallSignal is not a function

 

I think this type of game would work better if you shift the board up at the end of a turn rather than do continuous scrolling. You can end up with some blocks just constantly falling above you if you move left and then right again. 

 

sometimes they're actually getting stuck as well (screenshot). they're no longer falling, they're blocked. I don't think your widths are quite rounded off enough. 

[chg]

Hope this isn't too far off topic DonFrag (felt compelled to answer direct question)

Chg... If I collide my group with itself and there are, say, 20 Sprites in the group what is the maximum number of collisions it'll check make without prior optimisation by myself?

Worst case for any spatial partitioning will be O(N^2) ie. no objects rejected by the broadphase, and hence every object checked against every other in the narrowphase collision test.

 

Are you saying there's an implementation to reject a lot of collision checks, by eg distance? (QuadTrees etc). I vaguely know about those sort of algorithms but haven't implemented any previously.

No, I'm saying Phaser almost certainly has this in Arcade physics, and that it appears the algorithm used is a spatial hash (as opposed to a quadtree).

[chg]

you don't need to collide the other blocks with each other horizontally though? just the character. or can the blocks move horizontally?

You kinda sometimes do, as the player can push blocks so they aren't aligned with the grid horizontally (at least you could in the first example, and I presume it was intentional, though it seems you can't push them in the latest update)