[Help] Apply Linear Impulse

[pontobarraGAME]

Hello!

I have a problem that has been accompanying me on several projects.

No code needed to explain.

I have an image (game character) stopped and I need to apply a Linear Impulse to simulate a jump.

Object: applyLinearImpulse (xForce, yForce, bodyX, bodyY)

Is there any way for me to know what will be the highest point reached by the image based on the force I apply on the Y axis? In other words, how much the image shifted on the Y axis to the applied force.

My biggest problem is that this image is tailored for every screen resolution. So this influences the size of the image and then the mass of the object. So the force that I need to apply so that it always reaches the height of the obstacle varies according to the screen.

Is there any way to calculate which force should be applied so that the image moves a specific pixel value, based on the gravity, mass of the object, etc? 

Thank you!

[pontobarraGAME]

Anyone have a tip?

I tried physics.scale, scale (letterbox and zoomEven). But still having issues.

[bjsorrentino]

There’s no exact way to determine the adjustment of the force application to meet “will push until this Y value” or similar. You could test a bunch of screen sizes and experiment with an equation to get very close, but that’s the best you could do.

This being said, I personally would not alter my physics gameplay based on screen size. I don’t know what kind of game you’re designing, but I wouldn’t want to give some users the ability to “jump higher” than other users based on the device they’re using… conceptually it just doesn’t seem equal/fair. Now maybe you’ve accounted for this in other areas of the design, but that’s my personally opinion on the matter.

Best regards,

Brent

[pontobarraGAME]

@bjsorrentino

There’s no exact way to determine the adjustment of the force application to meet “will push until this Y value” or similar. You could test a bunch of screen sizes and experiment with an equation to get very close, but that’s the best you could do.

This being said, I personally would not alter my physics gameplay based on screen size. I don’t know what kind of game you’re designing, but I wouldn’t want to give some users the ability to “jump higher” than other users based on the device they’re using… conceptually it just doesn’t seem equal/fair. Now maybe you’ve accounted for this in other areas of the design, but that’s my personally opinion on the matter.

Best regards,

Brent

Hmmmm thanks for the reply.

In my game I do not intend to modify the jump height for different screens. On the contrary, I want it to be the same height, but this is not happening.

I work by creating the images (widths and heights) using a percentage of the screen. For example:

Toon = display.newImage (“main.png”)

Toon.width = display.contentWidth * 0.1

Toon.height = display.contentHeight * 0.1

When doing this, depending on the screen, the image has a different dimension (300x500, 250x300, etc). And with that, the force I use in applyImpulse, is boosting that image at different distances for each screen. Should this really be happening? Could you indicate an alternative so that this does not happen?

Taking advantage of the question, do you advise using the percentage-based dimensions of the screen? Or is there any way to specify in pixels, and the corona itself resize based on the screen of the phone, always considering how the objects were distributed in the simulator? And maybe, also “resize” the applyimpulse.

Thank you very much.

[bjsorrentino]

Hello again,

What appears to be happening is that, because the percentage-based calculations are changing the object size, the mass of the object also changes… and that affects how much a static impulse will affect things (bigger object is “heavier” in the physics simulation, thus the same impulse will affect it less).

I prefer to work with a dedicated content size (“letterbox” or “zoomEven”) and consistent object sizes, especially when using physics. I then “fill” the empty areas with visual content (letterbox mode), or I accept that some visual will be obscured on some screens (zoomEven).

If you want to stick with percentages, then you might have success by making the physics body (Toon) a “kinematic” object instead of “dynamic” and then, instead of using impulse, control its Y position via a Runtime function that basically mimics the effect of gravity (slows down as it reaches its peak, speeds up as the object begins to fall). This would give you direct control to move the object to basically any vertical position without physical forces having any affect upon it.

Hope this helps,

Brent

[sporkfin]

@pontobarraGAME

To maintain gravity and physics integrity, the display world and the physics world need to be bound together - which means NO scaling unless everything is scaled identically.  Instead of tailoring the size of the image for different screen resolutions, set up a standard size for your world and then zoom the entire world in or out depending on the device.

I’ve used this solution to solve several related problems.  

Alternately, you can run a bunch of experiments on varying bodies - measuring their mass , gravity and velocity to determine where things will land and the forces involved but it is much easier to just scale the whole world uniformly.  I learned this the hard way 

[pontobarraGAME]

@sporkfin

@pontobarraGAME

