Version: 4.4.50, dist: 2017-04-10 (Chrome: 56.0.2924.84)
Finally made a useful discovery - it's all about the RAM! By default you don't get much RAM allocated to the GPU, so this is what kills the WebGL usage. By running raspi-config, you can change the ram allocation to give more memory to the GPU. Updating to 256M, things are running better. Ghost shooter now hits, 40fps, and Rain Demo goes up to an astounding 7fps Having said that, if you look at the memory usage after running Chrome and the Rain Demo, the system only has 64M of RAM free! Chrome consumes a chunk of memory, and then loading a game consumes more memory, so it's all matter of juggling RAM.
I did have to monkey with some Chrome settings. I found if you even touch WebGL2, it wrecks Chrome until the next reboot. C2 now checks for WebGL2, which I believe causes the problem and makes Rain Demo fail to draw (lots of GL_OUT_OF_MEMORY errors). By turning off WebGL2 support in Chrome, via flag settings, games work again.
As a final note, I did find Super Adventure World was playable now, even getting to level 3 (which I hadn't managed to do on my PC!)
Version 4.4.50. Almost back to 4.4.34 level of support. WebGL runs again, but still a bit dodgy. Kicks out to logon screen randomly.
Bought a new SD card and went back to 4.4.34. Can now at least run (some) C2 games. I don't recommend upgrading just yet (see next update). (Minecraft doesn't run with OpenGL on). Also confirmed the Plymouth hack, so I've updated the original post with the correct format.
Thought it would be a good idea to update the OS. Sigh... Upgrading from the latest distro (4.4.34 2016-11-25) got me to 4.4.38 2016-12-15. I was hoping this would improve things - it did not. Now WebGL is even worse than before and any WebGL test crashes the OS. I've also discovered that Minecraft won't run now (didn't check in build34).
Also it looks like the plymouth hack does work when added to that single command line, so the following is now my cmdline.txt file:
plymouth.enable=0 dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p7 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
Since Santa brought me a RPi3 for Christmas, the first thing I did was try running a C2 game on it. As expected, and mentioned in Ashley's blog, it ran SLOWWW. So I went to turn on OpenGL, as described, BUT it didn't work. Trying to do a chrome://gpu wouldn't even display anything in Chromium! After some research, I found that there is one more step needed (at the moment) due to a change in PIXEL for the RPi3. You need to add the following to the \boot\cmdline.txt file, to turn off Plymouth.
Since this took some time to research, I felt it worth while to start a thread so people can have somewhere to go to keep the instructions on interacting with the Raspberry Pi up to date.
Speed definitely improves with WebGL. It's still not 60fps though.
So, to turn on the OpenGL:
[quote:3me2ase0]open a terminal and run sudo raspi-config - then in the menu that appears choose Advanced Options, GL Driver, then select Enable.
To turn off Plymouth, in the terminal, run sudo nano /boot/cmdline.txt, and add a new line with plymouth.enable=0 to the beginning of the one line in that file.
You can confirm that it works by going to address chrome://gpu in Chromium. You will see WebGL: Hardware accelerated
Be warned though. The driver definitely is not finished. I found several glitches in graphics with OpenGL on within the OS, and did end up turning it off again to get other things working (the Turtle drawing mechanism doesn't work properly with OpenGL on, and in C2, sadly Paster fails and even locked up my unit when I tried to run my puzzle-template, that relies heavily on Paster).
Interesting to know the RPi3 needs an extra step - any idea what "plymouth" is?
Also are the and [/url ] parts necessary? They look like forum BBCode rather than something you put in a config file.
Plymouth is some boot-theme that prevents all of the screen flickering during the boot phase. I'm 99% sure I tried adding the plymouth setting to the first line, without the URL tags but it didn't work, as I thought the same thing. There were several posts referencing the same line of text to add to the cmdline.txt file though, so I just put it there verbatim, and it worked. I'll update the first post if I find any refinements along the way.
I have a RPi 3B, will be sure to check this out Never tried any games on there before actually...
Develop games in your browser. Powerful, performant & highly capable.
Update in original-post.
blackhornet did you play some games from scirra arcade or just your games? could you please tell what games you played?
I tried Super Adventure World.
I tried Super Adventure World.
Did the game run OK or too slow? I am thinking to buy a raspberry PI 3 to make like an arcade machine with my C2 games
It was slow. I just did an experiment with Ghost Shooter and (GS) Rain Demo.
GS: PC 60fps, Mac 60fps, RPi 30fps
RD: PC 40fps, Mac 30fps, RPi 5fps
I tried your Monsters in the Night and it was OK, but noticeably not as quick as you'd expect.
Personally, I'd say if you have no other use for the RPi, I wouldn't bother. Especially given the newest OS update makes WebGL completely unusable.
Thanks for your answer.
I will have to think in other way on how to make my arcade or wait for like a raspberry pi 4, 5, .....
Hi guys, any update about this? I was hoping to buy a raspberry just for run my games but I would like to know what's the best export to use for better performance after one year of updates.
I haven't bothered in a while - it was just too frustrating. Ashley posted this alternative though:
https://www.scirra.com/blog/ashley/36/c ... nker-board
Thank you — Yeah the tinker board seems more performing but I am worried for how long it will be around since the community around it isn't the same as the one for the pi.
I have read many opinion in contrast with each other about the pi but it seems that with Raspian on it and the ExaGear on it, it can run quite ok Win32 games that don't require hardware acceleration, so I was wondering if exporting a game for Win32 could be a workaround.
I doubt it. You still need WebGL, and that's what the issue was. Adding yet another layer in there can only make things slower.
Edit: Actually that really makes no sense. You can already export to Linux NodeWebKit. You wouldn't export to the Windows NodeWebKit.
I haven't seen Linux in your FPS comparison, so I was wondering if there was something wrong with the exporter.
Honestly I never tried to export on Linux because I haven't any machine to test the game, but if that will do it then why not?