Another new reason why your JavaScript doesn't work
Posted on:February 11 2010
When I released CopperLicht a few days ago, it didn't work on some Mac OS X systems, but this has been fixed now. So what could possible make a JavaScript library which works perfectly on Windows and Linux not work in the same browsers (Chrome, Safari, Firefox) on Mac OS X?
CopperLicht uses WebGL to render 3d graphics, and uses GLSL shaders to do this. GLSL shaders are simple programs which are sent to the graphics drivers, which then compiles these and runs them on the GPU. One of the major benefits of GLSL is, as quoted from the Wikipedia page:
But since I now found and fixed the bug which caused CopperLicht not to work on MacOSX, I can say this statement is not true. Different graphics driver, different shader features you can use. Appearently the compilers in different graphic drivers currently don't even agree if you can multiply a vec4 with an integer or not. Which caused CopperLicht to tragically fail on Mac OS X systems with a driver which didn't want you to multiply vec4's with integers.
Great, so I guess testing if your javaScript works on different browsers now has been taken to the next level. You also need to check operating systems and installed graphic drivers!
Anyway, so if you are going to write a game using WebGL in JavaScript, you can circumvent this by using a 3d engine like CopperLicht. The engine developers (== me) will be taking care of this :)
CopperLicht uses WebGL to render 3d graphics, and uses GLSL shaders to do this. GLSL shaders are simple programs which are sent to the graphics drivers, which then compiles these and runs them on the GPU. One of the major benefits of GLSL is, as quoted from the Wikipedia page:
Cross platform compatibility on multiple operating systems, including Linux, Mac OS and Windows.
But since I now found and fixed the bug which caused CopperLicht not to work on MacOSX, I can say this statement is not true. Different graphics driver, different shader features you can use. Appearently the compilers in different graphic drivers currently don't even agree if you can multiply a vec4 with an integer or not. Which caused CopperLicht to tragically fail on Mac OS X systems with a driver which didn't want you to multiply vec4's with integers.
Great, so I guess testing if your javaScript works on different browsers now has been taken to the next level. You also need to check operating systems and installed graphic drivers!
Anyway, so if you are going to write a game using WebGL in JavaScript, you can circumvent this by using a 3d engine like CopperLicht. The engine developers (== me) will be taking care of this :)
Comments:
It is completely normal to not allow multiplication vec4 with integer to vec4. GLSL 1.10.59 and 1.20.8 specifications doesn't specify that implicit casting is allowed. It is bug in software if it assumes it can convert.
bubu
Quote2010-02-11 12:24:00
The difference is only between writing
x * 5
and
x * 5.0
so, it should be possible for the compiler to do this, without any side effects, i guess. not sure what the specification says, but on windows, all implementations allow that.
x * 5
and
x * 5.0
so, it should be possible for the compiler to do this, without any side effects, i guess. not sure what the specification says, but on windows, all implementations allow that.
niko
Quote2010-02-11 12:45:00
"... The engine developers (== me) will be taking care of this"
That's what I want from a cross platform solution: Protect me from platform details. I'm appreciating this.
That's what I want from a cross platform solution: Protect me from platform details. I'm appreciating this.
hermitC
Quote2010-02-11 12:53:00
That's one of the reasons why I once switched from GLSL to CG / DX and HLSL - because the GLSL compilers have to be built by the graphic card vendors and you can't rely on the same behaviour across different vendors or even across different driver versions.
einWikinger
Quote2010-02-11 14:58:00
Yep, GLSL has easily the biggest variance across machines - compile and link errors and runtime behaviour can all change. nvidia are always more lenient than ati, for example allowing some Cg/HLSL constructs like mul() to work even though they're not in the spec. Also conversions are more lenient so you can do "gl_FragColor = vec4(var_depth.xxx, 1);" on nvidia but you have to do "gl_FragColor = vec4(var_depth.x, var_depth.x, var_depth.x, 1);" on ati. I've talked to ati about it and they're actually working on making their drivers a bit more forgiving too just to make developers lives easier when porting.
steve
Quote2010-02-11 15:24:00
Just one question Niko...when do you sleep? Nice work again
Carlos
Quote2010-02-11 21:27:00
Are you using #version on your glsl shaders? Because on my pc everything worked without the glsl version declartion but on the mac it just exploaded. After reading a bit i realized that nv docs suggest you to use #version on glsl because than their compiler are more standard conform. Also using #version 120 would give you warnings when you compile x * 5 on the pc (at least mine does)
wolfmanfx
Quote2010-02-12 08:43:00
sleep? ha. :)
@wolmanfx: ah, that's a good idea, I'll try that out.
@wolmanfx: ah, that's a good idea, I'll try that out.
niko
Quote2010-02-12 08:45:00
Float * integer is not allowed on my windows implementation. But just cast all the time and you're fine!
xDan
Quote2010-02-13 19:59:00
I am very disappointed how your new projects seem to abandon open source. Shame on you
moo
Quote2010-02-17 12:04:00
so, moo, how many successful open source projects did you start? I guess niko did quite a few more than you.
dan
Quote2010-02-17 13:26:00
Add comment:
|
|
Possible Codes
| Feature | Code |
| Link | [url] www.example.com [/url] |
| Bold | [b]bold text[/b] |
| Quote | [quote]quoted text[/quote] |
| Code | [code]source code[/code] |
Emoticons
 |  |  |  |  |  |  |  |
 |  |  |  |  |