viewOrigin parameter passing wrong value

0 favourites
  • 11 posts
From the Asset Store
Be quick and choose whether the shown equation is right or wrong.
  • 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:

    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:


  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)