11.0 bugs

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

Re: 11.0 bugs

Post by slime » Sat Apr 07, 2018 1:52 am

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

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

Re: 11.0 bugs

Post by drunken_munki » Sat Apr 07, 2018 2:16 am

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.

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

Re: 11.0 bugs

Post by Ref » Mon Apr 09, 2018 3:03 pm

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
(1.44 KiB) Downloaded 176 times

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

Re: 11.0 bugs

Post by Nixola » Mon Apr 09, 2018 4:34 pm

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
lt = love.thread
li = love.image
lg = love.graphics

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

Re: 11.0 bugs

Post by zorg » Mon Apr 09, 2018 5:09 pm

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 :3True 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.

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

Re: 11.0 bugs

Post by pgimeno » Mon Apr 09, 2018 5:23 pm

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

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

Re: 11.0 bugs

Post by Ref » Mon Apr 09, 2018 5:59 pm

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.

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

Re: 11.0 bugs

Post by pgimeno » 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.

User avatar
slime
Solid Snayke
Posts: 2854
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: 11.0 bugs

Post by slime » Mon Apr 09, 2018 11:06 pm

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.

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

Re: 11.0 bugs

Post by pgimeno » Mon Apr 09, 2018 11:18 pm

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests