## 11.0 bugs

General discussion about LÖVE, Lua, game development, puns, and unicorns.
slime
Solid Snayke
Posts: 2854
Joined: Mon Aug 23, 2010 6:45 am
Contact:

### Re: 11.0 bugs

drunken_munki wrote:
Sat Apr 07, 2018 1:46 am
During a map load the Sb is told to load up about 19k draws, which I then render into a canvas that is used as the floor of the game space.

In 11.0 I can load two maps and then the SB renders out only black.
This canvas issue seems the likely cause: viewtopic.php?f=3&t=85051&start=20#p219603

drunken_munki
Party member
Posts: 134
Joined: Tue Mar 29, 2011 11:05 pm

### Re: 11.0 bugs

slime wrote:
Sat Apr 07, 2018 1:52 am
This canvas issue seems the likely cause: viewtopic.php?f=3&t=85051&start=20#p219603
Ah could be, I'll check it out thank you.

EDIT:

I've found my way to the new build and can confirm everything works with the fix, cheers slime.

Ref
Party member
Posts: 682
Joined: Wed May 02, 2012 11:05 pm

### Re: 11.0 bugs

Doubt that this is a bug in Love 11 but would like an explanation as to what is going on.

The attached script (used to floodfill concave polygons and polygons with holes) was converted from Love 10 (where it worked without any problems) to Love 11 by changing all colors from 0-255 to 0-1.

Discovered that script would fail ( goes into an endless loop) if the following colors were used: .1, .3, .5, .7, and .9

Also discovered that any color assigned using an integer from 0-255 divided by 255 works.

The test that seems to fail is the following:

Code: Select all

function colorMatch( c1, c2 )
return c1[1]==c2[1] and c1[2]==c2[2] and c1[3]==c2[3]
end

where color 1 is the assigned color and color 2 is the color returned from
imagedata:getPixel(x,y)

Seems the setColor and getPixel have a slightly different number representation.
Anyone have any idea what's going on –(probably something obvious)?
Attachments
floodfill.love
Inefficient floodfill

Nixola
Inner party member
Posts: 1940
Joined: Tue Dec 06, 2011 7:11 pm
Location: Italy

### Re: 11.0 bugs

You should probably not rely on == to compare floats from different sources. The correct way to compare them depends on their representation, which means it depends on the image format. In case of a normal 8bpc canvas/imagedata/whatever the only actual possible values will be [0-255]/255, which means .1, .3, .5, .7 and .9 aren't actual possible values.
lf = love.filesystem
ls = love.sound
la = love.audio
lp = love.physics
li = love.image
lg = love.graphics

zorg
Party member
Posts: 2734
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

### Re: 11.0 bugs

In short, even if you pass in .1, .3, .5, .7 or .9 just because setColor and the [0,1] range allows it, it will be converted to the nearest math.floor(x*255)/255, upon asking for them via getColor. (for 8 bits per color, that is)

Maybe it would be nice if there was a "RawColor" getter/setter pair, that would return values as how it's stored internally, integrally after all... whether the range be [0,255] or [0,65535] or whatever, for easier comparison, among other things.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

pgimeno
Party member
Posts: 1909
Joined: Sun Oct 18, 2015 2:58 pm
Location: Valencia, ES

### Re: 11.0 bugs

This should work for components with a max value of 255:

Code: Select all

function colorMatch( c1, c2 )
return math.abs(c1[1] - c2[1]) < 0.001
and math.abs(c1[2] - c2[2]) < 0.001
and math.abs(c1[3] - c2[3]) < 0.001
end


Ref
Party member
Posts: 682
Joined: Wed May 02, 2012 11:05 pm

### Re: 11.0 bugs

Thanks pgimeno for the idea.
This mess works!

Code: Select all

function colorMatch( c1, c2 )
return math.floor(255*c1[1]) == math.floor(255*c2[1]) and
math.floor(255*c1[2]) == math.floor(255*c2[2]) and
math.floor(255*c1[3]) == math.floor(255*c2[3])
end

Always something unexpected.
Couldn't be a simple change from 0-255 to 0-1.

pgimeno
Party member
Posts: 1909
Joined: Sun Oct 18, 2015 2:58 pm
Location: Valencia, ES

### Re: 11.0 bugs

The deprecated love.filesystem.isFile does not work the same in 0.10 and 11.0. In 0.10, if the filename corresponds to a symlink that points to a file, it returns true. In 11.0, it returns false.

Furthermore. love.filesystem.getInfo doesn't provide the functionality to check whether a filename corresponds to a file (after following symbolic links).

Similarly for isDirectory.

slime
Solid Snayke
Posts: 2854
Joined: Mon Aug 23, 2010 6:45 am
Contact:

### Re: 11.0 bugs

pgimeno wrote:
Mon Apr 09, 2018 8:49 pm
The deprecated love.filesystem.isFile does not work the same in 0.10 and 11.0. In 0.10, if the filename corresponds to a symlink that points to a file, it returns true. In 11.0, it returns false.

Furthermore. love.filesystem.getInfo doesn't provide the functionality to check whether a filename corresponds to a file (after following symbolic links).

Similarly for isDirectory.
The old 01.0 behaviour was actually a bug in PhysFS. The new behaviour is like that because we updated to PhysFS 3.0 (it would still be like this even if we didn't deprecate isFile).

Also (for what it's worth), love used PhysFS 2.1/3.0 on Android and iOS in 0.10, so the behaviour was inconsistent across platforms until now.

pgimeno
Party member
Posts: 1909
Joined: Sun Oct 18, 2015 2:58 pm
Location: Valencia, ES

### Re: 11.0 bugs

slime wrote:
Mon Apr 09, 2018 11:06 pm
The old 01.0 behaviour was actually a bug in PhysFS. The new behaviour is like that because we updated to PhysFS 3.0 (it would still be like this even if we didn't deprecate isFile).
Thanks for the clarification. If PhysFS provides a method to check the destination of a symlink, I'd appreciate if a future version exposes it.

### Who is online

Users browsing this forum: No registered users and 7 guests