Strange behaviour with physics.setDrawMode( "hybrid" )

Solar2D General Questions/Discussion
#1

Hi all,
 
I just updated Corona to the latest daily build and discovered a “weird issue” with hybrid mode, the physics bodies do not appear in the right location, although everything appears to work OK.  I found an update a few daily builds ago in daily build 2935 that I think is the issue.  Does this mean my “weird issue” is actually how it should be looking?
 
“Physics: Fixed debug draw mode to show the real position of physics bodies in groups that have been scaled or translated. This doesn’t fix the issue with using physics objects in groups but will display the true location of the physics body in relation to the display object. Casenum: 46663.”

I have attached two screenshots, one with daily build 2934 where things look OK, and one with daily build 2935 where things are weird.

I have also attached some code to demo issue.

Just wondering if this is actually an issue or something I need to get used to?

Cheers,

Craig

#2

This was a change to fix a bug people were having when this was the “old way” where the physics objects were not adjusting for being in groups. However after the change, people are not liking the fix. There is a new bug report regarding this. I don’t know what the right solution is. I’ll add this link to the bug report.

Rob

#3

Hi Craig,

I explored your report and sample project. What it breaks down to is this: some people (and possibly the third-party “Perspective” library as well) have been taking advantage of the previous bug so that the hybrid mode actually looked correct when moving around display groups. They were probably doing so without even knowing it, lol. However, there have been dozens of forum reports over the years which revealed the bug was valid and that hybrid mode was not behaving correctly. That’s why we fixed the bug in 2935.

We debated adding a flag to “display.setDefault()” that would let you swap between the old buggy style and the new style, but we considered that more effort than it was worth, at the time. I’m still not convinced that is a wise solution.

We’ll explore possibilities on this further, and hopefully we can fix it 100% so that you will see the proper position in hybrid mode regardless of whether you’ve shifted around groups.

Brent

#4

Hi there,

Is there any word on this?  The way it is now makes it quite hard to error check my app that uses a “camera” system.

Cheers,

Craig

#5

Hi again,

This is making error checking my game rather difficult, I keep having to test it with older versions of Corona (eventually this could cause issues).  Can someone please explain in more detail what is going on?  Or better still what I should be doing at my end so I don’t encounter this issue.

Thanks,

Craig

#6

Hi Craig,

I’m sorry to report that the engineers refuse to revert this behavior to the way it was before. I made my case as strongly as I could but they insist that the “new way” is actually more accurate than the old way since you’re not really supposed to be moving physics groups independently of each other. That being said, they fully admit that the new way is not a permanent solution either, and ultimately this must be fixed so that the issue is solved properly, once and for all.

So, my apologies for this and any promises I made toward reverting it. Instead, I’m going to push forward for a permanent fix since the old way was admittedly unreliable in cases of moved groups.

Brent

#7

Thanks Brent,

Sorry to keep pushing, but how am I supposed to be doing a camera then? Or is this no longer supported?

Cheers,

Craig

#8

Hi Craig,

A camera can still be implemented with physics. I can’t recall how you’re doing it now, but my preferred way is to “offset” whatever the object of camera focus is (i.e. your car/truck) in the exact inverse of what should move behind the camera. In doing it that way, you do not shift the physics groups independently of each other, which is (and has always been) effectively disallowed (at least if you want collisions to work properly).

So basically, let’s say you want your terrain to move left. You might do that with a transition.to(), or you might do it with a Runtime X position update. In either case, do not move simply the terrain display group while keeping the car display group un-moved… instead move the entire stage to the left (car/truck too!) but then in the same time step, offset the car/truck by the exact same amount in the opposite direction. For example, if you use a Runtime X shift of -1 (pixels), do that to the entire stage but then set the car/truck’s X position to +1 its previous X position. That will effectively make the car appear as if it never shifted to the left, and yet the terrain will smoothly glide behind it.

Hope this helps,

Brent

#9

Thanks Brent for the quick reply,

The method you described seems to be exactly what I am doing (at least as far as I can see).

I have attached the sample again, but simplified it down so it is clearer what is happening.

If possible can you have a look at the sample and tell me where I am going wrong or misunderstanding…

Cheer

Craig

#10

Hi Craig,

I tested out your project, thanks for re-sending it. Honestly, you aren’t doing anything wrong… your implementation of a camera is fine. However, until the engineers acknowledge that the “new way” was not a real fix and potentially revert it, you won’t be able to get an accurate judge of physics using the hybrid draw mode.

