updated from build 1076 to 1202 and will crash upon function use

[russm305]

I have a function that allows the user to draw a line on the screen.  With build 1202 it will crash the game upon drawing a line.  Terminal says:

Terminal: line 9:  2966 Segmentation fault: 11  “$path/Corona Simulator.app/Contents/MacOS/Corona Simulator” $*

logout

So I don’t what changes need to be made.  The function is a line drawing i got from code-exchange

<lua>

    function drawLine(e)

            if e.phase == “began” then

                prev_x = e.x

                prev_y = e.y

              elseif e.phase == “moved” then

                       lines[line_number] = display.newLine(prev_x, prev_y, e.x, e.y) 

                     lines[line_number]:setColor(0,191,255)

                    lines[line_number].width = line_width

                    group:insert(lines[line_number])

                    dist_x = e.x - prev_x

                    dist_y = e.y - prev_y

                        – Add a physics body that’s a flat polygon that follows each segment of the line

                    physics.addBody(lines[line_number], “static”, { density = 1, friction = 1, bounce = .1, shape = {0, 0, dist_x, dist_y, 0, 0} } )

                       prev_x = e.x

                    prev_y = e.y

                        line_number = line_number + 1

              elseif e.phase == “ended” then

              end

        

    end

    Runtime:addEventListener(“touch”, drawLine) 

[CineTek]

You are adding a physics body to your line. This did not return any errors in the past but now it does. You should use display.newRect() to fix this.

[russm305]

Yes the physics in the line is main part of the game

Do yo u mean instead of :

 lines[line_number] = display.newLine(prev_x, prev_y, e.x, e.y)

do this:

 lines[line_number] = display.newRect(prev_x, prev_y, e.x, e.y)

because now i am getting an error in the folowng line-

/Users/russm305/Desktop/Electic Portals/pepper15.lua:611: attempt to call method ‘setColor’ (a nil value)

stack traceback:

    [C]: in function ‘setColor’

    /Users/russm305/Desktop/Electic Portals/pepper15.lua:611: in function </Users/russm305/Desktop/Electic Portals/pepper15.lua:604>

    ?: in function <?:218>

How should I change the affected lines of code?

Is this considerd a bug that I should report?

[CineTek]

You are getting this error because lines[line_number] is a nil value. This means that there is an error in the creation process of the object.

I can see that you are using 

lines[line\_number] = display.newRect(prev\_x, prev\_y, e.x, e.y)  

 to create a rect…

If you take a look at Corona docs you will see that you need to change this code to create a rect:

display.newRect( left, top, width, height )

You can not take the same arguments you used for display.newLine since it uses the third and fourth one to create the ending points of a line.

Edit: Unfortunately I do not know a workaround if you are using dynamically created objects with different length values

[russm305]

Its a shame that things I have been using for months no longer work when I upgrade my build.  

Would you consider this a bug that needs to be reported?

[CineTek]

I don´t think that CoronaLabs recognises this as a bug. But you should ask someone from their staff if they have a workaround for this unless someone else is posting here one

[bjsorrentino]

Hi @russm305,

I believe this was already filed as a bug. When I investigated and tested the issue last (about a month ago), it seems that lines were accepting physics bodies in a previous build, but the results were very inconsistent, especially if you tried to apply it to an angular line (not a 90-degree increment). In addition, lines are not really intended to work with physics bodies, since other physics objects may pass through a thin line. As a result, I think the engineers are steering people away from lines as physics bodies, for better functionality and reliability in the physics engine.

As for the new error you’re getting when you change it over, rectangles accept :setFillColor(), not :setColor() as lines do. In Graphics 2.0, these methods should be more consistent, so you don’t need to think about which object type requires which fill function.

Best regards,

Brent

[rob]

There are multiple threads about this.  Using really thin rectangles is the answer and those threads have suggestions on how to make it work.

[russm305]

Please point me to a relevant thread.  I’ve tried using thin rectangles, it doesn’t work.  You will have spacing in between the rectangles when a line is drawn too fast and physics objects will fall through.  

