HxSL2 - Undocumented changes and bugs

[Sam Driver]

With the removal of the old HxSL from the Format library I've been converting my existing code over to HxSL2, and have found a few bugs and/or inconsistencies. I hope this is the right place to post them.

I'm using the latest (as of yesterday) version of HxSL installed by haxelib from github.com/ncannasse/hxsl, running the Haxe 3.0 RC, targeting Flash Player 11.4. I'm not using any other libraries.

---

In HxSL1 the following was possible:

var a:Float2 = [b.x * c.y, b.z * d.x];

In HxSL2 that still compiles but doesn't do what it used to. I'm not sure what it does do exactly, but it appears to cause changes to some of the variables b, c and d. The intended functionality can be achieved in HxSL2 with:

var a:Float2;

a.x = b.x * c.y;

a.y = b.z * d.x;

I'm not actuall sure if the example was ever correct HxSL1 code. But if the [x,y,z] syntax is meant only for defining constants then HxSL catching cases where it's used incorrectly would be helpful.

---

Undocumented change: You now need to prefix input variables with "input." to access them.

HxSL1:
out = pos * mpos * mproj

HxSL2:

out = input.pos * mpos * mproj

---

Missing functionality or undocumented change: I can't work out how to use simple fixed for loops in HxSL2.

HxSL1:

for (x in -1...2)

   colourSum += texture.get(uv + [x,0]);

HxSL2:

Gives a build error, unsupported operation on "-1...2"

---

Bug: Shaders that do not access one or more of their input variables may access other input variables incorrectly.

I have a shader with:

var input: {
   pos : Float3,
   normal : Float3,
   colour : Float3
};

But if the vertex function never uses input.normal then the shader appears to be compiled as if it's input variables were declared:

var input: {

   pos : Float3,

   colour : Float3

};

The problem is my vertex buffer still has data in it for the normal, which is now getting accessed by the shader as input.colour.

This happens when I have multiple shaders that can be run on the same vertex buffer. For instance when running two shaders on one set of data to render both a depth map for shadow mapping and a properly shaded version for display.

The bug can be worked around by making sure that each part of the input is accessed at some point in the shader, even if it does nothing:

var unusedVariable:Float3 = input.normal;

---

I'd also like to express my thanks for HxSL and Haxe itself. It really does make a world of difference when working on substantial projects.

[Nicolas Cannasse]

Le 27/02/2013 17:37, Sam Driver a �crit :

> With the removal of the old HxSL from the Format library I've been
> converting my existing code over to HxSL2, and have found a few bugs
> and/or inconsistencies. I hope this is the right place to post them.
> I'm using the latest (as of yesterday) version of HxSL installed by
> haxelib from github.com/ncannasse/hxsl, running the Haxe 3.0 RC,
> targeting Flash Player 11.4. I'm not using any other libraries.

Thank you for reporting these, I didn't have time yet to look at it but
will definitely do when I have allocated time for HxSL.

Best,
Nicolas

[Dima Granetchi]

+1 strange behaviour https://github.com/ncannasse/hxsl/issues/18

On Wednesday, 6 March 2013 12:45:23 UTC-8, Nicolas Cannasse wrote:

Le 27/02/2013 17:37, Sam Driver a �crit :