Show HN: WebGL Enabler for iOS(demoseen.com)
demoseen.com
Show HN: WebGL Enabler for iOS
http://demoseen.com/webglenabler/#
59 comments
I've spent a lot of time playing with this over the last two days, and it's absolutely the implementation not being where they want it yet. There are definite stability issues with more intensive scenes, though it generally works pretty nicely. I imagine that's why they allow it for iAds, where they can monitor the quality and test it across devices. Hopefully with iOS 6 my tweak won't be needed any longer.
It's hardly a tin foil theory. Even if it isn't the primary reason WebGL isn't enabled at the moment, higher-end games moving out of the App Store and into the browser must weigh on their mind.
I wouldn't recommend using the WebGL enabling hack at present, for security reasons. But then, people who are jailbreaking their phones in the first place are probably making a different security vs. features tradeoff.
Feeding your tinfoil hat for the moment... Isn't the implementation of Angry Birds in desktop Chrome built using WebGL?
His program essentially leaks beta software for profit.
Agreed. I don't know what I'd do without the $20.60 I've made off of this (before Paypal fees)...
Would be really interesting to see how much you make off this with your donation model. I wonder how much it would affect income if you used someone other than paypal, or had several donate options.
Anyways, good on you for doing this.
Anyways, good on you for doing this.
I'm expecting that it's probably not going to go much above where it is right now (which is still twice as much as I figured it'd bring in); despite quite a few downloads from HN, no one has paid for it. That said, I'm sure I could increase paid conversions with some work, but I honestly don't care enough to do so. I built this so that I could build neat demos on my iPad, and there's no way I'll recoup the cost of 5 or so hours of dev time I spent on this. I'm just glad that it's working well for people.
...except you don't have to pay a cent for it.
I submitted this a couple days ago at a pretty bad time (middle of the US night) and it died pretty quickly. I figured I'd wait until v0.0.2 to throw it back up here, and that's now out. It seems to be working quite nicely on all iOS 4.2+ devices, though some of the older iPhones have performance issues it seems. Hope you guys enjoy this.
Free, open-source, and ten months old.
https://github.com/rpetrich/WebGLEnabler
https://github.com/rpetrich/WebGLEnabler
I saw that after my first release, but 1) this is free-ish (you can choose to pay whatever amount you want) and open source ( https://github.com/daeken/WebGLEnabler ) as well, 2) mine works at the WebView level rather than Safari, and includes a toggle in settings.
That said, I would've used a different name had I known about that before I released.
Edit: Oh, I'm wrong. I could've sworn that his was just for Safari, but I just saw in the source that I'm wrong. He just works at the WebFrame level rather than WebView.
That said, I would've used a different name had I known about that before I released.
Edit: Oh, I'm wrong. I could've sworn that his was just for Safari, but I just saw in the source that I'm wrong. He just works at the WebFrame level rather than WebView.
Ouch, sorry for not paying better attention; I didn't notice the source to yours. Both approaches appear equally valid and yours appears to be rather more fleshed-out (what with preferences).
I didn't mean to denigrate your project, as well: I apologize if it seemed that way!
I quite enjoy seeing people use Theos/Logos as well. Definitely worth sinking my time into working on them!
I didn't mean to denigrate your project, as well: I apologize if it seemed that way!
I quite enjoy seeing people use Theos/Logos as well. Definitely worth sinking my time into working on them!
No worries. And seriously great work with Theos/Logos; I haven't touched iOS stuff since working on the unlock for the original iPhone, and I still managed to whip all of this up in ~5 hours.
One a random note, it would be cool to see AppList integrated into the preferences to allow for per-app toggling.
I thought about doing that, but at this point I don't think it'd be too terribly useful. If I do anything more with it (outside of fixing bugs if they pop up), it'll probably be to add a WebGL toggle inside of MobileSafari somewhere, for convenience.
[deleted]
This is badass! But, once again something Apple should have already given developers.
Thanks for putting this together, hopefully it spurs them along.
Thanks for putting this together, hopefully it spurs them along.
Former discussion: http://news.ycombinator.com/item?id=4029365
WebGL Enabler won't work well with all existing WebGL demos, but there's a cache of them to tryout at http://www.webgl.com and http://www.chromeexperiments.com
Two things to note about testing existing demos/games: 1) It supports 0 vertex shader texture units, which breaks some of the more interesting demos (I think this is an implementation thing, rather than a hardware limitation, at least on the higher end devices; the iPad 3 has to support this stuff), 2) Most demos and games use onmousedown/move/up rather than ontouch*, which causes them to break. I'm trying to come up with a decent solution to run these existing demos.
I know jailbreaking doesn't immediately imply piracy, but this is another example in the fine tradition of pirates getting the better product. The recent Quasar window manager for iOS is another example.
Like how Apple has sabotaged the use of HTML5 Audio, I think it is unlikely they will enable WebGL. It provides developers an open platform for developing games, which conflicts with Apple's closed system agenda.
How have they sabotaged HTML Audio?
The biggest problem is definitely not the lack of OGG support but the disabling of autoplay on iOS: http://weblogs.vpro.nl/digitaal/2011/11/04/why-html5-audiovi...
Disabling autoplay on iOS is not unreasonable. I don't want autoplay anywhere, but I really would not expect opening a web page on my phone to start blaring random audio out the speakers. I wouldn't call that "sabotage", I'd call that "someone actually cares about what users expect". (That's leaving alone data concerns, especially with limited and expensive 3G data plans.)
Theres no reason this couldn't be a user permissions thing like the geolocation API's. If the user wants a particular page to have autoplay enabled, then the user should have the choice.
They could always allow you to mute sites by default. You see to be overly optimistic that they are doing it for the users good.
How is "mute by default" different from "no autoplay" except that when users actually hit play, it would just start somewhere in the middle? (That sounds like an even worse user experience.)
It would be "no autoplay by default" instead of "mute by default".
the difference is that in the "no autoplay ever" case I would be not able to enable it if I wanted. "No autoplay by default" is the reasonable initial setting, while still giving users a choice.
the difference is that in the "no autoplay ever" case I would be not able to enable it if I wanted. "No autoplay by default" is the reasonable initial setting, while still giving users a choice.
Settings -> Safari -> Audio -> On/Off, or with a permissions dialog
There is no good reason to have Audio off by default and have no way to turn it on for games.
There is no good reason to have Audio off by default and have no way to turn it on for games.
By not supporting Ogg Vorbis on Desktop and totally fucking it up on Mobile on purpose:
http://www.phoboslab.org/log/2011/03/the-state-of-html5-audi... (Year old, but still valid)
http://www.phoboslab.org/log/2011/03/the-state-of-html5-audi... (Year old, but still valid)
I don't really call 'not supporting Ogg' sabotage. Joe Public doesn't care about Ogg. Never has, never will. How is not supporting Ogg for <audio> tags when the spec for <audio> tags doesn't require it 'sabotage'? The requirement for HTML5 to support Ogg was dropped very early on in 2007. It's not part of the standard.
Apple have been fairly supportive of WebGL: it's been in the WebKit nightly builds for almost three years now, of which Apple are a major contributor. You can accuse Apple of many things, but given how they've been part of the WebGL Working Group from its formation I'm not so sure you can say they're out to 'get' WebGL...
Apple have been fairly supportive of WebGL: it's been in the WebKit nightly builds for almost three years now, of which Apple are a major contributor. You can accuse Apple of many things, but given how they've been part of the WebGL Working Group from its formation I'm not so sure you can say they're out to 'get' WebGL...
Joe Public didn't care about AAC and Apple Lossless either before Apple started heavily pushing them on the iTunes Music Store. Apple doesn't use popularity as its metric when determining which formats to back.
> Joe Public doesn't care about Ogg
But developers care, a lot. You have no idea how many popular games use Ogg internally.
Here's a small list: http://wiki.xiph.org/index.php/Games_that_use_Vorbis
Looking at the games, I wouldn't be surprised if a billion copies have been sold to date.
But developers care, a lot. You have no idea how many popular games use Ogg internally.
Here's a small list: http://wiki.xiph.org/index.php/Games_that_use_Vorbis
Looking at the games, I wouldn't be surprised if a billion copies have been sold to date.
Do you know why games use Ogg internally? Is it just licensing or does Ogg have some technical advantage for them?
Audio cannot be played automatically -only when a user event occurs.
Audio cannot be streamed playlist-style, one after the other - again, it always requires user input.
So this screws things up completely for html5-based games with audio.
Audio cannot be streamed playlist-style, one after the other - again, it always requires user input.
So this screws things up completely for html5-based games with audio.
It's impossible to build an iOS game for Safari that has sound. They've limited the API by only allowing a single audio channel that can only be used during touchscreen actions. You can't programmatically play a sound, eg like when a collision occurs.
To be fair, audio support on all web browsers was an awful embarrassment, especially on mobile, until just recently. Thankfully recent versions of Chrome and Firefox are changing things, and I expect Safari (both Mac and iOS) will soon improve.
Hell, it's not like Android is a shining example of audio support: http://code.google.com/p/android/issues/detail?id=9372
Hell, it's not like Android is a shining example of audio support: http://code.google.com/p/android/issues/detail?id=9372
No, HTML5 audio actually kind of worked in iOS 3. But Apple plugged that whole and made sure it was fully sabotaged in iOS 4.
I think you're coloring Apple to be far more nefarious than they actually are. For many people, the change to only load media in response to a user's explicit action is a huge step forward, as they can confidentially browse over cellular networks without blowing out their bandwidth cap. As a user, I definitely appreciate that behavior.
And don't think I'm not affected as a developer – all the time people use our product, Hype, to create content that includes audio and video elements, and we're stuck explaining to them the behavioral differences between desktop and mobile browsers.
Apple's not evil; they're pragmatic. Right now, users needs win in this situation. Hopefully we get a more flexible solution in iOS 6.
And don't think I'm not affected as a developer – all the time people use our product, Hype, to create content that includes audio and video elements, and we're stuck explaining to them the behavioral differences between desktop and mobile browsers.
Apple's not evil; they're pragmatic. Right now, users needs win in this situation. Hopefully we get a more flexible solution in iOS 6.
Apple has helped keep OpenGL alive. Microsoft is the company that simply refuses to support it. Think we'll be seeing WebGL on IE anytime soon? Microsoft could have gone with OpenGL but they invented DirectX instead on the desktop. Apple does support OpenGL on their phone, it's just not in the browser, so I would think writing games for Android and iOS should be doable, right? Windows Phone 8? Probably not.
You're encouraging people to pay for this internal setting toggle, that Apple didn't default to 'On' for a reason (not being finished)? Where is the value in this? You are basically charging for Apples incomplete software.
The value is that people want to use WebGL now, as seen by the almost 1000 people who have downloaded the software over the last few days. However, I have no idea how one can put a price on something of this sort, which is why you could pay $0 or $500 for it if you want. I tend to believe that saving people from a couple of hours of tinkering (writing the same tweak I have, basically) is worth at least $1, but people have thrown in anywhere from $0.10 to $5.
But they're not "using" WebGL other than seeing a demo of it. There's absolutely no interaction. I bet at least half of your downloads expect they'll magically be able to have fully compatible WebGL games. Now that would be software worth paying for, provided it wasn't a settings toggle.
Err, what? You do have full compatibility with WebGL with this. Any failings there are on the part of games are due to a lack of proper event handling (specifically, not using ontouch* events).
And again, "worth paying for" is up to the customers. I very much encourage people to download it and then pay for it if they see value in it. So far people have seen value in it.
And again, "worth paying for" is up to the customers. I very much encourage people to download it and then pay for it if they see value in it. So far people have seen value in it.
Device data (touches, accelerometer, etc) are exactly what I meant by compatibility. Again, back to my point of it not being finished. I see that it wasn't your fault, but this is misleading and shady.
I don't think you understand. All of these things are there. In addition, these have nothing to do with WebGL. You're painting this to be something that it's very much not.
My tweak has been confirmed to work by everyone who has tried it, and it works quite nicely. You're saying that I'm being "misleading and shady", when in reality the full functionality is there.
My tweak has been confirmed to work by everyone who has tried it, and it works quite nicely. You're saying that I'm being "misleading and shady", when in reality the full functionality is there.
Oh, I do understand. Congrats on practically leaking a incomplete beta and making money off of it.
'Using' webgl is writing javascript. Text editors are widely available.
This is exclusively for jailbroken phones. Shouldn't you be more upset at the people who are jailbreaking their phones?
The reasons I can think of are:
* Performance isn't what they want yet.
* Implementation isn't what they want yet.
* There are security issues they still need to fix.
OR putting on my tin foil hat for a second:
* Apple sees WebGL as a possible threat to their app revenues as a soild WebGL implementation could allow developers to avoid entering their app market place and instead charge users directly. It would also allow developers to deploy to other platforms with the same code base.
Obviously the last point is a bit nutty but one can't help but wonder if it is a consideration.