Zebbi,

Thanks for buying it! The P2 plugin has a wall hang only so anything additional that you do via events will be good! If the player is moving at int positions then it's not P2 - my plugin works to 1/8 pixel iirc (I'll check).

Jump height is different because the standard plugin doesn't use Newton's equations of motion, only an approximation, which means that different frame rates will give different jump heights.... But this is not a problem with P2 :)

That and a completely different collision system (including filtering) are the main differences.

There shouldn't be any latency compared to the standard plugin. I'm intrigued by what you could mean for that.

Cheers!

Yeah, as we worked out, it's because platform+ registers the input during pause, whereas platform2 doesn't. I've tried matching the jump heights and jump speeds, but it's quite tricky to get a frame accurate match, specifically because I can can't change the timescale without it screwing up platform+'s height scale (which platform2 THANKFULLY fixes!) so step incrementing is the only real option for side-by-side testing. I assume incrasing gravity will increase the jump acceleration speed, which is the hardest part to match between the two, specifically the initial launch speed of the jump, and platform2 always seems a little slower to launch the jump. I'm not sure how to take Newton's laws:

v * v = u * u + 2 * a * s

= (v * v - u * u) / (2 * a)

is distance traveled which, in this case, is jump height; so jump height = jump strength squared >divided by 2 x gravity

ccording to Newton(edited)

o, double the jump speed = you jump 4 times the height (due to velocity squared)

and apply that to my platform+ settings to get the closest possible match I can. The reason I need it exact is for porting a couple of game engines already designed with previous platform settings, and also so I can finish writing a walljump group of events that accurately matches platform+ (which is tough to do by comparison without the rest of the speeds matched).

I have an array with 2 rows, one for an animation name, and the second row for a paired variable. When a particular object is destroyed, I have it write the two values from the object to the array:

s15.postimg.cc/5d8n1ya0b/flish1.png

I'm trying to then delete the element if I'm overlapping a different object that matches the second rows value. I've tried a few ways:

s15.postimg.cc/ivfjdq6kr/unknown.png

s15.postimg.cc/ivfjdq6kr/unknown.png

s15.postimg.cc/ivfjdqtq3/unknown_1.png

s15.postimg.cc/9avwqvjtn/unknown_4.png

Basically, I want this:

s15.postimg.cc/cuhugphej/unknown_2.png

to become this:

s15.postimg.cc/n4k9fz9uz/unknown_3.png

Any ideas how I can get this element deleted?

You can do it without behaviors. Just give the object an x and y velocity and do the bouncing by checking if walls are going to be hit horizontally or vertically. If they are, then reverse the velocity.

> Globals:
G=100

Instance variables:
Vx=0
Vy=0

Every tick
— sprite: add g*dt to vy

Sprite: overlaps wall at offset (self.vx*dt, 0)
— sprite: set vx to -self.vx

Sprite: overlaps wall at offset (0, self.vy*dt)
— sprite: set vy to -self.vy

Every tick
— sprite: set x to self.x+self.vx*dt
— sprite: set y to self.y+self.vy*dt

Just set vx and vy when the player throws it. You can adjust g to taste.

Should be pretty close. At the very least you’ll get the perfect bounces. There are improvements that could be had. Here are a few of them that may be of interest:

Possible improvements:

The sprite needs to be outside of walls when it starts and throughout the motion. If it’s in a tight area, or it’s started inside a wall, then you need to move it out of the wall first.

Usually not an issue if created inside the players collision area, and it’s given enough room to move around.

There can be energy loss with vertical bouncing at times. The sprite will bounce lower after a few bounces.

One reason for this is variable dt. You can help correct this by replacing self.vy*dt in all expressions with self.vy*dt+0.5*g*dt*dt.

Bouncing is done by checking where the ball will be a frame later. You can get more precise bounces by calculating when the wall is hit exactly before bouncing then moving again with the remaining time. Not really necessary but has advantages for very fast sprites.

A final idea is to only use integers for position and speed, and always use a fixed dt. This complicates it a bit but it removes energy loss from rounding caused by floating point numbers.

Thanks so much R0J0hound I really appreciate it, looks awesome! So G is speed, and setting Vx and Vy at spawn time sort of controls how high and far they are thrown?

Bouncing is done by checking where the ball will be a frame later. You can get more precise bounces by calculating when the wall is hit exactly before bouncing then moving again with the remaining time. Not really necessary but has advantages for very fast sprites.

I'm not exactly sure how this could be done, although Jill's blade moves fairly slowly, I'm interested in what method could be used.

A final idea is to only use integers for position and speed, and always use a fixed dt. This complicates it a bit but it removes energy loss from rounding caused by floating point numbers.

Should I encapsulate all variables in int() to achieve this? And how is dt made to be fixed (presumably so it's not machine independent?