Fortunately, you will be able to keep developing your game and see how objects react as you see them on the screen (not the hybrid trace)… that remains intact, so you can continue testing your game on that basis. In the meantime, I’m going to put increased pressure on the engineers to acknowledge this bug and revert it, or (even better) deliver a real fix that solves the long-standing bug which caused all of this to change.

Best regards,

Brent

#11

Thanks Brent. I appreciate this. Ill keep on developing, I can always test in the older version if I need to. Craig

#12

This was a change to fix a bug people were having when this was the “old way” where the physics objects were not adjusting for being in groups. However after the change, people are not liking the fix. There is a new bug report regarding this. I don’t know what the right solution is. I’ll add this link to the bug report.

Rob

#13

Hi Craig,

I explored your report and sample project. What it breaks down to is this: some people (and possibly the third-party “Perspective” library as well) have been taking advantage of the previous bug so that the hybrid mode actually looked correct when moving around display groups. They were probably doing so without even knowing it, lol. However, there have been dozens of forum reports over the years which revealed the bug was valid and that hybrid mode was not behaving correctly. That’s why we fixed the bug in 2935.

We debated adding a flag to “display.setDefault()” that would let you swap between the old buggy style and the new style, but we considered that more effort than it was worth, at the time. I’m still not convinced that is a wise solution.

We’ll explore possibilities on this further, and hopefully we can fix it 100% so that you will see the proper position in hybrid mode regardless of whether you’ve shifted around groups.

Brent

#14

Hi there,

Is there any word on this?  The way it is now makes it quite hard to error check my app that uses a “camera” system.

Cheers,

Craig

#15

Hi again,

This is making error checking my game rather difficult, I keep having to test it with older versions of Corona (eventually this could cause issues).  Can someone please explain in more detail what is going on?  Or better still what I should be doing at my end so I don’t encounter this issue.

Thanks,

Craig

#16

Hi Craig,

I’m sorry to report that the engineers refuse to revert this behavior to the way it was before. I made my case as strongly as I could but they insist that the “new way” is actually more accurate than the old way since you’re not really supposed to be moving physics groups independently of each other. That being said, they fully admit that the new way is not a permanent solution either, and ultimately this must be fixed so that the issue is solved properly, once and for all.

So, my apologies for this and any promises I made toward reverting it. Instead, I’m going to push forward for a permanent fix since the old way was admittedly unreliable in cases of moved groups.

Brent

#17

Thanks Brent,

Sorry to keep pushing, but how am I supposed to be doing a camera then? Or is this no longer supported?

Cheers,

Craig

#18

Hi Craig,

A camera can still be implemented with physics. I can’t recall how you’re doing it now, but my preferred way is to “offset” whatever the object of camera focus is (i.e. your car/truck) in the exact inverse of what should move behind the camera. In doing it that way, you do not shift the physics groups independently of each other, which is (and has always been) effectively disallowed (at least if you want collisions to work properly).

So basically, let’s say you want your terrain to move left. You might do that with a transition.to(), or you might do it with a Runtime X position update. In either case, do not move simply the terrain display group while keeping the car display group un-moved… instead move the entire stage to the left (car/truck too!) but then in the same time step, offset the car/truck by the exact same amount in the opposite direction. For example, if you use a Runtime X shift of -1 (pixels), do that to the entire stage but then set the car/truck’s X position to +1 its previous X position. That will effectively make the car appear as if it never shifted to the left, and yet the terrain will smoothly glide behind it.

Hope this helps,

Brent

#19

Thanks Brent for the quick reply,

The method you described seems to be exactly what I am doing (at least as far as I can see).

I have attached the sample again, but simplified it down so it is clearer what is happening.

If possible can you have a look at the sample and tell me where I am going wrong or misunderstanding…

Cheer

Craig

#20

Hi Craig,

I tested out your project, thanks for re-sending it. Honestly, you aren’t doing anything wrong… your implementation of a camera is fine. However, until the engineers acknowledge that the “new way” was not a real fix and potentially revert it, you won’t be able to get an accurate judge of physics using the hybrid draw mode.

Fortunately, you will be able to keep developing your game and see how objects react as you see them on the screen (not the hybrid trace)… that remains intact, so you can continue testing your game on that basis. In the meantime, I’m going to put increased pressure on the engineers to acknowledge this bug and revert it, or (even better) deliver a real fix that solves the long-standing bug which caused all of this to change.

Best regards,

Brent