I have been using lines a physics body function for a long time and the results are always consistent.  So all of a sudden Corona Engineers decided lines cannot be physics bodies!!!???   I am absolutely disappointed and blown away!!!

[bjsorrentino]

Hi @russm305,

I retract my former statement. You can still use lines as physics bodies, according to my tests in #1202:

[lua]

local line = display.newLine( 400,400,400,500 )

line:setColor( 255,0,0 )

line.width = 10

physics.addBody( line, “static” )

line.rotation = 40

[/lua]

This being said, the results are not ideal and I still encourage you to use rectangles instead. For example, this line (sample) gets the body drawn around it essentially correct, but it’s a bit wider than the visible line, whereas a rectangle would have a perfectly-traced outline. Beyond that, if you drew this line at an angle originally (not a 90-degree multiple), the physics body gets drawn incorrectly (like a square box that is positioned around the starting point of the line).

So, you can still use lines as physics bodies. I just recommend that you don’t.

Best regards,

Brent

[russm305]

Okay that is a relief to hear.  Why do you think my line drawing function now crashing the simulator in build 1202?

It says:  Terminal: line 9:  2966 Segmentation fault: 11  “$path/Corona Simulator.app/Contents/MacOS/Corona Simulator” $*

logout

[lua]

    function drawLine(e)

            if e.phase == “began” then

                prev_x = e.x

                prev_y = e.y

 

              elseif e.phase == “moved” then

                       lines[line_number] = display.newLine(prev_x, prev_y, e.x, e.y) 

                     lines[line_number]:setColor(0,191,255)

                    lines[line_number].width = line_width

                    group:insert(lines[line_number])

                    dist_x = e.x - prev_x

                    dist_y = e.y - prev_y

                        – Add a physics body that’s a flat polygon that follows each segment of the line

                    physics.addBody(lines[line_number], “static”, { density = 1, friction = 1, bounce = .1, shape = {0, 0, dist_x, dist_y, 0, 0} } )

                       prev_x = e.x

                    prev_y = e.y

                        line_number = line_number + 1

              elseif e.phase == “ended” then

              end

        

    end

    Runtime:addEventListener(“touch”, drawLine)

[/lua]

[Perry_Clarke]

It definitely shouldn’t crash.  Looking at the code you included above, I can see it references things that aren’t included in the fragment.  Can you boil down the code needed to reproduce the issue to the minimum and submit a bug?

Thanks!

[russm305]

Okay will do thank you very much!  Here is plug and play code that works perfect on older build at any angle.

local physics = require (“physics”)

physics.start(true)

–physics.setDrawMode(‘hybrid’)

local lines = {}

local line_number = 1

local line_width = 3.5

local prev_x, prev_y

    function drawLine(e)

            if e.phase == “began” then

                prev_x = e.x

                prev_y = e.y

              elseif e.phase == “moved” then

                       lines[line_number] = display.newLine(prev_x, prev_y, e.x, e.y) 

                     lines[line_number]:setColor(0,191,255)

                    lines[line_number].width = line_width

                   – group:insert(lines[line_number])

                    dist_x = e.x - prev_x

                    dist_y = e.y - prev_y

                        – Add a physics body that’s a flat polygon that follows each segment of the line

                    physics.addBody(lines[line_number], “static”, { density = 1, friction = 1, bounce = .1, shape = {0, 0, dist_x, dist_y, 0, 0} } )

                       prev_x = e.x

                    prev_y = e.y

                        line_number = line_number + 1

              elseif e.phase == “ended” then

              end

        

    end

Runtime:addEventListener(“touch”, drawLine) 

[Perry_Clarke]

When I run that code and draw a line I get the following in the console:

2013-10-23 10:30:14.334 Corona Simulator[7410:707] Runtime error /Users/perry/src/corona/apps/bug-physics/main.lua:65: From Box2D: edge.LengthSquared() \> 1.19209290e-7F \* 1.19209290e-7F stack traceback: [C]: ? [C]: in function 'addBody' /Users/perry/src/corona/apps/bug-physics/main.lua:65: in function 'func'

