R0J0hound's Forum Posts

  • Glad it worked. I’ve never used that noise function. I thought for a second I may have answered wrong as I’m not sure what those rgb stops do exactly.

    I agree with you it would be more useful if the noise function was in a more useful range.

    Edit: as for the hard lines, it could be clamping. Isn’t the noise value a decimal number?

    You could try to use 28 and 72 to be the low and high values in the equation to give a slight buffer.

  • If that’s the range you can make it from 0 to 100 with

    (X-29)/(71-29)*100

  • What a cool bunch of different graphics effects. The bobing and tilting are nice touches that make the motion cooler.

    Nice use of pixel data too. No need to process more than you need to and it seems to make it more interesting when you can draw the curves instead of relying on stiff math curves. Anyways, looking forward to seeing more. The pixel examples I made work differently but could benefit from canvas use if I used C3.

  • Hi.

    I don’t have an example but I think you can break it down in to simpler parts and see how they could be done.

    I guess I should play the game, but from watching videos this is what I can gather.

    1. The enemy moves around in the empty area and won’t leave the boundaries.

    2. The player can move anywhere inside the boundary too, but when it’s on the edge it’s safe.

    3. When the player leaves the edge it draws lines behind itself.

    4. The player can’t cross this edge, and if the enemy touches this edge or the player it kills the player.

    5. When the player makes it back to the original edge the area the enemy isn’t in is filled and the boundary edge is updated.

    I may be overlooking some aspects of the game, and it does look like some things can be more complex but as a start that covers most of it.

    Number 5 is the most novel. There are a few ways to think of it. One way that seems to work well in my mind is to have the boundary of the level be a polygon. When the player moves from one edge and makes it to another it splits the polygon into two. We then test which polygon the enemy is in and filling the other.

    Filling a polygon can either be done with a flood fill or more efficiently a scan line at a time. Canvas sounds like it would work well, or maybe a bunch of 1px thick sprites.

    So the laundry list of things to do would be:

    Point inside polygon test.

    Split polygon by poly line

    Fill polygon

    Others may have different ideas.

  • You didn't specify the size of B, but if it can be thought of as very small it will make things simpler. Does B bounce too, or is it just getting destroyed?

    The first is to find the point of collision and the normal. Since B is small you can just use B's position when it overlaps A. The normal is a bit trickier, but you can find it with something like this. It assumes that A is a rectangle. It just find the closest edge on A and uses it's normal 

    variable best=1000
variable normal=0
variable d=0
variable a=0

set best to 1000
repeat 4 times
-- set a to A.angle+90*loopindex
-- set d to (loopindex%2=0)?A.width/2:A.height/2
-- subtract (B.x-A.x)*cos(a)+(B.y-A.y)*sin(a) from d
-- compare: d < best
---- set best to d
---- set normal to a

    So the next part is to calculate the impulse. It's taken from here if you want the source of the math:

    en.wikipedia.org/wiki/Collision_response

    rx,ry is the offset from A to B

    relvel is the velocity between the two objects at that point, along the normal.

    cross is the cross product of r and the normal.

    j is the impulse magnitude

    vx, vy is the horizontal and vertical velocities

    w is the angular velocity 

    variable rx = 0
variable ry = 0
variable relvel = 0
variable cross = 0
variable c = 0
variable j = 0

