[Game performance/plugin] What ways can make FPS increase ?

[kenjivn14]

Hello, i'm a bit troubled. I am developing a plugin
I want it to work well on mobile, as far as I know mobile is not run by webgl, so I have rendered by Canvas

1st Test - Game performance / plugin
Loaded into one map with 3920 tree. It takes ~ 180mb. Within ~ 5ms,
But when playing games 7 FPS

Edited; I have updated more information

Spoiler: My System:

Main: A68HM-E33 V2
CPU: Amd Athlon X4 760k, 3800Mhz 2 Cores
GPU: AMD R7 360 OC
Total Physical Memory: 8,152 MB

Spoiler: Current Version

NWjs version: 0.35.3
Node verions: 11
RPG Maker MV 1.6.1

Spoiler: Test Cases:

• 1 Map with 17 x 13 (tiles)
• 1 picture tree.png
• 1 Plugin

File plugin with;

class UHPD_Sprite extends PIXI.Sprite (){
         constructor(texture){super(texture);}
}
class UHPD_MapObject extends UHPD_Sprite (){
         constructor(obj, texture) {
             super(texture);
             this.initialize(obj);
          }
}

const oldSpriteset_Map = Spriteset_Map.prototype.createCharacters;
Spriteset_Map.prototype.createCharacters = function (){
oldSpriteset_Map .call(this);
//value is the variable to handle the object
 const arr = value.map(k => new UHPD_MapObject(k, textures));
        for (const sp of arr) if (sp) this._tilemap.addChild(sp);
}

This is the second test

 

[peq42_]

If I understood, you tried testing a map, and it worked, but when you play elsewhere it lags? (Please try to add more details the problem)

In anyway, knowing MV, the lag comes from the fact that there's one(or more) of those 3 things happening:
1) There are too many objects that are parallel processes
2) Map is big and has big images within it
3) There's a broken plugin somewhere.

Try double checking the changes you made after the last time you tested and things were fine, and please list for us your plugins.

 

[MushroomCake28]

Not enough information. Is this a plugin you made? If not what plugin, in what instances does it lag?

 

[Poryg]

How do you expect us to help? You've hardly provided any necessary information.

What we don't know is:
Your engine. Not just MV version, which would be natural, but also what kinds of changes you made. What plugins you use. And from the looks of it, you developed your own stuff as well, since UHPD is not something in default engine.
Your computer specifications, which are VERY important!

Anyway...
You say you have planted 3920 trees. Which is an insane number. Did you use one texture for all these sprites or did you create 3920 textures and created sprites from them? This is also very important! The former is hard on performance, but soft on memory. The latter is harder on memory, but softer on performance.
Also, as you can see, the map is running on Canvas mode. Canvas2D, however, is rendered by CPU, which is not made for graphics rendering and hence is 4x slower than GPU rendered graphics. If you add to that the fact that Javascript is single threaded, there's really not much space UNLESS you can get the GPU to render the graphics.
But the GPU will render the graphics ONLY in WebGL mode, which the graphics card HAS to support. For the record, WebGL is equivalent to OpenGL v4.2. If your GPU doesn't support OpenGL 4.2, it doesn't support WebGL and hence will only render canvas2D... Which is slow. And as such it's only natural you have 7 FPS in your current example.

I'm not going to add any more info unless I see more info from you.

 

[LTN Games]

Just to clarify on the opengl version required, you don't need v4.2 my guess is as long as you have opengl v2.0 or greater, or at least 3.0 not sure exactly, but since I have v3.3 and MV runs WebGL perfectly fine I assume as long as you have 3.0 and greater then you're good.

As for your issues with performance, it appears you placing trees (as images) on the map and adding that many images will surly cause problems with performance on any game engine, and in canvas mode I'm surprised you even get 7fps Seriously you need to get out of canvas mode before you see any improvements in performance.

 

[kenjivn14]

@MushroomCake28 ,@elpeleq42 I have updated more information. I am developing a plugin
I want it to work well on mobile, as far as I know mobile is not run by webgl, so I have rendered by Canvas
@LTN Games I'm using: GL Version WebGL 2.0 (OpenGL ES 3.0 Chromium) /
@Poryg I loaded a picture and texture it with 3920 time. push it into const arr = [] length 3920. Each element is Class/ ( new UHPD_MapObject)

 

[MushroomCake28]

Is 39% with your cpu really that bad? Sorry I don't have have access to a low tier cpu to test my plugins, but if you can test with an average i5, or even i3, or a modern ryzen cpu to see the cpu usage and the number of fps you get that would be nice. But since you want to deploy for mobile, you'll need to optimize your code.

I would suggest to reduce the number of time you call the texture. Is 3920 times even necessary? I'm not sure if you're drawing 3920 trees or something else, but can you even see everything on the screen. Reduce that number to 100 and see how many fps you get. There's a reason why MV limits a map size the 256x256, and its for lighter rendering on mobile.

Also, is it redrawing the textures every frame? If you do it only when initializing a map, you have have a temporary fps drop, which shouldn't be too much of a problem. But if you're getting a constant 7 fps, and it's not a memory bottleneck, then it means that it's a cpu bottleneck, so you're probably updating something you shouldn't every frame. But then again, you're the one who coded your plugin, so you know your code better than anyone else.

 

[Poryg]

@MushroomCake28 The OP is doing a benchmark I reckon.

I want it to work well on mobile, as far as I know mobile is not run by webgl, so I have rendered by Canvas

