11.0 bugs

[slime]

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]

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]

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)?

[Nixola]

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.

[zorg]

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.

[pgimeno]

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]

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]

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]

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]

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.