set rx to B.x-A.x
set ry to B.y-A.y
set relvel to (B.vx - (A.vx+A.w*PI/180*-ry))*cos(normal) + (B.vy - (A.vy+A.w*PI/180*rx))*sin(normal)
set cross to rx*sin(normal)-ry*cos(normal)
set j to -(1+e)*relvel/(1/A.mass+1/B.mass+1/A.inertia*(-ry*c*cos(normal) + rx*c*sin(normal)))

    Before we go further the units used by the physics behavior needs to be taken into account. Construct physics uses degrees per second for angular velocity. The equations above need radians per second.

    So above A.w is replaced with A.w*PI/180.

    Also the physics behavior I don't think gives you the inertia of an object. But for a rectangle you can calculate it with

    inertia = mass/12*(w^2+(1/w)^2)

    Also bear in mind when I use A.vx in the equations above I mean A.physics.velocityX. Similar to vy and w.

    Ok, cool so Now we have j, which is the magnitude of the impulse. Since we can't apply an impluse at as specific location can just set the velocities directly.

    set vx to A.vx-*1/A.mass*cos(normal)

    set vy to A.vx-*1/A.mass*sin(normal)

    set w to A.w-j*1/A.mass*cross*180/Math.PI;

    Barring any typos on my part that should work.

  • JaviApps

    There is no update for this plugin for c3. This plugin probably should be retired. It works best with the non webgl renderer. It was made to somewhat work with webgl but is a performance hog.

  • Test 3: Scorched earth style terrain.

    dropbox.com/s/bjnapmhuy5vonch/burntEarth.capx

    It implements single color terrain that you can erase and draw. It's done with sprites used for one pixel wide vertical spans. I thought it faster than using a sprite per pixel. Construct's renderer really is quite speedy, but the event sheet is pretty slow when manipulating that many objects.

    Since this is done with sprites it will work with the platform behavior. Not sure about the physics behavior since it doesn't behave well with changing sizes of sprites.

    -cheers

  • Thanks.

    No, I've only briefly messed with babylon.js. I don't really have any 3d assets to make much use of it. Besides I think Construct only gets in the way when using it. It's better suited to be used directly without construct at all. The goal in the example here was to work within Construct's renderer, as well as try out interpolating between frames.

    For 3d to happily coexist in construct with it's renderer there are four approaches that i've seen.

    1. use a separate html5 canvas stacked on top of constructs canvas.

    2. still use a separate canvas, but it's hidden and it's copied to a texture that is drawn by Construct's renderer.

    3. Just utilize Construct's renderer to draw the 3d stuff. Limited, but that's what is happening here.

    4. Use custom webgl to render onto the same canvas that construct's renderer uses, but the complexity here is any webgl state that is changed needs to be restored when done. Best done with custom webgl instead of babylon.js, because construct's renderer and babylon.js both work as if they were the only ones utilizing the canvas.

    Anyways, 3d is still one of my many interests. Got a gltf importer partially working. The format makes more sense now, but I shelved it before making it render anything.

  • It was just an example, there's also pngout, pngcrush and for lossy compression pngquant. I haven't tried any of them honestly. Looks like you can fiddle with the parameters to get better results for different images. Likely it's the tech behind these png compression sites, at least that's my suspicion.

  • No idea what png compression c2 or 3 uses but as a user you could manually just do the compression with a tool like

    optipng.sourceforge.net

    Instead of an online tool.

  • Test2:

    dropbox.com/s/ai2pzste5q08hkh/perpixel_col4.capx

    Per pixel collision detection with collision normal calculation.

    Also included some simplish physics to interact. Once the arrays are loaded the balls will never miss a collision as they move a pixel at a time in a loop.

    Tech details:

    The wall sprites are in a container with arrays. When the capx runs some js is run that populates the arrays with the collision and normal for each pixel. Optionally it can expand the collision mask by another sprite.

    Note: The js code probably won't work when exporting so some other functions are included to save/load the pixel arrays.

    -cheers

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It’s just further reading. Anyways the gist is numbers only can have 15-17 significant digits.

    So you’re running into the limit and it’s rounding.

  • I’d imagine it has to do with how numbers in construct are 64bit floating point numbers that only use at most 15-17 significant digits.

    en.m.wikipedia.org/wiki/Double-precision_floating-point_format

  • Besides using a tilemp with 1x1 tiles, here is a different approach.

    It parses a svg file and uses sprites to make lines around the shapes to use as collisons.

    Added the original image too as a png. Had to fiddle with scale and position to make them line up, so that's not 100% ideal.

    dropbox.com/s/43e80boez5lg33b/svg_physics.capx

  • Tomycase

    The plugin was made to utilize the non webgl renderer. Even with webgl on it uses the non webgl drawing of plugins. Things like tilemap sets up itself internally different with webgl. So in short it won't work, although you could try the paster object which takes advantage of webgl and is similar.

    marceloborghi

    That's out of the scope of what I can help with. I'll answer questions about the plugin here and there, but I've since abandoned this. Anyways, you'll have to debug it more to see why it doesn't work. I usually have to test things a bit at a time to find out what works and where exactly it breaks and try to figure out why.