Do you have an android phone? It is the same. They have no modified it at all apart from the resolution(as far as I have noticed). Android uses webkit for rendering. The javascript engine I am not really clear on. I would think v8 given that it is googles javascript engine. Though I am unsure about that. If you are using a cross browser library or writing for cross browser it will not matter.
all of them will wrap up your tech layer into a packaged product. Not having an Ouya I can't verify the results.
Nothing currently supports WebGL, just Canvas. However, CocoonJS will be supporting WebGL in the near future. I'm hoping they will release that in May :) along with Ouya support.
I'm currently trying to replace the default Webview with Chromeview https://github.com/pwnall/chromeview however there looks to be a conflict with the Guava library. (Don't quote me however, my Java is seriously lacking and I may not be interpreting the results correctly.)
Assuming we could get Chromeview working, WebGL on the OUYA may not need to wait for Google to replace the default browser.
ooooh. going to get Chromeview working. Nice touch. I think Ash at Scirra would like to see that result. I think it`s a good idea. Though I believe Chromeview WebGl is a still on the slow side, but it`s a stable FPS where as Canvas isn`t.
Unfortunately I wasn't able to figure out chromeview. That said I have made a bit of progress using android-chromium-view.
Currently I can open the view and browse to chrome://gpu or get.webgl.org - both of which report that WebGL is enabled. Unfortunately I don't see the spinning cube on the webgl test page.
Without devtools I'm blocked but there is an open issue for that. Also, it looks like Mozilla wants to provide a GeckoView in the future.
So the issue I opened on android-chromium-view has been closed. :D
Now that remote debugging can be enabled, I'll be back looking at WebGL over the next few days (with a bonus... but more on that in a new thread soon.)
Hey, so how is every coming over all? I heard at one point you had an HTML5 game going. How hard is that. Is the controller W3C standard? is there store support?
It's coming, albeit slowly. Much more slowly that I'd hoped (primarily due to a lack of free time). I wish I had a better handle on Java, that's for sure.
TicTacToe (which formed the basis of Blip, my soon-to-be-released HTML5 Eclipse project generator) works well enough to prove it can be done. In any event, a nephew of mine seems to be particularly fond of the game, so I'll take that as a win. :)
The controllers do not tie into the Gamepad API unfortunately. One day hopefully. As it currently stands, dev's can poll for controller states from JavaScript (sync), or alternatively subscribe to pub/sub messages (async).
Comments
Android uses webkit for rendering. The javascript engine I am not really clear on. I would think v8 given that it is googles javascript engine. Though I am unsure about that. If you are using a cross browser library or writing for cross browser it will not matter.
I suggest checking into
Game Closure
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].