Closed taelnia closed 10 years ago
This should guarantee a nonnegative number of pixels, but I am not sure it is correct. Wouldn't the iconX and/or iconY also need to be changed in the event of a flipped icon?
I don't believe so. As I understand it, the iconX and iconY arguments should never be negative. They are the offset location on the texture sheet. In minecraft, Icon is an interface, so the getMinU() and getMinV() should return the correct location on the texture sheet regardless of which implementation of Icon is used.
The only reason the pixels array was being created negative was because the icon width or height calculation was not accounting for a flipped texture. This PR will allow for the correct width/height calculation, and the iconX,iconY will give the offset. When the getRGB() method is called it uses that offset and the width/height to copy the color of each pixel from the texture sheet into the pixels array. That array is then averaged to produce a final color value for the block, which is returned.
I would suggest to replace
float diffU;
if (minU > maxU) {
diffU = minU - maxU;
} else {
diffU = maxU - minU;
}
by a simple
float diffU = Math.abs(minU - maxU);
It means exactly the same thing but is much simpler to read.
I'm also not entirely certain this needs to be fixed in mapwriter. I think the only usage I can find of flipped icons in the vanilla MCP source is in BlockDoor
, and they appear to use the convention of using the non-flipped texture for getIcon
and the textureMap
. It just uses the flipped icons when rendering the textures on the actual blocks.
I know this is just a "convention" of one example, but it is all we have to work with.
I would agree that this is a problem related to the mod not using standard icons, but until it is fixed at the source (Extra utilities in that case), MapWriter can't keep on crashing because of cross mod interactions.
That's the burden of mods relying on other mods to provide correctly formated data. It is not an ideal situation, but since all conventions in the MCverse are more or less only verbal conventions, that's the only way to do it.
The reason I say iconX and iconY need to be changed is they get the offset to the wrong corner of the texture when it is a flipped icon. In the example of the gravel_road_corners icon that is causing the problem, it was flipped vertically, and because of this iconX and iconY point to the lower left corner of the texture, and not the upper left like the rest of the code expects.
While it would be nice if every icon returned were consistent, it would be near impossible to have every mod author follow the same standard.
I simplified the code and also adjusted the IconX/Y to use the lower of the two values. This should let it work for any Icon passed in.
... all this discussion for just a color, heh.
This is dedication. It is was me, I would have just try/catch the method and call it a day ;) Patch has been applied to the Opis version of MW, so you shouldn't get any complain from that either.
Thanks for the code taelnia! You fixed the problem before I even realized there was one :)
I'll merge it in and hopefully make a release in the next few days (including ProfMobius's overlay API work as well).
Just need to finish the underground map and it should be good to go.
The recent release of ExtraUtils has brought to light a bug with Flipped Icons where the pixels array would attempt to be created with a negative value.