Closed GoogleCodeExporter closed 8 years ago
Ok, I had a look at the source, and it seems that you're not blocking Firefox,
sorry!
It's just that, if I understand the code correctly, you're throwing exceptions
on
every GL error, and we hit GL errors on Firefox :) Unfortunately this makes it
super
hard for me to debug, as the GL errors don't get a chance to show up in the
error
console. Can you help me by telling me how to disable this behavior?
Original comment by jacob.be...@gmail.com
on 3 Jun 2010 at 1:15
Update. Here in Firefox (Minefield), Quake2-GWT does *not even attempt* to
create a
WebGL context. Yet the error page says "WebGL support required". So at the very
least, the error message seems wrong :)
Original comment by jacob.be...@gmail.com
on 7 Jun 2010 at 4:02
same here
i'm using Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a6pre)
Gecko/20100618 Minefield/3.7a6pre
and i activate webgl via about:config. some webgl demos work fine but my local
quake2-gwt just shows typical error page (webgl support required ....)
in error console i found no error or warning. there is no entry at all.
Original comment by sebastia...@googlemail.com
on 19 Jun 2010 at 8:13
This has been further investigated; it turns out that the reason is that
quake2-gwt is trying first the "webgl" canvas-id, without trying to catch
exceptions. We don't support the "webgl" canvas id, because the WebGL spec is
not yet final, so with other browser makers we agreed to support the
"experimental-webgl" canvas id. So what happens is that when quake2-gwt tries
"webgl", we throw an exception, and it isn't caught. Quake2-gwt really needs to
be fixed: it shouldn't assume that trying the currently illegal "webgl" id
won't cause an exception. See e.g. how it's handled in the WebGL conformance
tests: exceptions are caught (and "experimental-webgl" is tried first):
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conforma
nce/resources/webgl-test.js
function create3DContext(canvas)
{
if (!canvas)
canvas = document.createElement("canvas");
var context = null;
try {
context = canvas.getContext("experimental-webgl");
} catch(e) {}
if (!context) {
try {
context = canvas.getContext("webkit-3d");
} catch(e) {}
}
if (!context) {
try {
context = canvas.getContext("moz-webgl");
} catch(e) {}
}
if (!context) {
throw "Unable to fetch WebGL rendering context for Canvas";
}
return context;
}
Editing quake2-gwt to try "experimental-wgl" first (or catch exceptions), and
other tweaks, allow to get all the way to the game main menu, where we stop on
another exception, caused this time (as far as I understand) by quake2-gwt
converting all OpenGL errors into exceptions (which pretty much guarantees that
no other experimental webgl implementation than webkit's can run it, since the
GL error reporting hasn't yet been fully harmonized across WebGL
implementations --- we're working on that closely with google and apple on the
public_webgl list, but that takes time).
See this for further info & discussion:
https://bugzilla.mozilla.org/show_bug.cgi?id=557423
Original comment by jacob.be...@gmail.com
on 22 Jun 2010 at 9:23
Update: with the patch by Barak, (attached to
https://bugzilla.mozilla.org/show_bug.cgi?id=557423) quake2 is actually running
in Minefield! So what I wrote above about GL errors was probably wrong.
Original comment by jacob.be...@gmail.com
on 22 Jun 2010 at 11:19
a firefox howto can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=557423#c44
Original comment by jacob.be...@gmail.com
on 23 Jun 2010 at 1:39
Hi,
thanks for looking into this!
I have changed the WebGL context creation code (try/catch block,
experimental-webgl first) and added a check whether the console is present
before logging to the console. However, I still get the error message in FF
(Minefield/3.7a5pre GTB7.1). Not sure why the console is not present despite
firebug...
Is there anything else we can do on our side to make this work in minefield?
Stefan
Original comment by stefan.haustein
on 5 Jul 2010 at 11:39
Hi Stefan,
I wrote some of the patch that Jacob linked to (sorry for all the mess :)).
Anyway, I had the same problem you have, I assume you're using the latest
Firebug development version from
http://getfirebug.com/releases/firebug/1.6X/?C=M;O=A
For whatever reason the latest version doesn't seem to "kick in" after enabling
the console (I'll probably file a bug on that- if there isn't one already open)
- I have no idea in which version this regression happened so I just use the
first development version there (firebug-1.6X.0a1.xpi)... it seems to work fine
If you need any more info feel free to page me :)
Original comment by smoo...@gmail.com
on 6 Jul 2010 at 8:59
Ah, sorry, somehow had overlooked the diff:
https://bug557423.bugzilla.mozilla.org/attachment.cgi?id=453036
The main problem is that it seems a bit aggressive, i.e. it looks like it may
break Chrome -- and it contains a lot of stuff that is commented out. So I
cannot just patch it in and commit the new code... I will try to carry over
some more of the changes during the next days. Of course any help (like a
cleaner patch that has some kind of "if (firefox)" where necessary) is welcome!
:)
Original comment by stefan.haustein
on 6 Jul 2010 at 9:38
Hi, Thanks Stefan for handling this; not much to add since smoohta==Barak is
the author of the patch :)
I hope a good cross-browser solution can be found; Stefan: you can easily test
code in Minefield by using nightly builds.
Original comment by jacob.be...@gmail.com
on 6 Jul 2010 at 10:21
Stefan- I know, that's what I meant by the "sorry for all the mess" comment :)
Here is a much much cleaner patch, a couple of notes:
1. As you can see the main change is in render/gl/Main.java - wrapped with
(isFirefox) as you suggested.
Another change in Main.java is a check before the gl_config.extensions_string
is parsed (since Firefox doesn't expose the client's GL extensions) - the diff
makes it look awful but all it is a if (gl_config.extensions_string != null)
before and an else { ... } after :)
2. At some point, Firefox switched from getting GL Parameters through
glGetString to glGetParameter (per the WebGL specification, as Jacob explained
it) so I've added a glGetParameter method to the GLAdapter class (to
complement/replace glGetString).
Depending on the nightly version you may or may not need to use this method
instead of the former...
3. If you're using the Firebug console to debug, the game will work fine until
you try to start a game.
This is because Firebug/Firefox currently has a bug- if Firebug is enabled XHR
callbacks aren't called (see Firefox bug if you're interested) so all the
resource loading won't work unless you disable Firebug :(
Another problem is that for some reason, the "default" generated code has a
call for Console (haven't found where) so the current workaround is to strip
out all the Console calls out of the generated HTML before running the server
(see Jacob's link).
Original comment by smoo...@gmail.com
on 6 Jul 2010 at 11:19
Attachments:
Hi Barak,
thanks for the updated fix! A lot of issues should be gone if you update to
mainline. In particular, I have added a check wether window.console is there
before using it. I'll take a look at the getString vs. getParameter issue.
Original comment by stefan.haustein
on 6 Jul 2010 at 11:34
Update: Works in current nightly of Minefield/4.0b2pre now.
Thanks again for the hints/patches!
Original comment by stefan.haustein
on 7 Jul 2010 at 1:29
Sure, great to see it working out of the box :D
Thanks for fixing this properly :)
Original comment by smoo...@gmail.com
on 7 Jul 2010 at 7:24
Wow, this is awesome indeed!
I'm at the Mozilla Summit right now, people will love this :)
Original comment by jacob.be...@gmail.com
on 7 Jul 2010 at 5:29
Original issue reported on code.google.com by
jacob.be...@gmail.com
on 15 May 2010 at 3:13