Line:Append Broken :(

Solar2D Advanced Graphics
#21

ditto - working as it should in 2085 for me.

Thanks

#22

I’m experiencing the same thing as well. Also: are image stroke and fills supposed to work with lines as they do with circles, rectangles, and polygons?

#23

I’ve just used line:append without problem in my JSON importer - note this is version 2013.2018.

I add a ton of points to a line with the following code:

[lua]line:append( unpack( points ) )[/lua]

I have not worked with anything except lines and polygons, but I did note that in the case of the line, the line itself IS the stroke, so to make a fatter line or to colour it you use .strokeWidth and :setStrokeColor() which stumped me for a bit when I first tried using other properties and the :setFillColor() function instead.

#24

+1 on this.  My code which implements finger drawing (basically line:append as the touch move events are fired) behaves like ninjapig describes.   Colors are constantly changing, and include gradients.  It also appears to behave like a polygon – Corona is rendering a line segment between the first and last point on the line.  I believe the mitigating factor is that we’re calling line:append across frames.

#25

Wanted to let you know that I got an email from the Corona Bugs team and they apparently fixed it in the most recent daily build. I haven’t gotten to test it for myself yet.

#26

It doesn’t appear to be fixed in 2076, which is today’s public g2.0 release.

#27

I also just ran into this… and of course in the project you’re following a line around. :confused:

The “real time” part seems to be key. Some tests seem to show that lines work okay if you make them, do all your appends, and never touch them again (which should account for rakoonic’s case). But if the append() calls are distributed across frames, something goes awry.

I’m seeing the polygon-ish thing scott0 mentions too, but I wonder if it isn’t just undefined behavior. I almost suspect the VBO for the line mesh is being generated on demand before the render call, but only the first time, and then is missing a check to see if it grew on the next frame… and then glBufferSubData() happily stomps on unallocated memory.

On that note, is anybody else running out of memory or seeing it lock up?

(As a workaround I’ll probably just hold onto the most recent vertices and rebuild the line each frame, maybe baking it every now and then so the list doesn’t grow huge.)

#28

I submitted a bug report for this, and included the code below which demonstrates the problem.

[lua]
local myline = display.newLine(160,240,170,250)

myline.strokeWidth=5

myline:setStrokeColor(1,1,1)

local function append1()

    myline:append(190,250)

end

local function append2()

    myline:append(190,300)

end

timer.performWithDelay(1000,append1)

timer.performWithDelay(2000,append2)
[/lua]

#29

I’m trying to convert a project to G2.0 and I’m now seeing the line:append causing a rainbow of colors effect.  Any news on a fix for this?  

#30

After more testing of my particular usage, I see the rainbow color bug simply by changing a line’s width using a transition.  Here’s a simple test case demoing the problem.  Run it on G2.0/daily2076 to see the rainbow:

local testline = display.newLine(50,50, 300,400) testline.width = 50 transition.to(testline, {time = 5000, width = 1})   --This causes rainbow G2.0 bug  

  I filed a new bug, case 28115, since this version has nothing to do with line:append

#31

 I see the rainbow color bug simply by changing a line’s width using a transition. 

That might just be because of the “width” field, which has since become “strokeWidth”. Otherwise, it seems to invalidate my earlier theory.  :slight_smile:

As for the workaround I mentioned, it did seem to work in my own case, though it’s pretty craptacular, only handles one line, and I’m sure it would be a hassle if you need to maintain “old” parts of the line that have broken off.

local LINE, POINTS, N local function Append (group, x, y) if N \< 50 then display.remove(LINE) POINTS[N+1], POINTS[N+2] = x, y N = N + 2 else POINTS[1], POINTS[2], POINTS[3], POINTS[4] = POINTS[49], POINTS[50], x, y N=4 end LINE = display.newLine(group, POINTS[1], POINTS[2], POINTS[3], POINTS[4]) if N \> 4 then LINE:append(unpack(POINTS, 5, N)) end LINE:setStrokeColor(1, 0, 0) LINE.strokeWidth = 4 end -- Somewhere below, level setup: POINTS, N, LINE = {}, 0
#32

@StarCrunch,  I tested with  width and strokeWidth and both “work” in the sense that they both change the width of the line and have the rainbow defect.  

Since we’re all finding multiple ways to see the rainbow it must be a deeper issue with line rendering. I’m concerned that this has been known about for at least a month and made it into the public release without a peep of acknowledgement from the Corona folks.  

-Stephen

#33

Here’s an ironic throwback… Almost 18 months to the day…

http://www.coronalabs.com/blog/2012/05/15/corona-engineering-next-release-and-more/

Read midway in reader comments and you will see @Ninja Pig Studios talking about the same issue… 

#34

The funny thing is ksan is they fixed it, then with graphics 2.0 it broke again.  Now that I addressed the issue it works fine :smiley: funny how the same bugs can happen again with a new engine in place :smiley:

#35

Thanks all for the info, we’re looking into this.

#36

Seems to be fixed for me in daily build 2082.  Thanks, Walter et al.

#37

ditto - working as it should in 2085 for me.

Thanks