fisholith's Forum Posts

  • I may be thinking about this wrong, but I think the shader I linked to shows that the coordinate space flipping and scaling does not result in everything coming out as if it were never flipped. That is, at least on my computer and version of Construct 2, the end result appears to be different depending on what the shader is applied to and how it is applied.

    My specs are:

    Construct 2 version: r173 64-bit.

    Previewed in: Firfox & Node-Webkit (same behavior in both)

    OS: Win7 x64.

    RAM: 16 GB

    GFX: Geforce GTX 780 Ti

    Brief disclaimer: I always feel a bit uneasy about describing a potential problem, because I don't want to come off as complaining. My feeling is that Construct 2 is awesome, and thanks to the effort of the devs, grows steadily more awesome with each release. So, I'm only bringing up the coordinate space issue because if it really is a problem, that isn't just on my computer, it may eventually be one more place C2 has room to expand it's aforementioned awesomeness.

    Again, I could be thinking about this coord space thing wrong, but it doesn't look to me like there is any way to reliably address a desired location on an arbitrary object (layer, sprite, etc) in the way you could in Construct Classic.

    The issue I'm running into at the moment is that I'm trying to recreate a pretty simple elevation gradient effect I created for Construct Classic, but presently in Construct 2 the coordinate system doesn't necessarily face a consistent direction, or consistently refer to the bounding box of the object being processed.

    A number of my Construct Classic shaders that I'm trying to port to Construct 2 won't work without a coordinate system that behaves consistently. What I mean by consistent, is that the origin (0,0) is always in the same corner of any object and the (1,1) point is always in the opposite corner, whether you're dealing with sprites or layers, and whether the effect is the first in the chain, or later in the chain.

    At the moment, if I say get the object's color at (0,0) I could be referring to the bottom-left corner of a layer, the top left corner of a sprite (only if it's the first effect in the chain), or a point that may not be anywhere near the sprite's bounding box, if the effect is second or farther on in the chain. Although depending on the location of the sprite within the layout, (0,0) could also potentially refer to any point inside the sprite's bounding box as well, (since the coordinate space gets entirely decoupled from the sprite after the first effect).

    By contrast, in Construct Classic, the effective (0,0) point was always the top-left corner of any object you were dealing with, and (1,1) was always the bottom-right, whether you're dealing with sprites or layers, and regardless of how many effects were in the chain.

    As a workaround, I could try building in extra effect parameters that user's could use to compensate for the various possible coordinate spaces, but they would have to be things like "Enter the dimensions of your sprite only if this is the 2nd effect in the chain", "Enter the dimensions of the viewable screen area", "Check this box if this effect is being applied to a sprite", "Check this box if this is not the first effect in the chain" and "Check this box if this effect is being applied to a layer". This would require multiple layers of branching code to be placed inside the shader. But it could theoretically work. Though you might also have to pass the location of the sprite within the viewable screen area to the effect in order to resolve some of the 2nd-effect-in-the-chain issues.

    Another possibility would be to make multiple slightly different versions of an effect to handle each case. I could make a Layer version, a Sprite-1st-effect version, and a Sprite-2nd-or-later-effect version.

    Again, I don't want to sound like I'm complaining or criticizing here. And like I said, this may just be on my computer. I haven't had time to test it out on another machine, but the effect I linked to in the first post should show what I'm talking about if it's not restricted to my computer.

  • It's very possible I'm doing something wrong here, but it looks like the Y component of vTex is sometimes Positive upwards and sometimes Positive downwards, with the origin sometimes at the bottom-left, and other times at the top-left, depending on what you're applying the effect to, and how you're applying it.

    For a sprite the vTex coord system seems to have its origin at the top-left of the sprite, with the (1,1) point at the bottom-right of the sprite, making Y-positive-down, which is what I would expect. However, this seems to only be true for the first effect placed on the sprite. All subsequent effects applied to the sprite seem to have a flipped and scaled coordinate system with the origin at the bottom-left of the screen (the screen, not the sprite) and the (1,1) point at the top right of the screen, with Y-positive-up, instead of down like it is for the first effect.

    To try to better understand what was going on, I created an effect that simply places the X and Y values of vTex in the R and G channels respectively. Thus, red increases with positive X, and green increases with positive Y.

    gl_FragColor = vec4( vTex.x , vTex.y , 0 , 1 );[/code:nucr3ubz]