Actually, modern android devices handle WebGL quite well and from iPhone 7 even apple supports WebGL. So I wouldn't be worried about that.
In fact even my Android 5.1 tablet handles WebGL and can render WebGL with no issues. And it's 2 years old.
Nevertheless, it's not a good idea to make an MV game for mobiles. And here's why.
1. Javascript is SINGLE threaded. That means you can only use ONE CPU thread for Javascript. It's true that web workers exist to mitigate this problem, but as far as I know, they're not supported by Android. Even if they were though, mobile CPUs have such low power that you can't ever hope to draw nearly as much on a mobile as on a PC. Especially with all these background tasks Androids are always devoted to.
2. Android devices have problems with ogg and m4a files in MV games. Not sure why, whether it's bad support for WebAudio (the difference between WebAudio and HTML5Audio is, WebAudio needs to load the entire music file before it can be played).
3. Android files are very difficult to support, because what's a bug on one device may not be a bug on another one. Especially if you count in the fact that an android HTML5 app is just a wrapper to be used by the device's default browser, which...... Welllll.... Sucks.

Anyway, here's my couple of tips to speed up the drawing:

1. Do NOT draw crazy amounts of graphics! Nearly 4000 trees is a lot even for GPUs. Even my WebGL rendered graphics reach 40% use at 4000 sprites. Mobiles don't even have dedicated GPUs and their CPU single core power is very weak!
2. Focus primarily on WebGL, canvas is slow! For the record, apart from the fact that it's rendered on CPU, it also renderes graphics pixel by pixel, which is inefficient. OpenGL renders graphics by grouping pixels together in triangles (fragments), which saves time.
3. Have a system that sets renderable to false for everything that is off screen. PIXI renders everything that's renderable regardless if it's visible or not.
4. RPG maker MV's default engine is poorly optimized. I highly suggest optimizing it if you want to make a mobile game. Maybe you can solve the audio issues as well.

 

[kenjivn14]

@Poryg @MushroomCake28 Thanks for the explanation let me know.
Now I'll try again, if I can't deploy on mobile. I'll switch to another engine.

 

[Poryg]

Why would it be so much of an advantage to deploy on mobiles? Mobile market is heavily oversaturated.

 

[bgillisp]

@Poryg : The sound issue on android is confirmed to be a bug in the OS on newer phones and not an MV issue. This is per a post by Archeia a few days ago. So really everyone is just waiting for Android to fix their code now.

 

[hyuugacln]

3. Have a system that sets renderable to false for everything that is off screen. PIXI renders everything that's renderable regardless if it's visible or not.

Any system you could reccomend for this?

 

[Poryg]

I don't know of any in current existence, but generally the basic one consists of adding one if into Sprite.prototype.update:
if it's screen X is below 0 or above width or screen Y is less than 0 or above window height, it sets its renderable to false. In the opposite case it sets renderable to true.

 

[Fornoreason1000]

even on Desktop / Web , 4000 Objects is extreme, you want to use some kinda of Frustum culling, as Poryg said.

in my experience Crosswalk has many many problems when it comes to ES6 in some cases ES5,
this means Web Workers will not be coming to MV for Android anytime soon. heck i had a lot of trouble getting WebAudio to work because i forgot it used to be called webkitAudioContext 4 years ago (I've seen AudioContext being used as far back as 2013, so the Crosswalk MV uses for Android could be much older).

and yet again as @Poryg said, MV will run poorly on Android without some heavy optimization. in my experience even a decent Gaming PC will drop loads of frames between scenes. this is due to the single threaded nature of JavaScript, anything and everything (Except WebAudio's processing graph which generally miles a head of JS anyway) that takes more than a total 16ms will slow the game down. loading a 40x40 Map can take 40-80ms on a 4.7Ghz processor on a SSD drive. assigning a very large array value will also do it. creating thousand of objects will do the same thing.
MV in the past had support for HTML5 Audio specifically for Android because decodeAudioData took a few minutes to finish on larger files. but it was changed in 1.5 assuming due to the lack of features HTML5 had such as seamless looping and pitch shifting. HTML5 audio will also stutter whenever MV's frames drop unlike Web Audio

1. if you need an object don't destroy it and recreate it.
2. avoid unnecessary mass creation of objects.
3. with the frustum culling be sure to take the boundingbox or size of a sprite into consideration.
4. here is a link to another guy who wanted to get frustum culling in PIXI:
http://www.html5gamedevs.com/topic/31540-how-to-cull-objects-out-of-camera-view/
5. as said before WebAudio can take a while before it is ready to play, so be sure to preload the file at least 10-15 seconds in advance before you need it. you will need a plugin for this.
6. if you don't need an object, don't create one.
7. if you need something heavy in the future, try splits the load over multiple frames in advance

 

[kenjivn14]

Why would it be so much of an advantage to deploy on mobiles? Mobile market is heavily oversaturated.

My game is of type game loops. And I think it's appropriate to deploy on mobile. Maybe I'll publish it first on pc, see how people react. Then I'll continue to deploy it

even on Desktop / Web , 4000 Objects is extreme, you want to use some kinda of Frustum culling, as Poryg said.

4. here is a link to another guy who wanted to get frustum culling in PIXI:
http://www.html5gamedevs.com/topic/31540-how-to-cull-objects-out-of-camera-view/

This is a very good thing for me to seek ways to solve the problem I'll try to apply it on my plugin. Thanks!
This is the second test