Scaling physics bodies with images problem!

Solar2D General Questions/Discussion
#1

Hi all, I want to make use of the multitouch/pinch zoom feature to allow the player zoom in and out of the level. IE. The level will be 2 screens wide and 2 screens high.

Problem I am having, is that my physics bodies are not scaling with the images… so for example, the physics body for my terrain is no longer correctly scaled/positioned in relation to the image the player is seeing! And I would like the player to be able to take his next shot from his current view… be that zoom 100% or 50%!

I am not keen on removing and adding physics bodies each and everytime I zoom… and because I am using complex shapes, it could open a can of worms!

Is there an easier way!!! Why cant the physics body scale with the image?
Example. Add the last 2 lines of code to the eggbreaker example and turn physics to hybrid view.

[code]
– Launch boulder

local boulder = display.newImage( “boulder.png” )
game:insert( boulder )

– initial body type is “kinematic” so it doesn’t fall under gravity
physics.addBody( boulder, { density=15.0, friction=0.5, bounce=0.2, radius=36 } )

boulder.xScale = 0.5
boulder.yScale = 0.5
[/code] [import]uid: 12583 topic_id: 20785 reply_id: 320785[/import]

#2

Ok, I’ve just added a physics:removeBody followed by a physics:addBody to an enterFrame listener which I only run when zooming = true.

So basically, if the player is zooming IN or OUT… I set zooming = true, remove the current physics body and then add a new one (using a scale multiplier from the gameGroup.xScale… which is the background/level images group)

This seems to work ok… although I had to up my FPS to 60 in my config… otherwise I got a little bit of jitter between frames when the physics bodies were beng calculated.

Anyone any thoughts on whether this will have a hugh impact of performance? Any good links to discussion on FPS = 60

Cheers
[import]uid: 12583 topic_id: 20785 reply_id: 81741[/import]

#3

Performance would be better if you could avoid this, although that depends on what you are doing.

Do the physics bodies always need to be the perfect size during the zoom, or could you set them accordingly when the user stopped zooming, for example?

Peach :slight_smile: [import]uid: 52491 topic_id: 20785 reply_id: 81826[/import]

#4

Hi Peach

I am thinking they always need to be perfect, because I will have objects, such as a ball, on the physics body (ground terrain in this example) during the zoom.

When you say “better if you could avoid this”… are you refering to the FPS=60 or the updating physics body in enterframe listener?

I was looking into the new time based physics option in the daily build 721… might do some tests with that set to 1/30.

How would you approach this simple scenario:

ground object with static phsyics body
ball object dynamic… sitting on ground
zoom in and out… thus scaling ground and ball objects

Thanks for the help
R
[import]uid: 12583 topic_id: 20785 reply_id: 81835[/import]

#5

I meant the enterFrame listener, not the FPS settings.

Test it and see how it goes - if it works OK then that’s all well and good, if you get some lag then it would be time to look at possible alternatives, although these would be workarounds and not true solutions they could do the job.

(Eg, making the ball appear to stay on the ground but in fact it is just moving during the scaling then the body is added at the end of the event, etc.)

Peach :slight_smile: [import]uid: 52491 topic_id: 20785 reply_id: 81849[/import]

#6

I hear ya Peach…

I’ll do some testing on a device… the older the better… and update with my findings if anyone else has same issue/challenge.

I’ll also try that suggestion re: move ball then add body after event… I like the sound of it.

Thanks again
R :slight_smile: [import]uid: 12583 topic_id: 20785 reply_id: 81852[/import]

#7

Ok, got to the bottom of this… but not sure whether I have found a bug!

I started coding a simple level, with a ball, a floor and some walls… which I wanted to be able to pan and zoom around before taking a shot.

But I found that when I scaled a group or image… the physics bodies didnt scale with the images.(in physics hybrid mode) So I read on the forums about other devs with similar issues and a possible work around which involved removing and re-adding the physics bodies (with scale factor applied) after scaling the group.

This seemed to do the trick, with physics draw mode set to hybrid I could see all was well! So I thought!

Once I sorted this, I set about adding the impulse to my ball. NOTE: I hadnt actually fired the ball yet… or dropped it from a height.

But when I fired the ball the physics was not behaving… it appeared to be colliding with an invisible body. Almost like the physics bodies were all wrong.

So I played with the Egg Breaker sample code and have foudn that, when you scale an image which had a physics body added… the physics body scales with it… as far as the physics engine is concerned… ie. view everything in normal mode and all is fine. BUT, if you view in hybrid OR debug mode, the physics bodies have not scaled… making you think its not working and adding unnecessary code, which ultimately is breaking things.
To see the problem, simply scale the ball in the Egg breaker example and turn on physics in hybrid mode… The simulation works but the physics bodies drawn have not scaled
Is this a bug? Am I safe to go ahead on the assumption all is well, and the simulator just isnt drawing the physics bodies accurately after scaling???

Cheers
Richie

[import]uid: 12583 topic_id: 20785 reply_id: 82456[/import]

#8

It’s the debug draw mode not updating. Yeah [import]uid: 84637 topic_id: 20785 reply_id: 82583[/import]

#9

Cheers Danny

Can I take it this has been logged as a bug?
Richie [import]uid: 12583 topic_id: 20785 reply_id: 82673[/import]

#10

I believe so. Il check, and report back [import]uid: 84637 topic_id: 20785 reply_id: 82692[/import]

#11

Although this was reported as fixed in a recent update, it’s still not fixed.

#12

Although this was reported as fixed in a recent update, it’s still not fixed.