R0J0hound's Forum Posts

  • Forum is pretty inactive and probably few have suggestions. You can only say you’re being ignored if it’s someone’s job to answer questions I think.

    Anyways, the enemies stop moving since you’re only moving to the first node of the calculated path. You’ll probably want to have it move to each node one by one, and once the enemy is close enough to one node move to the next.

    As for the floaty movement you’d need to calculate different forces to do that. A force to a position generally is always floaty. Intuitively a force perpendicular to the velocity should help it turn faster.

    Or you may be able to throw some math at it to calculate the force required to change the current velocity to another one in one frame.

    Force = K*(TargetVelocity-currentVelocity)*mass*60

    Or split into xy components:

    Forcex=k*(targetvx-currentvx)*mass*60

    Forcey=k*(targetvx-currentvy)*mass*60

    Where k controls how rigid it works. 1 means the velocity changes in one frame, and 0.5 would make it a bit floatier.

    The target velocity would be something like:

    A=angle(enemy.x,enemy.y,node.x,node.y)

    Targetvx=speed*cos(a)

    Targetvy=speed*sin(a)

    You could also try limiting the velocity or force as well. In general you can limit xy values with:

    Mag=distance(0,0,x,y)

    If mag>limit

    — set x to x/mag*limit

    — set y to y/mag*limit

    Anyways, just some ideas.

  • You can incorporate time delta (dt). Basically rate*time=distance.

    Your growth rate is 1 pixel per 1/120th of a second or 1/1/120 which is 120.

    That would basically look like this in events: 

    midi: key is down
— 9patch: set height to self.height+120*dt

  • There’s a stickied topic somewhere with how to report bugs. I’ve never used it though.

    I still wonder if putting all the objects on the same layer that you want to glow and adding the effect to the layer would work. I’m becoming less familiar with construct by the day though so I probably won’t get around to testing it.

    I’ll defer to anyone else that has suggestions.

  • The effect likely needs to be fixed to not sample beyond the edges of the sprites. So if it’s an official bundled effect you can file a bug report for them to address.

    Again, it happens at export and not during preview because of spritesheeting.

    You possibly could work around it by adding a wider transparent border around the images the same as the glow radius. Or maybe adding the effect to a layer instead of individual sprites.

  • To fix you need to put a 1 pixel transparent edge around your images. In the image editor the crop button does that for you.

    Without that transparent edge the colors can get sampled from beyond the edge of the image and cause the edges you are seeing. You don’t see it when previewing because each image is a separate image and there is nothing beyond the edges. However, when exporting the images are spritesheeted together into a few bigger images so now other things can be just past the edges.

  • Getting the exact path isn’t as simple as you’d think. Objects are moved in steps with the timestep which can vary so when a collision is detected it will overlap by a varying amount. You can test that. Repeatedly launch a ball from the same spot to see the path. As long as the framerate is consistent the path will mostly be the same but the more dt varies the more the paths will deviate after a bounce.

    Anyways, maybe a close path would be good enough.

    One way to see the path of an object is to use a loop to simulate many frames at once. Basically use a clone object of the ball. Set the clone to the same position and velocity of the ball, then move the clone with a loop. The bounce logic can be involved if you do it yourself, but if you used the bullet behavior it would be simple. 

    Every tick
— clone: set position to ball
— clone: set vx to ball.vx
— clone: set vy to ball.vy

Repeat 60*3 times
— clone: set position to self.x+self.vx/60, self.y+self.vy*dt
— clone: overlaps wall
— — clone: bounce off wall

    Manually finding the collision normal for a bounce is more involved and a different question.

    Anyways, for the dashed line you only have the consider the positions where the ball bounces and stretch a tiledbg of the dashes between them (or maybe the drawing canvas lets you draw dashed lines)

    Another idea instead of using a loop to simulate motion in steps is to do a kind of shapecast (kind of like a ray cast but considering the shape of the object too). It’s an algorithm that would need to be implemented, but the result would be exact collision detection when the ball would just touch the wall. The con with that is it wouldn’t match how the ball actually moves, as mentioned in the first paragraph.

    Anyways, if very exact is required I’d also change how you move the ball. Basically, shapecast the ball to the walls to get an exact position and time of collision. Calculate the normal and reflect the velocity along that. Then repeatedly shapecast again. You’ll end up with a polyline path. Then it becomes just a matter of moving along a path which you can do exactly.

    But again, you probably want a simpler solution that’s good enough. The quoted pseudo code above is probably the simplest. Especially if you utilize the bullet behavior’s bounce action. However you will need to change from velocity from vx,vy to speed and angle of motion.

    Anyways, just some thoughts.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Or if you want to use just one loop. 

    Start of layout
