R0J0hound's Recent Forum Activity

  • Short answer is no. Long answer is maybe.

    You can already load textures at runtime. To use additional textures in an effect there are two parts in webgl. On the shader side just add another sampler uniform.

    To make it reference a texture you need to select a texture unit, bind a texture, and finally bind the shader program and set the sampler uniform to the texture unit index you’re using.

    Construct’s renderer doesn’t use too many texture units so you could use an unused one to bind a texture to. To do that all you need is to get the webgl context.

    The part I’m iffy about is setting the uniform on the shader. To do that you need the shader program for that shader. And that’s something that construct keeps track of. Possibly could be other ways to get the shader handle.

    Anyways that’s just a general outline for how it could be done for webgl. Construct doesn’t provide anything to help with that nor does it do much to prevent that.

  • Unless you can start a local server with JavaScript you wouldn’t be able to do it via python implemented via webassembly. The same limits apply. To bypass the browser limits you’d need a plugin for nwjs or webview2

  • I don't really want to make another cloth example. I've made like 10 and posted them all on this forum from one time or another.

    To move a point out of a box one way I've found useful lately is to use an sdf (signed distance field). Logic is basically this:

    var dx, dy
    
    function sdf(px,py)
    -- dx = (px-box.x)*cos(-box.angle)-(py-box.y)*sin(-box.angle)
    -- dy = (px-box.x)*sin(-box.angle)+(py-box.y)*cos(-box.angle)
    -- dx = abs(dx) - box.width/2
    -- dy = abs(dy) - box.height/2
    -- return distance(0,0, max(0, dx), max(dy,0))+ min(0, max(dx,dy))
    
    var d=0
    for each point
    -- set d to sdf(point.x,point.y)
    -- if d<radius
    -- -- point move radius-d pixels at angle angle(d,d, sdf(point.x+0.0001, point.y), sdf(point.x, point.y+0.0001)

    You'd have to modify it slightly to work with more than one box. There are probably other ways to do it too.

  • There are pros and cons to either. Basically text is simpler to use and look good with high res stuff, but is visually poor when doing low res stuff. Spritefonts are drawn faster and give more control over the look of the text but take more setup and don’t scale up well for high res stuff.

    Text object

    Pros:

    * simple to use. Pick a font and any character is available.

    * since it utilizes the canvas’ text renderer characters edges will look smooth no matter the text size.

    Cons:

    * it works by the text being drawn to an image and copied to texture. So it takes up video ram and copying the image into the texture may not be the fastest.

    * text looks fuzzy when full screen scaling is set to low quality. So probably not the best for low res graphics.

    spritefont object

    Pros:

    * it works by just drawing characters as quads and using one texture. This is pretty fast with construct’s batching renderer.

    * useful for low res games since you have more artistic control over the look of characters.

    * very easy to use with monospaced fonts.

    Cons:

    * have to make a texture with all the characters you want to use.

    * the texture can be fairly large with a lot of characters since the texture atlas isn’t tightly packed.

    * you have to provide the spacing numbers if you want to use a variable width font. There are tools that help with that though.

    * scaled the text is only as detailed as the texture. So scaling up will be blurry or pixelated depending on the sampling.

  • There are some third party solutions

    construct.net/en/make-games/addons

    construct.net/en/make-games/addons

  • Physics joints will never be completely solid. You can increase the iterations to make the joints more solid though. There’s an action for that.

  • Another idea is to make the bouncing not quite realistic by moving and bouncing vertically and then horizontally. Hitting corners would probably just reverse the motion then. Typically when a ball hits a corner its motion angle can change considerably but it’s not something you really see happen in breakout clones.

  • They probably just add some y velocity when the y part of the velocity is near 0.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You can try increasing the iterations to try to help the solver not explode like that (there’s a physics action for that).

    Another thing you could try is a distance joint from the first link to the last to help it from not getting too long. This is a general box2d idea, not sure if that shakes out in construct.

    Another idea is since box2d resolves joints with changing the velocity you could try adding some damping on the chain link objects.

    Final thought as to why the chain explodes is when the physics object gets updated. The loop is basically behaviors->events->draw->next frame. Any changes to the physics objects happens at the behaviors step. So maybe the lurch is from the links being in different orientations when the joints are added.

    What I did once to correct that is to create the links, wait till next frame (after the behavior runs again), then add the joints. Or something like that.

  • The idea is

    Save scale, make unscaled, check for collision, then restore scale. I guess what makes it complicated is depending on if the mouse is overlapping or not you also what to change the scale. What i wrote was on possible solution.

    And yes that’s a division. There is no expression for an objects so that is a way to calculate it.

  • It’s fairly simple. “A is overlapping B” will pick any A’s and B’s that overlap. It’s not a loop, it will just pick the ones that overlap and passes on to the next condition. If you want to examine individual pairs you’d need two for eaches.

    For each A
    A overlaps B
    For each B

    As to what the set position action is doing. It’s basically this with the picked instances.

     for(i=0; i<A.length; i++)
     A[i].setPosition(B[i%B.length])

    Or in other words it moves the first A to the first B, second A to second B, and so on. If it runs out of B’s it just loops back to the first B again.

  • If the mouse plugin or the c3 scripting api doesn't provide access to the additional buttons then its simple enough to just hook the mouse events with straight js.

    In general you can add event listeners to the document (or canvas if you know a quick way of accessing it) for the mousedown, mouseup and mousemove events. In the events you can access clientX, clientY (which is the xy in canvas coordinants) and button (0 through 4). To make it usable i'd just have them call some c3 functions with those values. and there you can use the CanvasToLayer expressions to get the mouse position in layout coordinants.

    As an example here is the js to run at the start of the layout.

    document.addEventListener("mousedown", (e) => {e.preventDefault(); runtime.callFunction("mousedown", e.clientX, e.clientY, e.button)};

    And here is what the events would look like:

    var mx=0
    var my=0
    function mousedown(x,y,button)
    -- set mx to CanvasToLayerX(x,y,0)
    -- set my to CanvasToLayerY(x,y,0)
    -- do whatever

    Do the same thing for mouseup and mousemove and that covers about everything. The only thing missing is a condition for "is mouse down". For that you'll have to just update some variables as the buttons are pressed and relased.

    In the js you see it call a function called preventDefault. That should stop those additional buttons from navigating away from the page in theory. It's what c3 already does to keep you from right clicking on a canvas to get a context menu.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 155 followers

Connect with R0J0hound