I think the error relates to having a physics body one of whose dimensions is too close to zero.

After some investigation I determined that this error isn’t displayed in Daily Builds because the Simulator crashes (it’s a difference between a debug and a release build).  We’re looking into the issue.

[russm305]

Thank you Perry for looking into this issue as this is the main feature of my games.  This is what my terminal says when I try to draw the line:

/Applications/CoronaSDK/Corona Terminal: line 9:   931 Segmentation fault: 11  “$path/Corona Simulator.app/Contents/MacOS/Corona Simulator” $*

logout

You can see the function in action on my latest game

https://itunes.apple.com/us/app/electro-puzzle-brain-arcade/id702376893?ls=1&mt=8

[bjsorrentino]

Hi @russm305,

While Perry investigates, I still encourage you to avoid using lines as physics bodies. This is even mentioned in the addBody() documentation under “Gotchas”: http://docs.coronalabs.com/api/library/physics/addBody.html

In either case, you may want to also code a method to prevent it from creating a new physics body on every “moved” state of the touch motion. You’re potentially creating hundreds of physics bodies in the code above, at each micro-increment of the sensory touch motion. This may result in a nice physical curve line, but performance will likely be impacted on some devices.

I once designed a similar line tracing sample using physics, and as the user dragged along the screen, I simply checked the distance between the previous point and the new point. If the distance was sufficient enough (something like 10-20 pixels) then, and only then, would it create a new physics body (rectangle, not line) and place it in the correct location. The result was a fairly nice, basically smooth “line” that other objects could interact with, using a fraction of the physics bodies that your code seems to be generating.

Anyway, just my two cents.

Take care,

Brent

[Perry_Clarke]

@russm305

Thank you Perry for looking into this issue as this is the main feature of my games.  This is what my terminal says when I try to draw the line:

/Applications/CoronaSDK/Corona Terminal: line 9:   931 Segmentation fault: 11  “$path/Corona Simulator.app/Contents/MacOS/Corona Simulator” $*

Just to be clear, the bug relates to the reporting of the error not to the error itself which is valid.  The message I showed above is the actual error being thrown by Box2D which was invisible until recently.  You should consider Brent’s advice and modify your code so it doesn’t throw errors.  When we fix the bug, you’ll be able to see the errors yourself.

[russm305]

The code i used was from the code exchange. I have no idea how it works. My coding skills are not sophisticated enough to modify it the way it is suggested by Brent. Would it be possible for someone from Corona to share this workaround code with me in the plug and play format similar to what i have done above? Thank you

[russm305]

Would someone from Corona please show me this modified code that will work in my projects.  Thank you.

[bjsorrentino]

Hi @russm305,

I can’t write the entire module for you at this time, but basically, you should consider using a distance calculation between the previous point and the new point, like this:

[lua]

local function distBetween( point1x, point1y, point2x, point2y )

    local xFactor = point2x-point1x ; local yFactor = point2y-point1y

    local dist = math.sqrt((xFactor*xFactor) + (yFactor*yFactor))

    return dist

end

local function angleBetween( point1x, point1y, point2x, point2y )

    local angle = ( math.deg( math.atan2( dstY-srcY, dstX-srcX ) )+90 )

    return angle%360

end

[/lua]

Then, in your “moved” phase, check the distance between the previous point and current touch point:

[lua]

local thisDistance = distBetween( prev_x, prev_y, e.x, e.y )

if ( thisDistance >= 10 ) then

   --place a newRect object (small square?) and add a physics body to it

end

[/lua]

The value of “10” above will need to be adjusted… maybe 20 is better, maybe 30, it all depends on the size of your content area and the size of the objects you’ll draw.

You should also use the “angleBetween” function I show to rotate the squares to the correct angle, so the line is smoother (otherwise the little boxes will all be facing 0 degrees straight up, which would result in a bumpy line if a curve is drawn).

Anyway, hope this gets you started. The concept is to just limit the number of objects you draw, while still creating a basically smooth “line” that other objects can roll along, bounce off, etc.

Brent