[r152] - Shader Effect Resolution Change - Bug?

0 favourites
  • 6 posts
From the Asset Store
Adjusting the game screen for different resolutions (Letterbox scale)
  • Link to .capx file (required!):

    VIEW

    DOT SCREEN

    gameswarp.com/studio/demo/Bug/DotScreen800x600

    gameswarp.com/studio/demo/Bug/DotScreen1600x1200

    COLOR HALFTONE

    gameswarp.com/studio/demo/Bug/ColorHalftone800x600

    gameswarp.com/studio/demo/Bug/ColorHalftone1600x1200

    DOWNLOAD

    DOT SCREEN

    gameswarp.com/studio/demo/Bug/DotScreen-800x600.capx

    gameswarp.com/studio/demo/Bug/DotScreen-1600x1200.capx

    COLOR HALFTONE

    gameswarp.com/studio/demo/Bug/ColorHalftone-800x600.capx

    gameswarp.com/studio/demo/Bug/ColorHalftone-1600x1200.capx

    Steps to reproduce:

    See description below.

    Observed result:

    The two outputs are dissimilar.

    Expected result:

    The two outputs should remain the same even if the resolution is changed via C2 or manually via the control panel.

    Browsers affected:

    Chrome: yes

    Firefox: browser had been uninstalled; unable to test

    Internet Explorer: yes (on IE11)

    Operating system & service pack:

    Win 7 64-bit, SP1

    Construct 2 version:

    1.52

    DESCRIPTION

    I have been toying with my mouse cursor specific shaders for the past few hours now and have my suspicions that there are some problems with C2's shader "resolution" code.

    If you could refer to these forum messages:

    1. scirra.com/forum/effect-gs-4-circles-with-eyelid_topic82420.html

    2. scirra.com/forum/effect-gs-2-flower-petals_topic81325.html

    I got different results just by changing the screen resolution between 1600x1200 and 800x600 (this includes resizing the background to fit the screen). In one case, the mouse cursor is in the exact center of the flower petal effect, while it is displaced in the other.

    I simply cannot reconcile my observations of Construct 2 with what I see on Heroku and Shadertoy. Try this one for example and change the screen resolution via Control Panel: glsl.heroku.com/e

    The pattern should remain the same - centered on the mouse.

    On Heroku/Shadertoy, they have the resolution parameter that takes care of all resolution switching problems. On Construct 2, I coded it as: vec2 resolution = vec2(pixelWidth, pixelHeight); - which is similar to the approach used in Heroku/Shadertoy.

    To demonstrate there is an error in Construct 2, I had to search for an existing plug-in that would clearly demonstrate the problem. Here are two.

    Just create two Color Halftone (or two Dot Screen) effects having the same settings, but set one to 1600x1200, and the other to 800x600. You will see that the output images are different in appearance because of the resolution change.

    I may be wrong... but please, give me the benefit of doubt... as I am at my wits end as to why C2 can't behave similarly to Heroku/Shadertoy. Would love to hear your explanation.

  • Another way to look at it.

    Here is a shader effect on Heroku/Shadertoy that is not dependent on mouse movement... glsl.heroku.com/e

    1. Set resolution to 1366x768.

    2. Load the heroku link - glsl.heroku.com/e

    3. Resize the browser window to fit four rows of hexes.

    4. Change screen resolution via control panel - I chose 800x600.

    5. Count the number of rows of hexes... it should still be four.

    Conclusion: The shader output maintains itself regardless of resolution changes.

    Now, if only Construct 2 can do that... then the community would have a Heroku/Shadertoy like sandbox at their fingertips.

    Thanks,

    Gavin

  • I found an error in my code, and will be relooking at all the above.

    This

    vec2 resolution = vec2(pixelWidth, pixelHeight);

    should be

    vec2 resolution = vec2(1./pixelWidth, 1./pixelHeight);

    In the meantime, please ignore this.

    I will repost, if I suspect a bug.

    Thanks,

    Gavin

  • Nope... it seems that this issue still persists. I have changed my code to use the above line. However changing resolutions still give me an offset problem.

    I used the following shader code to test out my code at 800x600 and 1600x1200. Only the 800x600 code gets the mouse position ALMOST correct, while 1600x1200 is way off.

    Reference:

    shadertoy.com/view/lssGzH

    HIGHLIGHT MOUSE POSITION SHADER CODE

    precision mediump float;

    varying mediump vec2 vTex;

    uniform lowp sampler2D samplerFront;

    uniform mediump float seconds;

    uniform mediump float pixelWidth;

    uniform mediump float pixelHeight;

    uniform mediump float layerScale;

    uniform float mseX;

    uniform float mseY;

    uniform float distancebetweencircles;

    uniform float zoomfactor;

    mediump vec2 iResolution = vec2(1./pixelWidth, 1./pixelHeight);

    mediump vec2 iMouse = vec2(mseX, mseY);

    float smoothbump(float center, float width, float x) {

    float w2 = width/2.0;

    float cp = center+w2;

    float cm = center-w2;

    float c = smoothstep(cm, center, x) * (1.0-smoothstep(center, cp, x));

    return c;

    }

    void main(void) {

    vec2 uv = (gl_FragCoord.xy / iResolution.xy);

    vec2 m = iMouse / iResolution.xy;

    float m1 = smoothbump(m.x,0.05,uv.x) *

                 smoothbump(m.y,0.05,uv.y);

    gl_FragColor = vec4(m1,0,0,1.0);

    }

    Did I miss something out?

    Or is it a bug? Or maybe a missing feature?

  • As far as I can tell dotscreen is working correctly. Because it is written to take in to account pixelWidth and pixelHeight, it means the effect produces a dot in a certain pixel distance. Therefore increasing the window size will show more dots. Then you have a letterbox scale which resizes them to both be the same final size, which is possibly confusing. If dotscreen were to look the same regardless of the window size, it should not use pixelWidth and pixelHeight and just base calculations off the texture co-ordinates, but we decided to do it the pixel-based way.

    Your effect simply looks like it mixes up texture co-ordinates and screen co-ordinates. It looks like you correctly convert the mouse to texture co-ordinates by dividing it by the resolution, but this line appears to be wrong:

    vec2 uv = (gl_FragCoord.xy / iResolution.xy);

    The fragment co-ordinates are already in texture co-ordinates, so dividing again by the resolution does not make sense.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Will take a closer look at everything you mentioned as well as any available documentation on Heroku/Shadertoy (as well as the code internal to C2).

    The ultimate objective is to find an easy way to handle the porting of shader code to a C2 environment for the more casual users.

    Thanks,

    Gavin

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