Animmaniac's Forum Posts

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • You do not have permission to view this post

  • There's a couple of issues with your shader:

    • First you are not using brackets in your if statement, so the alpha is set for every pixel and the if is effectively doing nothing.
    • Second you are using front.x and front.y, that is the same as front.r and front.g respectively, and those returns color values and not positions. What you meant to use is vTex.x and vTex.y that are the coordinates.
    • Just a minor thing, but you can multiply the alpha value directly (front.a *= fA) instead of repeating the alpha then multiplying (front.a = front.a*fA).

    So your code should look like this:

    lowp vec4 front = texture2D(samplerFront, vTex);
    
    if( vTex.x<fL || vTex.x>1.0-fR || vTex.y<fT || vTex.y>1.0-fB )
    { front.a *= fA; }
    
    gl_FragColor = front;[/code:2pirw3zx]
  • 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.

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

  • 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

  • You do not have permission to view this post

  • You do not have permission to view this post