R0J0hound's Recent Forum Activity

  • You could just set the scale to 1 when checking for collision and back to scaled directly after. So the idea would be to save the current scale to a variable, set scale to 1, check for collision, then restore the scale. With some fiddling it should work with whatever system you have in place to adjust the scale.

    Every tick:

    — sprite: set savedscale to self.width/self.originalWidth

    — sprite: set scale to 1

    — sprite: set scaleMe to false

    Mouse: is over Sprite:

    — sprite: set scaleMe to true

    Every tick:

    — sprite: set scale to savedscale

    Sprite: scaleMe

    — sprite: lerp scale to 1.5

    Negated sprite: scaleMe

    — sprite: lerp scale to 1

  • I still think it would be helpful to look at the touch examples for working demonstration of use. Your screenshot shows one thing and you talk about different things. It’s probably a bug with your events, not a bug with the plugin.

    I will say that a Touch ID is different than getting the nth touch

  • Well nothing came to mind when I wrote that. I’ve already become unfamiliar with what my example did.

    Well the idea is simple. Find if a ball shaped player is overlapping the wedge shape. If it is move out in the closest direction. And since gravity and the motion directions aren’t parallel with the slopes sliding occurs which is semi realistic.

    There are likely many solutions. I mentioned the idea to push up maybe when on a slope, but it would require logic to not push up when moving from the sides.

    Possibly we could guess when you want to push up by looking at the z component of the normal.

    Another idea is to disable gravity when on the ground. Again you should be able to know that based on the z of the normal, or we could make the collision detection return what feature of the wedge we are pushing out of. Then when on the ground we could make the motion be parallel to the slope so no sliding would occur. It would require rotating the motion axis’ with the normal.

    Third idea is a vertical ray cast to find the ground level and just change the z to that.

    Anyways most of those would work best by scrapping my example and making a new one.

  • Maybe you could do the parallax manually. Just need two instance variables: startx and rate. Then you could do something like this: 

    Start of layout
— sprite: set startX to self.x-scrollx*self.rate

Every tick
— sprite: set x to self.startx+scrollx*self.rate

    Maybe tweak the start offset as needed.

  • Spritefonts are a good option.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It’s probably just a place to clean up any gpu resources that you created to use for that object. So looks like it’s mentioned if you create text to render. Probably would be a place to release textures you created too.

    construct.net/en/make-games/manuals/addon-sdk/reference/graphics-interfaces/iwebgltext

  • Personally I’d say just go for a simpler interaction with touch. 

    Var startX=0

On touch
— set startX to touch.x

Is touching
— rotate by startx-touch.x
— set startX to touch.x

    Which works great if you only have one touch at once.

    The touch id stuff is only useful when you are dealing with multiple touches. Each distinct touch will have its own unique id.

    Fastest way to get an example of how to use one of the bundled examples.

    But off the top of my head you’d get the id when the touch starts, then use the id to reference that touch, and finally unset the variable when that Touch ID releases. 

    Var myid=-1

On touch
Myid=-1
— set myid to touch.id

Touch: id myid is in touch
— do something

On touch released
Touch.id = myid
— set myid to -1

  • It would but you can keep that in mind when using tokenat. It’s just a complexity trade off.

  • Had a look. Looks like that example just has a terrainheight function that gives the z height of any xy point on the terrain. They used a bunch of formulas to define the shape of the terrain. Cool but not necessarily the easiest to tweak. They could have sampled a greyscale image or used a noise function to define the shape as well.

    The idea could be used with wedges. Basically pick the wedges under an xy, and calculate the z with some math. The main issue is that method isn’t enough to deal with walls too. It’s mostly good for smooth terrain. So wall logic would be separate.

  • I’d have to look.

    I’d think raycasting in the z direction would give the z position on the slope without sliding. There are various ways to do that but projecting the xy position onto the equation for the plane of the top face of the slope is one idea. But youd have to do some checks to consider what direction you were moving into the wedge so you’d hit it from the side and such.

    Or actually we could take the push out direction in my example and if it’s mostly a change of z then do the z ray cast.

  • I’d say what you're doing is fine. You could also add semicolons to the front and back of the string to be able to have one replace work for all positions. Then you could remove the semicolons at the ends with mid() but usually I leave them there if I’m doing that sort of thing.

    Do bear in mind that if two or more tokens are the same then the replace will remove them all.

    A general solution could be to make your own tokenat that returns the index of a token. And then you can remove that with a left and right I imagine.

  • The method works by finding the closest point on the shape’s surface and pushing the object away from that. A side effect of that is wall sliding. Guess you don’t like how it’s slower moving up a slope because of that.

    There isn’t really a fix with this method. Maybe one of the other ideas floating around would help.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 155 followers

Connect with R0J0hound

buymeacoffee.com

Trophy Case

  • 15-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

28/44
How to earn trophies