Build 2935's draw mode fix... not fixed?

Physics
#1

RE:

Thu, 2016-08-25 03:36

Release notes for build 2016.2934 through 2016.2935

  • 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 was excited to read this, as I could really use it.  But does it actually work?  Doesn’t seem to.

  Here’s the “DebugDraw” sample, modified with a simple “shake” -type camera (slowed down, so effect is distinguishable), the entire world (minus the buttons, who cares) is in this single group and so remains consistent; the camera group is subjected to animated transforms, but the debug/hybrid display remains static:

-- -- Abstract: DebugDraw sample project -- Demonstrates physics.setDrawMode() and draggable objects using "touch joints" -- -- Version: 1.3 (September 27, 2010) -- includes new "gameUI" library for dragging objects -- -- Sample code is MIT licensed, see https://www.coronalabs.com/links/code/license -- Copyright (C) 2010 Corona Labs Inc. All Rights Reserved. -- -- Supports Graphics 2.0 --------------------------------------------------------------------------------------- -- MODIFED WITH CAMERA LAYER TO TEST DEBUG/HYBRID PHYSICS DRAW MODES local centerX = display.contentCenterX local centerY = display.contentCenterY local \_W = display.contentWidth local \_H = display.contentHeight local physics = require("physics") local gameUI = require("gameUI") physics.start() system.activate( "multitouch" ) display.setStatusBar( display.HiddenStatusBar ) local bkg = display.newImage( "night\_sky.png", 160, 240 ) local camera = display.newGroup() local instructionLabel = display.newText( "drag any object", centerX, 25, native.systemFontBold, 20 ) instructionLabel:setFillColor( 1, 1, 1, 40/255 ) local ground = display.newImage(camera, "ground.png", 160, 415 ) -- physical ground object physics.addBody( ground, "static", { friction=0.5, bounce=0.3 } ) local grass2 = display.newImage(camera, "grass2.png", 160, 464) -- non-physical decorative overlay local dragBody = gameUI.dragBody -- for use in touch event listener below local function newCrate() rand = math.random( 100 ) local j if (rand \< 45) then j = display.newImage(camera, "crate.png"); j.x = 60 + math.random( 160 ) j.y = -100 physics.addBody( j, { density=0.9, friction=0.3, bounce=0.3 } ) elseif (rand \< 60) then j = display.newImage(camera, "crateB.png"); j.x = 60 + math.random( 160 ) j.y = -100 physics.addBody( j, { density=1.4, friction=0.3, bounce=0.2 } ) elseif (rand \< 80) then j = display.newImage(camera, "rock.png"); j.x = 60 + math.random( 160 ) j.y = -100 physics.addBody( j, { density=3.0, friction=0.3, bounce=0.1, radius=33 } ) else j = display.newImage(camera, "crateC.png"); j.x = 60 + math.random( 160 ) j.y = -100 physics.addBody( j, { density=0.3, friction=0.2, bounce=0.5 } ) end j:addEventListener( "touch", dragBody ) end local function drawNormal() physics.setDrawMode( "normal" ) end local function drawDebug() physics.setDrawMode( "debug" ) end local function drawHybrid() physics.setDrawMode( "hybrid" ) end local function setPhysicsDrawMode( event ) local newDrawMode = event.target.drawMode if event.phase == "began" then --Set the new draw mode physics.setDrawMode( newDrawMode ) end return true end --Create 3 buttons to change between physics draw modes local button = {} button[1] = display.newImage( "smallButton.png", true ) button[1].drawMode = "normal" button[1].label = display.newText( "Normal", 0, 0, native.systemFont, 16 ) button[1].x = 55 button[1].y = 450 button[1].label.x = button[1].x button[1].label.y = button[1].y button[2] = display.newImage( "smallButton.png", true ) button[2].drawMode = "debug" button[2].label = display.newText( "Debug", 0, 0, native.systemFont, 16 ) button[2].x = 160 button[2].y = 450 button[2].label.x = button[2].x button[2].label.y = button[2].y button[3] = display.newImage( "smallButton.png", true ) button[3].drawMode = "hybrid" button[3].label = display.newText( "Hybrid", 0, 0, native.systemFont, 16 ) button[3].x = 265 button[3].y = 450 button[3].label.x = button[3].x button[3].label.y = button[3].y for i = 1, #button do -- Make buttons into physics objects so they remain visible in "debug" draw mode physics.addBody( button[i], "static", { density=1.0 } ) --Add event listener to all buttons button[i]:addEventListener( "touch", setPhysicsDrawMode ) end local dropCrates = timer.performWithDelay( 500, newCrate, 120 ) local frameCounter = 0 local function onEnterFrame() local r = 30 local t = frameCounter \* 0.01 camera.x = r \* math.cos(t) camera.y = r \* math.sin(t) camera.rotation = math.sqrt(r) \* math.cos(t) \* math.sin(t) local s = 1.0 + math.cos(-t) \* math.cos(-t) \* 0.2 camera.xScale, camera.yScale = s, s frameCounter = frameCounter + 1 end Runtime:addEventListener("enterFrame", onEnterFrame)
#2

Hi Dave,

This one is a bit of a pickle. Our fix was to resolve what was previously a bug, but people seem to like the buggy version more than the fixed version. We’re discussing how to handle this… ultimately we need to fix it permanently (as in, extend this half-fix that you noted for build 2935). I’ll push for some increased traction on this…

