odd physics(?) issue

Sparkyidr

ok.. so I have a set of platforms, I have them moving along the screen along the X axis.
I also have a character jump[ing from platform to platform.

It works really well, but I have a small issue.

When the character lands on the platforms, they shift down the Y axis by a random couple of pixels.
Have tried messing with the density, setting them to like 10000, and setting the players to 0 etc etc.. but it doesn't seem to make any difference.

I guess I need some way of locking the Y position (they are spawning offscreen at a random set of Y values)

Any ideas?

chosenonestudios

Constrain the y value to a number? Or itself or something of the sort.

Not very performance friendly, but it should work.

Sparkyidr

yeah.. thats the only way I can think of doing it too.
just means I will have to have an attribute called platform_y or some such, that can register the Y value of the platform when it's spawned. and then constrain the Y to that attribute.

Seems like a horrible way to do it really.

firemaplegames

In the platform, create an integer attribute called originalY.

And a Change Attribute:

Change Attribute: self.originalY To: self.Position.Y

And then a Rule:

Rule
When all conditions are valid:
self.Position.Y != self.originalY
-----Constrain Attribute: self.Position.Y To: self.originalY

(!= means not equal - the equal sign with a slash)

That's the only way I know of doing it successfully. Constrains can be a drain on the system, so hopefully you don't have too many platforms at once. Wrapping that Constrain in a Rule SHOULD make it behave a little better, as it shouldn't constantly fire.

chosenonestudios

Nice tip FM, I'll be sure to use that.

Sparkyidr

thanks for the input guys.
I did it my way..
i.e.
pass the y value to an actor attribute called yposs, and then just constrained self.y to that.
Only got 2 or 3 platforms onscreen at any one time, so not a massive hit. only lost 1 - 2 frames really.
Will try it your way Joe, see if it's less of a drain.

ORBZ

You can bypass this whole problem by bypassing tge physics engine if you flag the platforms as not movable then move them by hand with constraints on self.position.x set to a function of self.time.

Or interpolated x position instead of constrained.

firemaplegames

Awesome! I wasn't aware that you could Interpolate unmovable objects.

@sparkyidr: use this method!

synthesis

Yep! You can move stuff around easily with movable unchecked...so long as you use interpolate or change attribute or constrains (X and/or Y) as Orbz stated.

Accelerate and Move/MoveTo however require the physics engine...which is great for simple transitions and subtle effects.

I think its a matter of manipulating the actor attributes via a forced static method rather than a dynamic method (via physics behaviors) that requires the physics engine to calculate the behavior.

I assume he previous method uses the graphics engine to process the motion rather than the physics engine.

Sparkyidr

ahh cool.
I'm also assuming that method will be better on the framerates if the physics engine isn't being used for the movement?

Didn't realise you could move unmoveable object in this way. Will give it a go. )

ORBZ

@Sparkyidr

Yes, framerates are better when there are less objects to be computed by the physics engine.

@synth

Graphics engine can't be actually used for processing movement, it just blits gfx to the screen. Movement is being computed in your code. The illusion of movement is when an object changes position rapidly over time.

Downside to this approach is that since you're not using the physics engine there is no collision detection for two objects that are both marked as not movable. At least one object involved in the collision needs to be marked as movable for collision detection to work.

The reason for this is the engine makes the assumtion that if an object is immovable that it can't collide with another object that's immovable. We cheat though when we reposition objects manually. The engine has no idea about this. So keep that in mind when moving around non-movable objects.

Enjoy!

synthesis

@ Orbz...
True...but the static movement option is MUCH better when dealing with non-collision movement...which works great for special effects like tweening menus, floating clouds, scene extras, etc.

As far as graphics vs. physics...it was all a guess what actually was happening under the hood (since the hood is locked down). And seeing as I am 0 for 2 in getting a physics based game out without memory leaks...my next game attempt is purely NON-PHYSICS...a 1st person 2D shooter.