[SOLVED][1.7.2] Rendering icon in inventory turns completely grey

This is an icon with numbers rendered over the top of it, which renders perfectly fine until there is a damaged ItemStack preceding its position in the inventory, at which point it turns completely grey.

Never had this problem in 1.6.4, and after spending some time poking around in the updated rendering code and trying some things I'm no closer to a solution...

Here's my IItemRenderer:

@SideOnly(Side.CLIENT)
public class RenderItemBombBag implements IItemRenderer
{
/** Defines the zLevel of rendering of item on GUI. */
public float zLevel;

public RenderItemBombBag() {}

@Override
public boolean handleRenderType(ItemStack item, ItemRenderType type) {
	return type == ItemRenderType.INVENTORY;
}

@Override
public boolean shouldUseRenderHelper(ItemRenderType type, ItemStack item, ItemRendererHelper helper) {
	return false;
}

@Override
public void renderItem(ItemRenderType type, ItemStack item, Object... data) {
	if (type == ItemRenderType.INVENTORY) {
		Tessellator tessellator = Tessellator.instance;
		for (int i = 0; i < 3; ++i) {
			IIcon icon = item.getItem().getIcon(item, i);
			tessellator.startDrawingQuads();
			tessellator.addVertexWithUV(0, 16, zLevel, icon.getMinU(), icon.getMaxV());
			tessellator.addVertexWithUV(16, 16, zLevel, icon.getMaxU(), icon.getMaxV());
			tessellator.addVertexWithUV(16, 0, zLevel, icon.getMaxU(), icon.getMinV());
			tessellator.addVertexWithUV(0, 0, zLevel, icon.getMinU(), icon.getMinV());
			tessellator.draw();
		}
	}
}
}

It's really strange, the icons render perfectly fine if any of the preceding slots are highlighted with the mouse, whether or not a damaged stack is preceding, or if a non-damaged stack is preceding, but turns totally grey when a damaged stack is in a preceding slot with no slots or only empty slots in between and no highlighted slots.

I've tried manually setting the color and zLevel as well as some other probably useless things, to no avail. Is this perhaps a bug with 1.7.2 or Forge version 1024, or am I doing something stupid here?

Does it turn like full black? If so it maybe mc bug like the armor slot rendering black at times.

Sadly, no, it turns grey like the gui background, except one of the digits will still render.

I wasn't able to take a screenshot with the inventory screen open, but the effect is the same if I remove the stone block and highlight the slot instead, and if neither of the bags will render correctly if nothing intervenes between them and a damaged stack.

Hi

I reckon this is almost certainly a problem with OpenGL or the Tessellator settings carrying over from previous renders - but I'm not sure what.

Does the grey background still appear even if you do nothing in your render?  If not, perhaps your texture hasn't been bound properly.

You might try rendering a vanilla icon on the slot (by calling the vanilla code) and then rendering your icon over the top of the vanilla icon.  If that fixes it, then it shouldn't be too hard to track down the setting that's the problem.

Strange huh

-TGG

That's what I figure is going on as well; somehow the rendering of the damage bar over the ItemStack is screwing up the colors, but no matter what I try I can't seem to get it to normalize... Here's an interesting picture when I change it to just render the first icon:

Note how the background is brownish colored for the bags; that goes away if I highlight the bag slot or any slot intervening the bag and the damaged stack.

Very odd. Rendering multiple icons of course makes it turn grey like the previous screenshot. I've been looking through the inventory render code to see if they do anything prior to rendering each stack, such as enable/disable standard lighting, etc., but none of those have had any effect when I've tried them... the search continues

Hi

Man I hate this type of bug.

This class might perhaps be of some help

https://github.com/TheGreyGhost/SpeedyTools/blob/master/src/speedytools/clientonly/OpenGLdebugging.java

It's something I put together to help figure out which OpenGL settings vanilla has modified before calling my rendering code.  If you run it for the "good" vs "bad" renders you might be able to spot the difference.

dumpAllIsEnabled() currently works.  The rest isn't fully functional yet but I reckon you've got the skills to tweak it so it gives you useful information :-)

Was based on this very useful link

http://www.glprogramming.com/red/index.html

-TGG

Ooooh, that looks neat!!! I will have to give that a whirl and see what I can see, thanks!

Mwa ha ha ha!!! I finally tracked it down in RenderItem.renderItemOverlayIntoGUI(args...)

if (par3ItemStack.isItemDamaged())
            {
                int j1 = (int)Math.round(13.0D - (double)par3ItemStack.getItemDamageForDisplay() * 13.0D / (double)par3ItemStack.getMaxDamage());
                int k = (int)Math.round(255.0D - (double)par3ItemStack.getItemDamageForDisplay() * 255.0D / (double)par3ItemStack.getMaxDamage());
                GL11.glDisable(GL11.GL_LIGHTING);
                GL11.glDisable(GL11.GL_DEPTH_TEST);
                GL11.glDisable(GL11.GL_TEXTURE_2D);

// HERE: alpha and blend are disabled:
                GL11.glDisable(GL11.GL_ALPHA_TEST);
                GL11.glDisable(GL11.GL_BLEND);
                Tessellator tessellator = Tessellator.instance;
                int l = 255 - k << 16 | k << 8;
                int i1 = (255 - k) / 4 << 16 | 16128;
                this.renderQuad(tessellator, par4 + 2, par5 + 13, 13, 2, 0);
                this.renderQuad(tessellator, par4 + 2, par5 + 13, 12, 1, i1);
                this.renderQuad(tessellator, par4 + 2, par5 + 13, j1, 1, l);
                GL11.glEnable(GL11.GL_TEXTURE_2D);
                GL11.glEnable(GL11.GL_LIGHTING);
                GL11.glEnable(GL11.GL_DEPTH_TEST);
// HERE: they are not re-enabled
                GL11.glColor4f(1.0F, 1.0F, 1.0F, 1.0F);
            }

EDIT: disabling blend and alpha_test screws up the creative tab rendering; just enabling them is enough

Re-enabling them before I draw my icons (and then re-disabling them afterwards) brings everything back to normal

Seems like an oversight / bug on the part of Mojang there. I wonder if it will or has been fixed in versions after 1.7.2?

nice work!