To maintain gravity and physics integrity, the display world and the physics world need to be bound together - which means NO scaling unless everything is scaled identically.  Instead of tailoring the size of the image for different screen resolutions, set up a standard size for your world and then zoom the entire world in or out depending on the device.

I’ve used this solution to solve several related problems.  

Alternately, you can run a bunch of experiments on varying bodies - measuring their mass , gravity and velocity to determine where things will land and the forces involved but it is much easier to just scale the whole world uniformly.  I learned this the hard way 

Oh thank for the tips.

Im a little confused for now about this Physic World you are saying. Where do I define it?

Its the “width” and “heigh” inside config.lua file?

[pontobarraGAME]

@bjsorrentino

Hello again,

What appears to be happening is that, because the percentage-based calculations are changing the object size, the mass of the object also changes… and that affects how much a static impulse will affect things (bigger object is “heavier” in the physics simulation, thus the same impulse will affect it less).

I prefer to work with a dedicated content size (“letterbox” or “zoomEven”) and consistent object sizes, especially when using physics. I then “fill” the empty areas with visual content (letterbox mode), or I accept that some visual will be obscured on some screens (zoomEven).

If you want to stick with percentages, then you might have success by making the physics body (Toon) a “kinematic” object instead of “dynamic” and then, instead of using impulse, control its Y position via a Runtime function that basically mimics the effect of gravity (slows down as it reaches its peak, speeds up as the object begins to fall). This would give you direct control to move the object to basically any vertical position without physical forces having any affect upon it.

Hope this helps,

Brent

Hey Brent. Thank you so much.

Im checking about the scale parameter. Trying use letterbox for now and understand how it work.

Also im trying understand about this “physic world” and the “screen world”.

You helped a lot.

[bjsorrentino]

Hi again,

There’s really just one “physics world” and that’s what your game will use. I think what @sporkfin is saying is that it’s best to use a typical content area scale mode like “letterbox” and then, if you need to, scale the entire visual “stage” (but this isn’t even necessary in most cases).

First thing I suggest is that you fully understand the Corona “content area” and the differences between each mode. This guide should get you on the right track:

https://docs.coronalabs.com/guide/basics/configSettings/index.html#content-scaling

Once you have that established, we can return to discussing physics-related matters.

Brent

[pontobarraGAME]

Hi Brent.

I have already published 12 games, and have always worked resizing the images by percentage. Luckily, most of them used only the static and kinematic.

I will look at this with urgency, thank you very much.

[sporkfin]

Hi pontobarraGAME,

The “physics world” is anything entered into the physics engine.  You enter parameters to approximate the size and shape of your display objects, but the physics are invisible (unless you change the draw mode).  The “display world” is what you see.

It’s probably more clear to say scale the “stage” as Brent did.

[pontobarraGAME]

Anyone have a tip?

I tried physics.scale, scale (letterbox and zoomEven). But still having issues.

[bjsorrentino]

There’s no exact way to determine the adjustment of the force application to meet “will push until this Y value” or similar. You could test a bunch of screen sizes and experiment with an equation to get very close, but that’s the best you could do.

This being said, I personally would not alter my physics gameplay based on screen size. I don’t know what kind of game you’re designing, but I wouldn’t want to give some users the ability to “jump higher” than other users based on the device they’re using… conceptually it just doesn’t seem equal/fair. Now maybe you’ve accounted for this in other areas of the design, but that’s my personally opinion on the matter.

Best regards,

Brent

[pontobarraGAME]

@bjsorrentino

There’s no exact way to determine the adjustment of the force application to meet “will push until this Y value” or similar. You could test a bunch of screen sizes and experiment with an equation to get very close, but that’s the best you could do.

This being said, I personally would not alter my physics gameplay based on screen size. I don’t know what kind of game you’re designing, but I wouldn’t want to give some users the ability to “jump higher” than other users based on the device they’re using… conceptually it just doesn’t seem equal/fair. Now maybe you’ve accounted for this in other areas of the design, but that’s my personally opinion on the matter.

Best regards,

Brent

Hmmmm thanks for the reply.

In my game I do not intend to modify the jump height for different screens. On the contrary, I want it to be the same height, but this is not happening.

I work by creating the images (widths and heights) using a percentage of the screen. For example:

Toon = display.newImage (“main.png”)

Toon.width = display.contentWidth * 0.1

Toon.height = display.contentHeight * 0.1

