Mikal's Forum Posts

  • How about this? A good look depends a lot on the gradient image you apply.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I am not the plugin's original author, I am mostly helping out with the webgl rendering side and fixing bugs. So, generally, I will not be doing work to add a lot more ACEs. I think the original author has moved on from using this plugin themselves, so I think it will likely stay with a minimal number of ACEs to support playing animations.

    That being said if you have a few critical ACEs required, you can make a request up on the github website in the issue list:

    github.com/gritsenko/c3_spine_plugin/issues

    Also, since this is all done in JS, you can also use JS script in events to access the Spine API directly in C3.

  • Here's a formula for linear light from this page: deepskycolors.com/archive/2010/04/21/formulas-for-Photoshop-blending-modes.html

    (Blend > 0.5) * (Target + 2*(Blend-0.5)) +

    (Blend <= 0.5) * (Target + 2*Blend - 1)

    I am not exactly sure how to use it though, I imagine you are blending a source image with the background. I think you would have to apply the above to each color component separately?

    I am over on the Construct Community Discord and have ported/developed effects before if you want to discuss creating an effect or see if that would even work for your purposes.

    discord.gg/kBrCTWV

  • On my project, I fixed the Android APK issue. It seems that for some reason, the initialization process for the Spine plugin takes longer on apk than when done with the web version.

    The longer initialization exposed a bug in the plugin which caused multiple initializations. I fixed this bug in the plugin and now in my simple apk, the Spine character renders properly.

    Please try out the new version of the plugin: 1.4.5

    It's available here:

    gritsenko.github.io/c3_spine_plugin

    Please let us know your results.

  • I am debugging another simple project on Android, it looks like there's some looping on initialization. I will report back what I can debug around this issue.

    I am using USB and Mac to do the debug, it's very helpful to enable this. See the post above about how to do this.

    Also, I wanted to check that my other comment about the bug in your project with the wrong animation name helped fix your 'restart layout' problem on the PC.

  • Ashley I think I'm going to assume that for distortion effects (or effects where we adjust the texture sampling coordinates), I will always enable must-predraw so I can get consistent behavior with srcOriginStart, srcOriginEnd, and relative impact and 'direction' of pixelSize, regardless if only one effect is used or more than one effect is used (or opacity is used.)

    I think there also may be cases where I can also use the normlization technique (n= (vTex-srcOriginStart)/(srcOriginEnd-srcOriginStart)) and then I can use clamp(newN, 0.0,1.0) and perhaps then it won't matter if must-predraw is used.

  • I see one error in your project, you have a Spine character with an incorrect animation-name at the bottom of your layout. When I removed that, restart layout worked.

    Zoom out in the C3 editor you will see at the bottom, it has an animation name of 'Tutorial2toidle'.

    The error shows up in the Chrome developer console (press F12). Please learn how to use the developer console, it is very useful for debugging errors.

  • When you have an error restarting the layout, open up the developer console (F12 on PC) and post any errors you see.

    One quick idea to try, add a 'wait 0.1 seconds' after the skeleton is loaded before enabling animations. I have seen a 'race' condition where one skeleton is loaded, but others are not loaded yet and using their animations cause an error.

  • The buggy versions that do not follow the spec actually make it possible to use clamp(uv, srcOriginStart, srcOriginEnd) in the C3 predraw case.

    The versions that follow the WebGL spec do not work with the C3 predraw case where srcOriginStart.y > srcOriginEnd.y. The webgl spec is: min(max(x, minVal), maxVal).

    So, if the bugs were fixed to match the OpenGL spec, then clamp(uv, srcOriginStart, srcOriginEnd) could not be used with C3 in the predraw case on any platform.

    I think to handle the variable C3 behavior between predraw and no predraw, clamp and platform variance, for effect distortions where vTex is changed, I will use must predraw and also my own definition of clamp.

  • Ashley

    I think I have found out the reason I was having an issue with using clamp(uv, srcOriginStart, srcOriginEnd) when a predraw was being done with an effect (e.g. <100% opacity or an effect stack.) In this case srcOriginEnd.y was less than srcOriginStart.y. The clamp still worked fine on MacOS Chrome, however, it worked differently on iOS. It looks like it's because the glsl clamp function is being implemented differently on different platforms (OS/browser/GPU/driver.)

    Here's an example and discussion:

    shadertoy.com/view/Ms33R4

    I get different results in iOS/Safari/iPhone and MacOS/Chrome/Radeon.

    So, for cross-platform and predraw / non-predraw compatibility, I will probably use this method: 

     #define clampX(x,a,b) min(max(x,min(a,b)),max(a,b))

    From the discussion on shadertoy (from my experience, iOS also does the OpenGL spec version.)

    It seems like it's implemented in a few different ways (guessed based on how you described them):

    #define clamp(x,a,b) min(max(x,a),b) //OpenGL spec (3 gradients, 2nd black)

    #define clamp(x,a,b) max(min(x,b),a) //Linux (2 white bars in the middle)

    #define clamp(x,a,b) min(max(x,min(a,b)),max(a,b)) //Windows (4 gradients)

  • This effect applies lighting and specular without using an additional normalmap, the normalmap is generated from the object's image. Control over light power, specular color, location, etc.

    Ported from a shadertoy effect, details in Documentation.

    construct.net/en/make-games/addons/350/normalmapprocedural

  • Similar to: 

    			this._info.AddCommonPositionACEs();
			this._info.AddCommonAngleACEs();
			this._info.AddCommonAppearanceACEs();
			this._info.AddCommonZOrderACEs();

    for example: this._info.AddCommonZElevationACEs();

    If not, can one be added?

  • Ashley thanks for the reply. I do think it could be an issue with my understanding, so I made a very simple effect using pixelSize, shifting the texture using a variable amount passed through as a uniform. I expect to have the same result regardless of effect stacking or opacity. Should I not expect that, or am I using pixelSize incorrectly?

    Here's the simple shader. 

    void main(void)
{
 mediump vec4 c = texture2D(samplerFront, vTex);
	c += texture2D(samplerFront, vTex + (pixelSize * shiftAmount))/2.0;
	gl_FragColor = c;
}

    Here's the simple project with the simple effect bundled.

    kindeyegames.com/forumfiles/ShiftTest.c3p

    Thanks for the help in understanding this.

    Here are the results (I expected them all to match. It looks like the Y axis inverts and the relative amount also changes in terms of the distance of the shift.)

  • I am not looking for a destination size.

    I was looking to have effects that use pixelSize to have the same behavior regardless if there is only one effect applied to a sprite or if there are multiple effects applied to sprite (e.g. requires multiple webgl draws, some to the intermediate surface and the final one to the canvas surface.) From my experimenting it seems to have different behavior. For example for bur if I offset a texture sample by widthScale * pixelSize.x, I seem to get a different visual result depending on whether only one effect is used or if multiple effects are used (e.g. set opacity to 99%). I will work on creating an example and experimenting more to see if it's an issue in my effect or something else that I don't expect.

    Another question, while I work on that. How do you suggest clamping texture samples to stay within the sprite's image? Originally I was using clamp(uv, srcOriginStart, srcOriginEnd) which works when only one effect is used, but that does not seem to work on all platforms when doing multiple effects and the Y axis for SrcOrigin* gets flipped for using the framebuffer as texture vs the image as texture (in particular on iOS it fails.)

    My workaround, for now, is to use: 

    newTex.x = clamp(newTex.x,min(srcOriginStart.x, srcOriginEnd.x),max(srcOriginStart.x, srcOriginEnd.x));
newTex.y = clamp(newTex.y,min(srcOriginStart.y, srcOriginEnd.y),max(srcOriginStart.y, srcOriginEnd.y));

    Do you have other suggestions?

  • Adding must-predraw 'true' seemed to do the trick - now I have consistent behavior and another draw is required.

    I would be interested to hear if this is the right approach Ashley