You can download the effect here to try it for yourself:
[url=https://dl.dropboxusercontent.com/u/38240401/Public%20Distribution/Construct2/Effects/fi_effect_ShowUV.zip]https://dl.dropboxusercontent.com/u/382 ... ShowUV.zip[/url] 

When I apply this effect to sprites, I get a black corner in the top-left of the sprite, with green increasing downward, and red increasing rightward, just like you'd expect, both colors maxing out at the bottom-right corner of the sprite. When I apply the effect a second time to the same sprite, I get a "window" onto a coord system where there is a black corner at the bottom-left of the screen (the screen, not the sprite), and green increases upwards until it maxes out at the top edge of the screen. Likewise, red maxes out at the right edge of the screen.

When I apply this effect to layers, I get a black corner in the bottom-left, with green increasing upwards, and red increasing rightward, both colors maxing out at the top-right corner of the screen.

This inconsistency in the coordinate systems seems to occur both in the editor and at runtime.

Again, I could be doing something wrong here, so I figured I'd run it by the forum. Any advice is welcome. If anyone want's to try it out and report back with what they find, you can download the Show UV effect above.

  • Is there a list of the specialty variables that Construct 2 makes accessible in GLSL?

    e.g. From looking through scripts I found "pixelHeight".

    In Construct Classic, I recall the following variables being available:

    [quote:1lvdl6i8]boxWidth

    boxHeight

    boxLeft

    boxRight

    boxTop

    boxBottom

    pixelWidth

    pixelHeight

    hotspotX

    hotspotY

  • Sounds good. Thanks again. :)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Just want to double check the method for enabling dev mode.

    The SDK page says,

    [quote:165dbysl]"and add the key devmode and set it to 1 (DWORD value)."

    Does this mean that, inside the "html5" key (folder), I need to create a new key (subfolder) named "devmode", put an unnamed DWORD inside it, and set it to 1?

    Or does it mean that, inside the "html5" key, I need to create a DWORD named "devmode", and set it to 1?

  • Good point. Additionally, adding and removing effects is probably much less of an issue than previewing changes anyway, because in general if I'm working on a new effect, I only need to restart C2 once for it to show up. After that it's just a matter of testing incremental changes.

    The dev mode sounds like it's pretty much exactly what I'm looking for.

    Thanks :D

  • Other than exiting and restarting Construct 2, is there a way to force the list of effects to reload?

    The only reason I ask is that it would be a bit easier to test incremental changes to effect code if I could avoid regularly restarting Construct.

    On the plus side, what I've noticed so far is that in some cases I can see changes to effect code when running the compiled version of a project, which is nice, but it's a limited workaround, as it doesn't really help if the change was something like a new parameter.

    At the moment, if I create a new effect, I save my project, close Construct 2, restart it, and reopen the project, to see the new effect show up in the effects list.

    Similarly, if I make a change to an existing effect, the change will show up when I compile and run the project, but it won't show up in Construct 2's layout editor, even if I remove and reapply the effect.

    Anyway, I hope I don't sound like I'm complaining or anything. I just want to make sure I'm not missing something, or overlooking a better workaround.

  • Wow, awesome. Thanks. :D

    A few more questions just occurred to me, actually.

    5: If you place an effect on a sprite, can you sample parts of a foreground sprite that are off-screen?

    Just checking because I played around with a blur, and it looks like it ignores pixels that are outside the visible screen area. More specifically it looks like sample coords that refer to off-screen locations are clamped to the closest equivalent on-screen location.

    6: Can the origin of the vTex coords ever be outside the visible screen area?

    i.e. If a foreground sprite's top-left corner moves off-screen, does the origin of the vTex coords move off screen with it, or are the vTex coords squeezed to fit inside the edges of the visible screen area?

    In Construct Classic, I vaguely recall the HLSL coords acting a little different as a sprite started moving off-screen.

    7: Is there any place I should look to find out more about the details of the Construct 2's GLSL related stuff, or is the forum the best place to ask about this kind of thing?

    Thanks again. :)

  • Hi all :)

    I just started looking into making some GLSL shaders, and I have a few questions about the coordinate system.

    1: What are the units for the vTex coordinate values? (e.g. pixels, sprite lengths, etc)

    2: What is the origin for the vTex coordinates? (e.g. corner of layout, corner of sprite, etc)

    3: Does the background need some kind of special coordinate conversion to ensure that it is sampled correctly? I ask because the "dodge" effect has the following line:

    [quote:sdoz8br7]lowp vec4 back = texture2D( samplerBack , mix( destStart , destEnd , vTex ) );

    It looks like "mix()" might be a lerp style function. It makes me wonder if vTex values run from 0 to 1 across a sprite, and so they are being used to lerp between the screen cords of the relevant patch of background, or something.

    4: What are the "destStart" and "destEnd" variables, and what are their units and origin?

    Just curious, thanks. :)

  • Thanks. :D

  • I just recently created a post for an effect suite I'm working on for Construct Classic. I set up the download to use Dropbox, as I wasn't sure if it was okay for a poster to link to their own website. So I wanted to ask first.

    Is it alright for a poster to link to their own site?

    (e.g. In my case link to a page containing documentation for the effect suite I'm releasing.)

    Does it make a difference if the site can accept donations, via donation button or something?

    (My site doesn't have any donation system at the moment, but I'm still in the process of assembling the site, and I hope to include something like that eventually.)

    I know I've seen a few other posters link to their sites, but I just wanted to make sure those weren't special cases or something.

    Sorry if this is an odd question. I try to err on the side of caution where forum etiquette is concerned. :)

  • Thanks everyone. :D

    Definitely let me know if you have any questions or suggestions. I'm all ears.

    Also, there are descriptions of all the effect parameters available as well. I just added a new "Effect Instructions" section to my top post describing where you can find these descriptions.

    (I'm also including that new section below for convenience.)

    <font color=blue>Effect Instructions:</font>

    I'll be releasing more detailed instructions in the future, but for now, each effect has some built-in documentation which should help out.

    Effect Descriptions:

    When adding a new effect from the effect list, the description of the selected effect can be seen in a gray box at the bottom of the effect list window. If a description doesn't quite fit in the box, then you can always stretch the window wider to read all of it.

    Effect Parameter Descriptions:

    When you add an effect to an object, and edit the effect parameters in the Property panel, clicking on one of the parameters to edit it's value causes a gray box at the very bottom of the Property panel to show a description of that parameter. I've tried to make the parameter descriptions pretty helpful. They will often explain what the parameter does, what to expect from specific example values, and the valid range (e.g. 0.0 to 1.0) and type (integer or decimal) of values.

    For parameters that are integer menus, (e.g. 0 = off, and 1 = on.), the parameter descriptions will list the available menu options, and their effects.

    e.g.

    [0] = Normal blend.   [1] = Add blend.   [2] = Multiply blend.

  • Okay, here is the alpha release of the effect suite I'm working on.

    Feedback is very much welcome, as are any questions.

    I'll be releasing effect demos, in both .cap and .exe form, for the other effects soon.

    <font color="blue">Download:</font>

    Fisholith Effects - alpha 1 - 111111.zip

    (The "111111" is the date.)

    <font color="blue">Effect Demos (compiled):</font>

    Download - Bias Gain demo app

    (more to come)

    <font color="blue">Installation:</font>

    Unzip the ".fx" files and place them in the following folder, (depending on your OS).

    XP: C:\Program Files\Scirra\Construct Classic\Effects

    Vista & 7 x64: C:\Program Files (x86)\Scirra\Construct Classic\Effects

    <font color="blue">Effect naming:</font>

    "!fi -"

    For the alpha releases, all effect names start with "!fi -". This is because when I work on them, it's much easier to have them sort to the top, and stay in a group. I hope this isn't too inconvenient for anyone for the time being.

    "RGB"

    Effects with names ending in RGB give individual control over the Red, Green, and Blue channels.

    <font color="blue">Effect Instructions:</font>

    I'll be releasing more detailed instructions in the future, but for now, each effect has some built-in documentation which should help out.

    Effect Descriptions:

    When adding a new effect from the effect list, the description of the selected effect can be seen in a gray box at the bottom of the effect list window. If a description doesn't quite fit in the box, then you can always stretch the window wider to read all of it.

    Effect Parameter Descriptions:

    When you add an effect to an object, and edit the effect parameters in the Property panel, clicking on one of the parameters to edit it's value causes a gray box at the very bottom of the Property panel to show a description of that parameter. I've tried to make the parameter descriptions pretty helpful. They will often explain what the parameter does, what to expect from specific example values, and the valid range (e.g. 0.0 to 1.0) and type (integer or decimal) of values.

    For parameters that are integer menus, (e.g. 0 = off, and 1 = on.), the parameter descriptions will list the available menu options, and their effects.

    e.g.

    [0] = Normal blend.   [1] = Add blend.   [2] = Multiply blend.

    <font color="blue">Effect List:</font>

    Additive Bidirectional RGB

    Additive Bidirectional

    Bias Gain

    Bias RGB

    Bias

    Bit Crusher RGB

    Channel Invert

    Channel Reassignment

    Channel Select RGBA for BG

    Channel Select RGBA

    Channel Wrench

    Compose RGBA Tiles Stretch

    Compose RGBA Tiles

    Dither Map Bit Crusher RGB

    Dither Map Gen 8x8

    Dither Map Posterize RGB

    Elevation Gradient Chromatic

    Elevation Gradient

    Gain

    Global Variable Texture Viewer

    Grayscale to Opacity Gamma Aware

    Grayscale to Opacity

    Pixel Noise

    Posterize RGB f3

    Posterize RGB

    RGB2HLS

    Scan Line Tool

    Solarize RGB

    Solarize

    Threshold RGB

    Threshold Soft Color

    Threshold Soft

    Threshold

    Use Background via Alpha Mask

    Use Background via Bounding Box Mask

    I would definitely be interested in helping to add to Construct. :)

  • Thanks Angelo.

    I'm nearing completion of the first release. I was hoping to have the alpha out last Thursday, but I had to put working on it on hold for a few days. I'm hoping to have it available by this Friday, or sooner if I'm able.

    Thanks again guys. :)

    Let me know if you have any requests by the way, with respect to effects or demos. I don't know If I'll have time to implement them in the first release, but any feedback helps.

    <font color="purple">EDIT:

    Still hoping to get it released this Friday (technically today). I've gotten quite a bit more done, so with any luck I'll have it ready shortly.</font>

    <font color="blue">EDIT 2:

    Alpha version 1.0 is now available :)

    </font>