Fps dropping on web hosted game

[PresaDePrata]

I wasn't sure if this topic should be on support or deploy, but here we go.


Hi,


I have a hosted demo of my game, where i'm putting everything i have to test it first. Plugins, images, musics, movies, the whole thing. This is to narrow down any error on an easier way before i start to unite all these assets on an actual game. I test all my game demo on a cloud based server which is pretty good.


While testing, i noticed a sudden drop of fps after some iterations (i'm adding a fake story just to amuse me) of adding plugin and others stuff. While i tried to understand why it was falling down, i realized that opening and closing the characters menu would drop the fps drastically. Not only dropped it, but remained low making the game almost unplayable. But here comes the odd thing, opening and closing it a few times would restore the fps to normal levels (60). Actually any map changes has the possibility to either drop or restore the fps. On battles it remained stable at 60.


This only occurs on my hosted game. IN local dev, it works perfectly. The fps drops occurs after opening and closing the menu, but it always restore to 60 fps. This, however, won't happen in the hosted demo game. I even got some demos, the largest being Moghunter's demo (which is heavy graphical), hosted on my website just to make sure it was my project. It wasn't, on their demos the fps drop would still occur.


Do you know why? I really don't know what do right now..


ps. = if you're interested in helping me, i can provide you the link of my demo game for you to see for yourself.

 

[KisaiTenshi]

It's likely that opening the menus is causing a network (probably an audio file) pull. Setup caching directives on your server (expires 30 minutes, or set up etags) to try and solve that.


Remember that any difference in behavior from running it locally and remotely is attributed entirely to the network connection. If you are experiencing it, everyone who doesn't live in the city where the server is will also experience it.

 

[PresaDePrata]

It's likely that opening the menus is causing a network (probably an audio file) pull. Setup caching directives on your server (expires 30 minutes, or set up etags) to try and solve that.


Remember that any difference in behavior from running it locally and remotely is attributed entirely to the network connection. If you are experiencing it, everyone who doesn't live in the city where the server is will also experience it.

@KisaiTenshi that's new to me, that opening is causing network traffic. I thought it was something about common events or parallel processes, but then i checked ram consumption on my dev machine and was always stable. Even on local, if open and close several times a menu thr fps drops, but will restore less than a second after. Also, i don't have any music plugins on menu, but i see your point. 


Let me see if i get it, MV reloads assets every time i open a menu or enter/leave a map? Enter/leave a map i can see why, but opening a menu? If that is so, it was a bad a really bad design decision since menus, depending on how which game uses it, could be used a lot. Furthermore, shouldn't this be happening on battle too? My battles are all super stable. It has to download animations the first time they're used but then goes smoothly.


Anyway, thanks. I'll try setup this directives.  


EDIT


I went to look for network traffic and indeed the game performs a GET to pull map001.json. However it was cached and only bytes of size. The main.json is just kaspersky being intrusive. And before you think that maybe is what is causing the fps drop, it isn't. My friends have the same lag that i have and they don't have kaspersky.

 

[KisaiTenshi]

If you were running it locally, the antivirus would behave is a similar way. Typically they run both a transparent proxy LSP mode and a file scan mode, and when the web browser loads files locally it doesn't go through the transparent proxy LSP. 


But that wouldn't be the reason for the FPS drop.


If you watch the network panel, nothing on there should should have more than a 2ms load time. If the server sends "not modified" responses to eTags, or you use mod_expires to explicitly tell the browser to not come back for 30 minutes, it should leverage caching for all the files. 


Part of the reason I was evaluating RPG Maker in the first place was to see what kind of web-suitability it has, and it's really not much fault of the RPG Maker developers so much as the dependence on node-webkit (nw.js). nw.js is basically the current version of Chrome minus all the google branding and menus. So when you run a nw.js game inside Chrome, the performance should be exactly the same.


You can pop over to  chrome://gpu  to see if there are any browser-specific reasons for it to be running slower than expected.

 

[PresaDePrata]

If you were running it locally, the antivirus would behave is a similar way. Typically they run both a transparent proxy LSP mode and a file scan mode, and when the web browser loads files locally it doesn't go through the transparent proxy LSP. 


But that wouldn't be the reason for the FPS drop.


If you watch the network panel, nothing on there should should have more than a 2ms load time. If the server sends "not modified" responses to eTags, or you use mod_expires to explicitly tell the browser to not come back for 30 minutes, it should leverage caching for all the files. 


Part of the reason I was evaluating RPG Maker in the first place was to see what kind of web-suitability it has, and it's really not much fault of the RPG Maker developers so much as the dependence on node-webkit (nw.js). nw.js is basically the current version of Chrome minus all the google branding and menus. So when you run a nw.js game inside Chrome, the performance should be exactly the same.


You can pop over to  chrome://gpu  to see if there are any browser-specific reasons for it to be running slower than expected.

Thanks for your time Kisai. You seem to know a lot about web dev and ops. I myself am new to this gaming world and got my attention on rpg maker because of it's possibility to play on web. Also it was kind of a dream to build a game that suits me, even if only my friend will play it.


Motives and reasons apart, i printed the chrome gpu as you can see below. It does point to  Accelerated rasterization  being disabled and  Native GpuMemoryBuffers too. I'm a little skeptical to seeing this as part of the problem, since the game lags when entering/exiting places or opening/closing the characters menu. But i'll look into to see if it may be the problem.


And what exactly is the problem with node-webkit? I failed to understand why it would be bad for gaming development. I thought mv's problems were due PIXI's limitations.

 

[KisaiTenshi]

Basically, the dependency on node-webkit adds a large amount of overhead that isn't really used (RPG Maker MV only uses canvas and webaudio features) So when people compare previous versions of RPG Maker to MV they are disappointed that there is a 100MB overhead of disk space and 128MB of ram just to do nothing when the previous VX game engines took 138KB of disk space and 52MB of ram to do nothing. So on a high end desktop it's meaningless, but on low-end desktops/netbooks and mobile phone/tablets it matters. In fact the only platform where Node-Webkit isn't used is iOS, where it uses the native safari webkit.


So when people complain about FPS drops, not all of it is attributed to rendering, the single-threaded nature of a web-based development platform is entirely cpu bound. So Node Webkit is a general purpose "web browser" environment, where as something like Unity is a general purpose game environment, and comparing the two is like comparing pineapples to pinecones.


As I mentioned in the earlier comment, network pulls will drag down the frame rate because the javascript has to wait for the content to download before it can use it. In the case of JSON files, it absolutely needs those to be downloaded before doing something, and are frequently re-polled (I believe there's a caching plugin that attempts to migitate the audio asset pulls with pre-caching) because that is the nature of the web browser. So the best solution to making a web-hosted game behave like a local game is to ensure that all the files are cached. So you have to decide if you'd rather have more loading time, or less loading time but a lot of "background loading" that results in consuming CPU time.


Another thing I didn't mention but is a lot more obvious in a game which uses more than one tileset, is that the web browser can often only pull a maximum of 4 files at once from a web server, and then the web browser will block until those are downloaded. So even if you set the etags, if the server doesn't say "don't come back for a while" it will check every single file, every single time.

 

[PresaDePrata]

Basically, the dependency on node-webkit adds a large amount of overhead that isn't really used (RPG Maker MV only uses canvas and webaudio features) So when people compare previous versions of RPG Maker to MV they are disappointed that there is a 100MB overhead of disk space and 128MB of ram just to do nothing when the previous VX game engines took 138KB of disk space and 52MB of ram to do nothing. So on a high end desktop it's meaningless, but on low-end desktops/netbooks and mobile phone/tablets it matters. In fact the only platform where Node-Webkit isn't used is iOS, where it uses the native safari webkit.


So when people complain about FPS drops, not all of it is attributed to rendering, the single-threaded nature of a web-based development platform is entirely cpu bound. So Node Webkit is a general purpose "web browser" environment, where as something like Unity is a general purpose game environment, and comparing the two is like comparing pineapples to pinecones.


As I mentioned in the earlier comment, network pulls will drag down the frame rate because the javascript has to wait for the content to download before it can use it. In the case of JSON files, it absolutely needs those to be downloaded before doing something, and are frequently re-polled (I believe there's a caching plugin that attempts to migitate the audio asset pulls with pre-caching) because that is the nature of the web browser. So the best solution to making a web-hosted game behave like a local game is to ensure that all the files are cached. So you have to decide if you'd rather have more loading time, or less loading time but a lot of "background loading" that results in consuming CPU time.


Another thing I didn't mention but is a lot more obvious in a game which uses more than one tileset, is that the web browser can often only pull a maximum of 4 files at once from a web server, and then the web browser will block until those are downloaded. So even if you set the etags, if the server doesn't say "don't come back for a while" it will check every single file, every single time.

You should be teaching, you know? Yours have been the deepest answers i've seen lately and concerning to real, important aspects of a game.


And yeah, i figured it'd cause high loading times because of the single thread plataform. However, weren't web workers supposed to mitigated these problems? Running a self contained thread, even with restrictions would lift the heavy non graphical processment wouldn't it?


And once again, Kisai, i think about application cache. It seems the most viable thing for a web hosted game.


About those tiles, default mv implementation ask for them every single time? I mean, you enter a certain map, leave it, come back 3 minutes later and you have to get it again? Hasn't it a default cache for the images? Since they will 90% the time the largest file in a game it would be expected to cache them regurlarly. Although now that i'm thinking, the game runs solely on client side which would be the server conf's task to tell what to or not to cache. Hence the etag you mentioned times before.

 

[KisaiTenshi]

You should be teaching, you know? Yours have been the deepest answers i've seen lately and concerning to real, important aspects of a game.


And yeah, i figured it'd cause high loading times because of the single thread plataform. However, weren't web workers supposed to mitigated these problems? Running a self contained thread, even with restrictions would lift the heavy non graphical processment wouldn't it?


And once again, Kisai, i think about application cache. It seems the most viable thing for a web hosted game.


About those tiles, default mv implementation ask for them every single time? I mean, you enter a certain map, leave it, come back 3 minutes later and you have to get it again? Hasn't it a default cache for the images? Since they will 90% the time the largest file in a game it would be expected to cache them regurlarly. Although now that i'm thinking, the game runs solely on client side which would be the server conf's task to tell what to or not to cache. Hence the etag you mentioned times before.


Here's the cpu profile of the game running on its web host.

You could try the application cache, but I'm warning you in advance that it's going to result in the game taking like 20 minutes to pre-download.


Web-workers can't manipulate active data in the main thread, they can only "do something" on data passed to it and pass the data back. Basically parallelism is a problem that "web browsers" were not expected to handle, and rather push the parallelism to the underlying network, audio and GPU hardware. http://www.htmlgoodies.com/html5/client/using-web-workers-to-improve-performance-of-image-manipulation.html has an example of how to use web workers, but as for how to really use on MV, would probably require retooling how the maps are processed. Basically how MV works is it's a JSON blob and it runs a second level of processing on it for the "script" code blocks. 

 

[PresaDePrata]

You could try the application cache, but I'm warning you in advance that it's going to result in the game taking like 20 minutes to pre-download.


Web-workers can't manipulate active data in the main thread, they can only "do something" on data passed to it and pass the data back. Basically parallelism is a problem that "web browsers" were not expected to handle, and rather push the parallelism to the underlying network, audio and GPU hardware. http://www.htmlgoodies.com/html5/client/using-web-workers-to-improve-performance-of-image-manipulation.html has an example of how to use web workers, but as for how to really use on MV, would probably require retooling how the maps are processed. Basically how MV works is it's a JSON blob and it runs a second level of processing on it for the "script" code blocks. 

20 minutes? That's a lot. I mean, a lot. I was about to argue you on download time but accordingly to mozilla's site, it's being removed from web standards.


In the example you linked about web workers, the guy associates an event to notify the main function of the pixel processment. 


// Function called when a job is finished
var onWorkEnded = function (e) {
// Data is retrieved using a memory clone operation
var canvasData = e.data.result;
var index = e.data.index;

// Copying back canvas data to canvas
// If the first webworker (index 0) returns data, apply it at pixel (0, 0) onwards
// If the second webworker (index 1) returns data, apply it at pixel (0, canvas.height/4) onwards, and so on
tempContext.putImageData(canvasData, 0, blockSize * index);

finished++;

if (finished == workersCount) {
var diff = new Date() - start;
log.innerText = "Process done in " + diff + " ms";
}
};


Couldn't it be done to process auto tile stuff? Or maybe things running on background. Anyway, i digress. None of this will solve my fps drop problem


It's starting to really bug me out.


When i come with something new i'll return here. Once again, you were a great help, Kisai.

 

[Enius]

I have trouble with this code. I think it's due to the my new (!) proxy provider. Could it be the reason of problem?