R0J0hound's Recent Forum Activity

  • You probably can improve the situation by disabling the rotation setting with the 8direction behavior. Likely there are other tweaks to be had.

    Alternatively here is an event based 8dir like motion using the angle of the sprite. It has turning and strafe with settings for max speed, acceleration and deceleration. For the collision response it considers the player as a perfect circle and uses signed distance fields to allow smooth wall collisions. Basically it gives better collision handling than what usually is done.

    dropbox.com/s/3days6yqvdj1t9w/custom_fps_controler.c3p

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Naw. This is probably more what you’re after

    construct.net/en/tutorials/enlighten-games-dynamic-1213/normal-maps-5

    There was a more recent normal map effect, but I was didn’t look too hard. It’s made by user Everade.

  • You can change those formals slightly to use there or just do it in a set position action after the crest action. All the clamp is doing is move the box so that it fits on screen.

  • You can use clamp for that. Assuming the origin of that window is top left.

    X = clamp(self.x, 0, viewportWidth-self.width)

    Y = clamp(self.y, 0, viewportHeight-self.height)

  • I don’t think we have any control over that at this point then. Maybe that’s something that can be fixed with a bug report.

    If it’s distracting enough one idea would be to use a lower z scale in the layout editor and scaling it up at the start of the layout when the game runs. It could be a somewhat doable workaround for now. So say in the editor you’d use half scale and then double it in events:

    start of layout
    — set zelevation to self.zelevation*2
    — set depth to self.depth*2

    A third idea could be to make an in game level editor. Could be an interesting thing to attempt.

  • Could it be that it just uses the image and not the repeated version?

    Possible fix could be to use multiple smaller cubes or use a mesh distort to position the tiledbg where the face would be.

  • Is that screenshot showing the glitch well? All I can see are the whiter pixels around the chain link.

    When 3d faces have transparency they typically need to be drawn from the furthest to closest to see through the transparent parts. That works best when the faces are facing the camera as angled faces or faces intersecting other polygons will often still have the issue.

    Construct seems to do this for you somewhat. I haven’t messed with it a lot. What you can do is change the z order of things to control what gets drawn first.

    Besides that there is a shader floating around somewhere called alpha discard or something that lets you see through transparent textures. But it’s a hard off/on, it doesn’t handle semi transparency.

    So anyways the two tools you have to deal with transparent textures in 3d is that discard shader, and maybe messing with the zorder of things.

  • You'll unfortunately have to re-adjust the zheights of everything after that change. It's typically the first thing I change when working with 3d. Apart from that I don't know how to fix the extreme editor z scaling.

  • In the project properties you can set the z scale from normalized to regular.

  • This should work I think. It lerps between the start and end in a straight line. Then also moves in a parabola.

    dropbox.com/s/ilxsoyy7mmm04dc/jump_path.c3p

  • Here’s an idea to keep track of the total rotation of the an object. You’d want it to run toward the end of the event sheet after anything that rotates the sprite.

    The equation used is a signedAngleDifference, which is like the angleDiff() expression but it gives positive and negative for clockwise and counter clockwise rotation.

    Global totalRot=0
    Global prevAngle=0
    
    Every Tick
    — add angle(0,0,cos(sprite.angle-prevAngle), sin(sprite.angle-prevAngle)) to totalRot
    — set prevAngle to sprite.angle

    So a front flip would be if totalRot>360, and a back flip would be if totalRot<-360.

    In general the number of flips could be calculated with:

    Flips = totalRot>0?floor(totalRot/360):ceil(totalRot/360)

    You’d probably want to reset totalRot to 0 when you first get air born from a jump I’m guessing.

  • Something like this would work well. Key differences to what you're doing is it adds to instead of sets the rotx variable. Also instead of the touch speed expression here we find the xvelocity since that gives a direction in addition to speed.

    global rotx=0
    global xvelocity=0
    global px=0
    
    on touch start
    -- set px to touch.x
    
    is touching sprite2
    -- set xvelocity to (touch.x-px)/10
    -- set px to touch.x
    
    every tick
    -- add xvelocity*dt to rotx