R0J0hound's Recent Forum Activity

  • 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.

  • 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.

  • Instead of touch.x which grabs the coordinates from the bottom layer you can use touch.x("TouchInderface") to get it from the specific 2d layer.

    That should solve the touch coordinates issue I think.

  • Most of the ideas have limited times they can be used. Events aren’t flexible in all ways so I generally decide what I want to do with consideration of what you can do with events.

    Stuff like interfaces lose me. I mean I could look up what they do but they seem like just an abstraction like much of object oriented stuff that just adds complexity.

    The event system is basically a mix of multiple things. The picking system which is kind of like functional programming, and without that it’s structured programming like a limited c without pointers or structures. On the object oriented front we have plugins which act as objects and families which are more like genetics than inheritance. I guess behaviors and custom actions could considered a bit object oriented too.

    As a whole the event system doesn’t adhere to any specific paradigm or even map directly to JavaScript. It’s just a little of everything with many useful parts, arguably missing parts, and a few really awkward parts that require you to choose a different approach when doing some things.

    In the end we all have our preference on how we want to structure or abstract our code.

    Personally I want to use as few languages as possible so I use events and js only to add missing engine features when absolutely necessary. The engine as a whole has good coverage of features but like anything it has limits which require doing things a different way. I don’t make plugins or effects because I hate dealing with build systems, I don’t want to maintain such addons and deal with comparability across browsers and systems. The reason I use a program like construct is because I enjoy the fast edit->run cycle to iterate on stuff. My goal is to do stuff in the least amount of events possible while remaining readable so only add abstractions where it simplifies stuff and makes it readable.

    Cheers

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You could set an instance variable to self.y and use “pick highest variable”.

    Or You could add a “for each ordered by sprite.y descending” with a stop loop action.