Repeat layoutWidth*layoutHeight/16/16
— create sprite at 8+loopindex%(layoutWidth/16)*16, 8+int(loopindex/(layoutWidth/16))*16

  • Instead just setting the position you’ll want to do it in steps.

    One idea is to take the angle from the object to the touch position, and then simulate a control if it’s close to that angle. For example: 

    Angle angle(object.x,object.y,touch.x,touch.y) is within 45 degrees of 0
— object: tileMovement: simulate control right

    You’d just do that for 0, 90, 180 and 270 degrees. And you’d depend on the solid behavior to keep from moving over other things.

    Another very visual way to do it is to use some sprites to use as detectors, and position them one grid space in all four directions around the object as well as on the object itself. Then you’d just pick the closest object around the player that wasn’t overlapping something to move to. 

    global uid=-1
On object touch
— set uid to object.uid

Pick object by uid uid
— det: destroy
— create det at object.x, object.y
— create det at object.x+32, object.y
— create det at object.x-32, object.y
— create det at object.x, object.y+32
— create det at object.x, object.y-32

Det overlaps wall
— det: destroy

[inverted] pick object by uid uid
Det overlaps object
— det: destroy

Pick object by uid uid
Det: pick closest to touch.x, touch.y
— object: set position to det.x, det.y

    Just some ideas.

  • What problems? You forgot to specify what they were. I have some down time to guess though, but I may or may not be around to reply again.

    Last I checked the drawing canvas object doesn’t store depth, it only stores color. So pasting 3d objects results in the 3d faces drawn in an arbitrary order instead of sorted with a z buffer.

    If you mean pasting stuff onto a distorted drawing canvas. I think that never worked, or worked as if the canvas wasn’t distorted. But maybe things have changed with newer updates.

  • You probably could do it with a 3d camera too. That would let you use normal text.

  • The description of what you’re after is still pretty vague. However, you can solve any problem by breaking down what you want to do into smaller doable steps.

    It looks like maybe you want to drag icons from the left onto the top. Maybe you could give the icons the drag and drop behavior. Then when you drop them (the one drop trigger) you’d check if it’s overlapping the top bar, and if it is then do something to position it in a nice way. And it’s not overlapping the top bar on drop just move it back to the left toolbar. You could also just move it back to the left toolbar on drop but create a duplicate on the top bar.

    To position them in a nice way on the top bar you could pick all the icons overlapping the top bar, then “for each” the icons, and set the icons position to something like (topbar.x+icon.width*loopindex, topbar.y). That would put them in a nice evenly spaced horizontal line.

    Just some rough ideas that could be a possible starting point.

  • Set rotateSpeed to lerp(rotateSpeed, 0, 0.05)?

  • Couldn’t you just use the bullet behavior, and rotate behavior but gradually reduce the turning rate to zero?

    Behaviorless is similar and easier for me to write off the top of my head and would be: 

    Every 1 second
— create bullet at sprite.x, sprite.y
— bullet: set angle to random(360)
— bullet: set turningRate to random(30,120)

Every tick
— bullet: move forward 150*dt pixels
— bullet: set turningRate to lerp(self.turningRate, 0, 0.05)
— bullet: rotate self.turningRate*dt degrees

    If you used behaviors then you’d basically reuse the action that sets the turning rate to some extent.

  • I mean ignoring hierarchy, waits and such to have the fireball shoot one way or another based on if the enemy is mirrored could be simple as: 

    Every 1 seconds
For each enemy
— enemy: spawn fireball at imagepoint “mouth”
— enemy: is mirrored
— — fireball: apply impulse at angle -30
— else
— — fireball: apply impulse at angle 180+30

    Anyways, the relevant part is the “is mirrored” check. And generally if logic works for one enemy but not consistently with multiple then you can put that logic under a “for each enemy” event.

  • Maybe they are trying to make a merge game? And whatever they tried only works for one instance based on the “note”.

    We are missing information.