viewOrigin parameter passing wrong value

Problem description:

In r160 a new parameter viewOrigin was added to pass the scroll position to shaders.

However it seems is not really passing the scroll position (screen center) but another unidentified value (maybe top left corner).

Link to .capx file and test effect:

https://dl.dropboxusercontent.com/u/7871870/construct/ViewOriginBug-01.zip

Steps to reproduce:

1. Install the effect and run the capx

Capx description:

What the shader does is map the viewOrigin parameter to the red and green channels so it's possible to partially visualize what value is being passed. The test effect is applied to "Layer 0". What the capx does is just rotate "Layer 0" in the same spot.

Observed result:

As the layer rotates the screen color oscillates, indicating that the viewOrigin value is also changing with it.

Expected result:

The screen color should remain constant since the scroll position doesn't change, and the viewOrigin should also stay the same.

Browsers affected:

Chrome: yes

Firefox: yes

Internet Explorer: -

Operating system & service pack:

Win 7 32bit sp1

Construct 2 version:

r163

Yeah there is definitely a discrepancy with the way viewOrigin and scroll work in scirra, however I think viewOrigin makes more sense in the way it handles coordinates.

0,0 should be the top left corner, scroll.x should be the left viewport origin and scroll.y the top viewport origin.

It's a problem of consistency

If you want to see what is given to the shader with viewOrigin, replace scrollx by ViewportLeft(0) and scrolly by ViewportTop(0) in your capx.

I haven't tested it, but I'm pretty sure the way construct handles the layer angle is by rotating it from the middle of the layout, and since viewOrigin is the top left corner of the layer, the values change. But you can use the uniform layerAngle and derive the rotation matrix like so:

where mid is the center of rotation

|x'| = cos(layerAngle) * (vTex.x - mid) + sin(layerAngle) * (vTex.y - mid) + mid

|y'| = cos(layerAngle) * (vTex.y - mid) - sin(layerAngle) * (vTex.x - mid) + mid

Kaisirak I'm almost sure that these new parameters "viewOrigin" and "layerAngle" where added to account for scrolling and rotation inside shaders, and for this purpose returning the center of the screen is a lot more useful.

If ones want to account only for scrolling than the top left corner is fine, but if there's layer rotation included than the center of the screen is what you need. Of course you can derive the center by the method you described, but doing these operations in the shader for every pixel is very costly and unnecessary when you can pass the proper values to the shader once per tick.

Ashley also mentions in the changelog for r160 that "viewOrigin" should return the layer scroll position, and at least in the editor the scroll position is the center of the screen.

I was previously passing the scroll position to some shaders through events, but from what I could observe there seems to be a one frame delay in doing so that cause small jitters. So an internal parameter that returns the center of the screen in layout coordinates is much needed for me, if not "viewOrigin" then a new "scrollPosition" parameter.

It depends on how you use them, using them as they are is simpler for me, but I get where you're coming from.

It's probably a matter of implementation, and you'll have to wait for Ashley for this.

It was a deliberate decision to report the top-left visible point instead, but given the problems you describe with scaling and rotation I think you're right that it would make more sense to report the scroll middle position instead.

I think it might be useful to provide enough parameters to get the object box size in layout co-ordinates too. Then you should be able to make scaling/rotation independent shaders by working in layout co-ordinates rather than texture co-ordinates. Does that sound like a good solution?

Sure, if it can provide access to both parameters then it should cover every possible case.

I just think that maybe calling "scroll" to the parameter that returns the scroll position would be less ambiguous, since "viewOrigin" indeed may suggests the top-left corner.

Hey Ashley

Just to remind you again, can you please add this to one of the next betas?

I did some custom shaders for Airscape, and they are really needing this to eliminate the frame delay glitch and squeeze every performance improvement possible.

I guess it shouldn't be too difficult to implement.

Is it just the scroll position or the whole box in layout co-ordinates that you need?

Just the scroll position (center of screen).

Added a scrollPos vec2 for the next beta.

Thanks!