When doing this, depending on the screen, the image has a different dimension (300x500, 250x300, etc). And with that, the force I use in applyImpulse, is boosting that image at different distances for each screen. Should this really be happening? Could you indicate an alternative so that this does not happen?

Taking advantage of the question, do you advise using the percentage-based dimensions of the screen? Or is there any way to specify in pixels, and the corona itself resize based on the screen of the phone, always considering how the objects were distributed in the simulator? And maybe, also “resize” the applyimpulse.

Thank you very much.

[bjsorrentino]

Hello again,

What appears to be happening is that, because the percentage-based calculations are changing the object size, the mass of the object also changes… and that affects how much a static impulse will affect things (bigger object is “heavier” in the physics simulation, thus the same impulse will affect it less).

I prefer to work with a dedicated content size (“letterbox” or “zoomEven”) and consistent object sizes, especially when using physics. I then “fill” the empty areas with visual content (letterbox mode), or I accept that some visual will be obscured on some screens (zoomEven).

If you want to stick with percentages, then you might have success by making the physics body (Toon) a “kinematic” object instead of “dynamic” and then, instead of using impulse, control its Y position via a Runtime function that basically mimics the effect of gravity (slows down as it reaches its peak, speeds up as the object begins to fall). This would give you direct control to move the object to basically any vertical position without physical forces having any affect upon it.

Hope this helps,

Brent

[sporkfin]

@pontobarraGAME

To maintain gravity and physics integrity, the display world and the physics world need to be bound together - which means NO scaling unless everything is scaled identically.  Instead of tailoring the size of the image for different screen resolutions, set up a standard size for your world and then zoom the entire world in or out depending on the device.

I’ve used this solution to solve several related problems.  

Alternately, you can run a bunch of experiments on varying bodies - measuring their mass , gravity and velocity to determine where things will land and the forces involved but it is much easier to just scale the whole world uniformly.  I learned this the hard way 

[pontobarraGAME]

@sporkfin

@pontobarraGAME

To maintain gravity and physics integrity, the display world and the physics world need to be bound together - which means NO scaling unless everything is scaled identically.  Instead of tailoring the size of the image for different screen resolutions, set up a standard size for your world and then zoom the entire world in or out depending on the device.

I’ve used this solution to solve several related problems.  

Alternately, you can run a bunch of experiments on varying bodies - measuring their mass , gravity and velocity to determine where things will land and the forces involved but it is much easier to just scale the whole world uniformly.  I learned this the hard way 

Oh thank for the tips.

Im a little confused for now about this Physic World you are saying. Where do I define it?

Its the “width” and “heigh” inside config.lua file?

[pontobarraGAME]

@bjsorrentino

Hello again,

What appears to be happening is that, because the percentage-based calculations are changing the object size, the mass of the object also changes… and that affects how much a static impulse will affect things (bigger object is “heavier” in the physics simulation, thus the same impulse will affect it less).

I prefer to work with a dedicated content size (“letterbox” or “zoomEven”) and consistent object sizes, especially when using physics. I then “fill” the empty areas with visual content (letterbox mode), or I accept that some visual will be obscured on some screens (zoomEven).

If you want to stick with percentages, then you might have success by making the physics body (Toon) a “kinematic” object instead of “dynamic” and then, instead of using impulse, control its Y position via a Runtime function that basically mimics the effect of gravity (slows down as it reaches its peak, speeds up as the object begins to fall). This would give you direct control to move the object to basically any vertical position without physical forces having any affect upon it.

Hope this helps,

Brent

Hey Brent. Thank you so much.

Im checking about the scale parameter. Trying use letterbox for now and understand how it work.

Also im trying understand about this “physic world” and the “screen world”.

You helped a lot.

[bjsorrentino]

Hi again,

There’s really just one “physics world” and that’s what your game will use. I think what @sporkfin is saying is that it’s best to use a typical content area scale mode like “letterbox” and then, if you need to, scale the entire visual “stage” (but this isn’t even necessary in most cases).

First thing I suggest is that you fully understand the Corona “content area” and the differences between each mode. This guide should get you on the right track:

https://docs.coronalabs.com/guide/basics/configSettings/index.html#content-scaling

Once you have that established, we can return to discussing physics-related matters.

Brent

[pontobarraGAME]

Hi Brent.

I have already published 12 games, and have always worked resizing the images by percentage. Luckily, most of them used only the static and kinematic.

I will look at this with urgency, thank you very much.