snowkit / snow

A low level cross platform framework for Haxe. Mac, Windows, Linux, Android, iOS, WebGL.
http://snowkit.org/snow
MIT License
133 stars 35 forks source link

native and web; GLUniformLocation inconsistent behavior #67

Closed haxiomic closed 9 years ago

haxiomic commented 9 years ago

On web, null is returned if getUniformLocation fails, whereas on native, -1 is returned, consequently there's no platform independent way to check if a GLUniformLocation is valid.

I've been using this abstract in native/render/opengl/GL.hx (newtypedarray branch) that treats GLUniformLocation as a Null checks if its value is -1 when comparing with null

abstract GLUniformLocation(Null<Int>) from Int{
    @:op(A == B) inline public function equality(rhs:Null<Int>) return rhs == null ? this < 0 : this == rhs; //allow for comparison with null
    @:op(A != B) inline public function invEquality(rhs:Null<Int>) return !equality(rhs);
    @:to inline public function toInt():Int return this == null ? -1 : this;
}

I suspect it's not bullet proof but do you think this is the right approach?

ruby0x1 commented 9 years ago

The right place to check for the correct behaviour is the WebGL spec

The return value is null if name does not correspond to an active uniform variable in the passed program. Returns null if name starts with one of the reserved WebGL prefixes per GLSL Constructs. Returns null if any OpenGL errors are generated during the execution of this function.

ruby0x1 commented 9 years ago

But keep this issue open, I'll take a look at matching the spec on native in the best way for the future changes (native stuff)