Problem with WebGL (black background) fix included with speed bonus

[jonpatterns]

I found the potential problem with the black play area.

The latest version of Awesome Game did not load the background image on Firefox, it showed everything else (ie. character tiles hud etc).

In the web console I got about 3x:

Error: WebGL: Error during native OpenGL init.

It seems there is a problem somewhere between WebGL, Firefox and my graphics hardware (Mesa DRI Intel(R) 915G x86/MMX/SSE2, 2.1 Mesa 11.2.2).

Going to to 'about:config' in Firefox and setting 'webgl.disabled' to 'true' allows the background to be loaded. As a bonus the game runs much faster.

Interestingly, on Seamonkey and Chromium the game works, but is a little slow (i haven't tried disabling WebGL on these browsers).

[I'm using an up to date version of Manjaro Openbox (Linux).]

[jimfrize]

@jonpatterns Very interesting, maybe webGL is not the best option then. I noticed that my CPU ussage is really high, at one point firefox peaked at over 70% it normally doesn't go much over 20%. I've also noticed that my fans are spooling up and the base of my laptop is getting hot, the only other time my laptop does that is when I'm rendering out HD video!

The background image is 1920 × 672 px and it's pasted a few times to cover the whole map, but I made the file a low quality GIF, it's only 149KB. The whole resources folder is only 4.9MB.

@metalx1000 Maybe we could default to using Canvas rather than WebGL? - I'll test it now and see if it improves the CPU load.

I could also refactor some of the code, so there's as little as possible in the update functions?

[jimfrize]

Okay, so Canvas uses less CPU on my system. Compared to WebGL, the CPU usage fluctuates less and on average the useage is 20% lower.

[metalx1000]

That is really odd. I was always under the impression that if your system can use webGL it was a better option, that's why the 'AUTO' we have set defaults to webGL. I'll have to look into this more.

Also, the background image is beautiful, but maybe we should look into turning it into a tilemap image.

[metalx1000]

For now I've disabled the background, just for testing. I also started adding a few new tiles in case we decided to go that way.

[jimfrize]

It seems to make the same sort of difference as changing to Canvas. Maybe the .GIF format is the problem, I can make a replacement tileset for now. I might look into using an image again in the future, I would still like to have a scrolling background - but I guess there's plenty of other things to do first :)

[metalx1000]

Yeah, I would love to keep using your background, I like it a lot. I also thought maybe the gif format was the problem. I don't see why it would be, but maybe we can convert it to a png and see if that makes a difference.

I'll also be testing everything out on my mobile devices more now that I have the basic on screen controls made. I have them set to only should up on mobile devices. So let me know if you try it on any tablets/phones and the controls don't show up or work correctly.

[jimfrize]

@metalx1000 Okay, tested using a .PNG for the background. It's worse! 75% CPU usage nominal! Tried scaling the image down to a quater of the size, then scaling it back up agian in Phaser, it was a little better, but still not great (around 65%).

Also been looking at some example code to see if I can shed any light on this.

This runs fine (< 20%) : http://www.goodboydigital.com/pixijs/examples/19/ This one too: http://www.goodboydigital.com/pixijs/examples/20/ & this one: http://www.goodboydigital.com/pixijs/examples/16/

In fact, almost all of them run okay.

But this one maxs out my CPU (Over 70%) : http://www.goodboydigital.com/pixijs/examples/lasers/

[jimfrize]

So I got the background image down to 14KB by converting it to .JPG, quatering the chroma and reducing the quality to 20%. I also loaded the image as a tileset using Tiled. This got the CPU load down to around 55%. Better, but not the massive saving I was hoping for.

[metalx1000]

We'll just have to keep playing with this. At lest we are moving in the right direction.

[jimfrize]

Here's some interesting info on Phaser performace: http://www.thebotanistgame.com/blog/2015/03/04/tuning-phaserjs-performance.html WEBGL is sometimes slower, apparently

[metalx1000]

@jimfrize ok, I set the default to canvas for now. I also just set it so that if you set the debug variable to 'true' it will display the FPS in the HUD.

[metalx1000]

And...I'm pretty sure the FPS HUD display is working. My desktop always says 60fps, which is the default max. I haven't created a way to turn it on for mobile devices. I'll probably add url variables for this sort of thing.

[metalx1000]

You can now turn on Debugging to see the FPS on screen in the HUD with URL variables. http://filmsbykris.com/scripts/Awesome-Game/?debug=true

This will help with testing performance on both desktop and mobile devices.

[metalx1000]

Sure enough, on my phone with Canvas I'm getting between 49 and 60 fps with canvas. If I switch to webGL it's all over the place, but probably averaging 20 to 30 fps, and going as low as 16 fps at times. Good catch on this guys. For now we'll stick with CANVAS.

That on my 2014 Moto G with Chrome Browser

[OneSleepyDev]

Good find! I tried this on my own game and I got much better FPS on my test phones.. Haha.

[jimfrize]

Ok, just a quick catch up before I head out. Been working on a really stripped back "sandbox" version of the game for testing and troubleshooting. Using it, I'm currently working on adding momentum to the characters walking. Got something going, will report back soon.

The Sandbox version is less than 68MB in total. While making it I have gained a better understanding of the project, it's been pretty usefull.

[metalx1000]

So, since we are using canvas now, is this an issue anymore?