Brent

#3

Hi Brent,

how are we supposed to design and view our physics bodies if they do not display properly on screen, i.e. the physics bodies do not follow their actual display objects?

We have a platformer/runner game in which we simulate the camera movement by translating a main parent group which contains all physics objects. The problem now is that when the parent group moves, the physics bodies of its children stay still and get “detached” from their actual display objects. In our case, because the translation of the parent group is very large, the physics bodies do not show at all on screen. Although this misplacement does not affect the actual functionality, it renders the"hybrid" and “debug” modes useless and thus it is impossible for us to design and test our physics bodies.

We’ve now switched to an older Corona build, but we really need to be able to work on your newest builds. So please fix this issue! Revert to the old method, or provide a way to switch between the two modes.

Thanks for your help,

Elpida

#4

Hi Elpida,

I’m now leaning toward reverting to the previous behavior, since the community has spoken. I’ll keep you posted on what the engineers report back to me on this point.

Best regards,

Brent

#5

That’s good to hear Brent, thanks for this!

#6

This sounds really good because now my camera system is not in sync with the hybrid view, when it previously was. Maybe be able to insert the debug draw/hybrid overlay in a specific parent/group?

Here is my example of the problem: video link

Any news on this?

#7

Hi all,

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

#8

Sounds ok, if is to solve many problems new programmers might make. But I do think a really good and fast fix would be for us to “choose” where the debug elements are drawn, or modify the groups x and y, so we can align it to our moving group (camera)

imagine it like this:

local debugGroup = physics.getDebugGroup() camera:add(debugGroup)

Instead of the debug group being drawn on top of everything else.

Or, something else to control the group’s position, like

physics.setDebugDrawPosition(x, y)
#9

Brent, thanks for updating us on this. We really appreciate your effort.  

You say: “…you’re not really supposed to be moving physics groups independently of each other.” In our case we do not move groups independently of each other. There is one single parent group that contains all physics objects. This is a platformer game, so this group is several screens wide and tall. A character moves inside this platform and in order for the “camera” to follow the character, this parent group needs to move in both x and y. See the video here: http://avokiddo.com/apps/thinkrolls-kings-queens

This simple functionality will not work with the “new way”. We are not able to view our physics objects in real-time while playing the game. 

Since the engineers refuse to revert to the “old method” can they suggest a way we can test our physics objects in the above case? Am I missing something? 

#10

my use is like @basiliogerman and @elvo - a single parent group that operates as a “camera”

the engineers appear to have misunderstood the problem and instead attacked a straw man.   we all know that “moving physics groups independently of each other” doesn’t work, but none of us are doing that nor asking for that.

putting the entire physics world inside a single “camera” group works just fine, and the world remains completely consistent.  it’s only the debug/hybrid display that is mis-rendered if that group is translated/scaled/rotated in any way.

#11

P.S.  here is a game having a 4DOF (X,Y,Z,Zrot) camera, the physics remain entirely consistent throughout, but debug/hybrid is completely useless:  

P.P.S.  i like @basiliogerman’s idea/approach of specifying a single group for the debug/hybrid display to follow.  The ability to insert a theoretical debug “group” literally inside the camera group (as shown) would be ideal.  But it need not be literally “inside” the group (implying that it might need to also respect isVisibile and alpha and all else - it does not) just so long as it can mimic the group’s transform.

#12

I completely agree with @davebollinger, this is exactly what the problem is. Brent, can we have the engineers’s reply on this matter?

#13

Every one of you is absolutely correct: this is a clear and obvious bug. I’m going to put increased pressure on the engineers to acknowledge it, and either revert it or deliver a real fix that solves this whole mess once and for all. I’m sort of going at this as a “one-man army” but your evidence of how broken it currently is will help bolster the war effort. :slight_smile:

Brent

#14

Personally, i don’t consider it broken, the graphical representation is true to the simulation. It could just be improved by being able to position the debug view freely on any position, rotation and scale.

#15

How’s this going? :slight_smile:

#16

Any news on this Brent?

#17

Hi @elvo,

For now, we reverted this to the classic behavior in a recent daily build (past week or so). Grab the most recent and it should behave as it did in the past.

Best regards,

Brent

#18

That’s great news, thank you! :slight_smile:

#19

Hi Dave,

This one is a bit of a pickle. Our fix was to resolve what was previously a bug, but people seem to like the buggy version more than the fixed version. We’re discussing how to handle this… ultimately we need to fix it permanently (as in, extend this half-fix that you noted for build 2935). I’ll push for some increased traction on this…

Brent

#20

Hi Brent,

how are we supposed to design and view our physics bodies if they do not display properly on screen, i.e. the physics bodies do not follow their actual display objects?

We have a platformer/runner game in which we simulate the camera movement by translating a main parent group which contains all physics objects. The problem now is that when the parent group moves, the physics bodies of its children stay still and get “detached” from their actual display objects. In our case, because the translation of the parent group is very large, the physics bodies do not show at all on screen. Although this misplacement does not affect the actual functionality, it renders the"hybrid" and “debug” modes useless and thus it is impossible for us to design and test our physics bodies.

We’ve now switched to an older Corona build, but we really need to be able to work on your newest builds. So please fix this issue! Revert to the old method, or provide a way to switch between the two modes.

Thanks for your help,

Elpida