[Solved] [1.10.2] GuiContainer#drawRect drawing at wrong coordinates?

[IceMetalPunk]

I have a class that extends GuiContainer for a custom tile entity of mine. I'm drawing the UI, drawing the container name, etc. and all that works fine. However, I'm now trying to render the fluid in the tank of the tile entity, and the rectangle is being drawn completely wrong, in the wrong location, with the wrong width, and in the wrong color. I've even simplified it to ignore the amount of fluid and just draw a static rectangle, and it's still drawing in the wrong place.

 

I've done so much research and tried many things, but I can't figure this one out on my own.

 

Here's the current code I'm using:

 

	@Override
protected void drawGuiContainerForegroundLayer(int mouseX, int mouseY) {

	int left = 168, top = 30, right = 186, bottom = 90;
	FluidTank tank = (FluidTank) (((ICapabilityProvider) this.tileEntity).getCapability(CapabilityFluidHandler.FLUID_HANDLER_CAPABILITY, null));
	int color = 0xFFFFFFFF, amount = 0;
	if (tank.getFluid().getFluid() != null) {
		color = tank.getFluid().getFluid().getColor();
		amount = tank.getFluidAmount();
	}

	// Draw container title
	FontRenderer fontRender = Minecraft.getMinecraft().fontRendererObj;
	String title = new TextComponentTranslation("container.chaotic_condenser").getUnformattedText();
	fontRender.drawString(title, this.xSize / 2 - fontRender.getStringWidth(title) / 2, 5, 0, false);
	// Render fluid amount in text
	fontRender.drawString(amount + " mb", 5, 25, 0, false);

	/* FIXME: Implement proper fluid tank rendering. */
	this.drawRect(left, top, right, bottom, color);

}

 

Those coordinates are relative to the GUI's background image, taken directly from Photoshop measurements. The title draws perfectly fine, as does the text showing the amount of fluid (which is also how I know the tank is non-null and properly being read). But the bar...is too far to the right, too wide, and completely white (even though the fluid color is a yellow-ish).

 

Does drawRect use some weird transformations before drawing or something? I couldn't find anything, but the coordinates are clearly not correct...

[Animefan8888]

I have a class that extends GuiContainer for a custom tile entity of mine. I'm drawing the UI, drawing the container name, etc. and all that works fine. However, I'm now trying to render the fluid in the tank of the tile entity, and the rectangle is being drawn completely wrong, in the wrong location, with the wrong width, and in the wrong color. I've even simplified it to ignore the amount of fluid and just draw a static rectangle, and it's still drawing in the wrong place.

 

I've done so much research and tried many things, but I can't figure this one out on my own.

 

Here's the current code I'm using:

 

	@Override
protected void drawGuiContainerForegroundLayer(int mouseX, int mouseY) {

	int left = 168, top = 30, right = 186, bottom = 90;
	FluidTank tank = (FluidTank) (((ICapabilityProvider) this.tileEntity).getCapability(CapabilityFluidHandler.FLUID_HANDLER_CAPABILITY, null));
	int color = 0xFFFFFFFF, amount = 0;
	if (tank.getFluid().getFluid() != null) {
		color = tank.getFluid().getFluid().getColor();
		amount = tank.getFluidAmount();
	}

	// Draw container title
	FontRenderer fontRender = Minecraft.getMinecraft().fontRendererObj;
	String title = new TextComponentTranslation("container.chaotic_condenser").getUnformattedText();
	fontRender.drawString(title, this.xSize / 2 - fontRender.getStringWidth(title) / 2, 5, 0, false);
	// Render fluid amount in text
	fontRender.drawString(amount + " mb", 5, 25, 0, false);

	/* FIXME: Implement proper fluid tank rendering. */
	this.drawRect(left, top, right, bottom, color);

}

 

Those coordinates are relative to the GUI's background image, taken directly from Photoshop measurements. The title draws perfectly fine, as does the text showing the amount of fluid (which is also how I know the tank is non-null and properly being read). But the bar...is too far to the right, too wide, and completely white (even though the fluid color is a yellow-ish).

 

Does drawRect use some weird transformations before drawing or something? I couldn't find anything, but the coordinates are clearly not correct...

Show an image of what it should look like and one with what it does look like.

[IceMetalPunk]

This is what it looks like now:

 

 

The white bar on the right side of the UI is supposed to fit inside the recessed rectangle in the center of the UI. (It's also not supposed to be white, since I have this in my fluid's constructor:

this.setColor(245, 255, 163, 255)

).

[hugo_the_dwarf]

try

 

this.drawRect((this.sizex / 2) - (18/2), top, (this.sizex / 2) + (18/2), top + 60, color);

 

I had to subtract left from right to get 18, and top from bottom for 60. For small objects like bars and that make sure you store their dims (height width)

[IceMetalPunk]

try

 

this.drawRect((this.sizex / 2) - (18/2), top, (this.sizex / 2) + (18/2), top + 60, color);

 

I had to subtract left from right to get 18, and top from bottom for 60. For small objects like bars and that make sure you store their dims (height width)

 

Doing that gave me this result:

 

 

It's still about twice as wide and tall as the pixel values suggest it should be, too low down, and the wrong color. More importantly, other UI's won't have the fluid tank in the center, so I need to know how to make this work with coordinates that aren't calculated from the dimensions of the UI as well.

 

*EDIT* Well, there you go. I started to wonder if it wasn't just "about" double the size, but if the coordinates were *exactly* double. So I divided all my coordinates by 2, and...the position and size are now perfect! Can anyone explain why I had to divide the pixel values by 2?

 

So now the only big problem is that the color is still white even though the fluid's getColor should be returning a yellow color--can anyone help m figure that one out?

 

*EDIT 2* I also forgot setColor isn't a method of Fluid, but of my extension of Fluid, so here's that class so you can see how I'm setting and getting the color:

 

package com.icemetalpunk.chaotica.fluids;

import net.minecraft.util.ResourceLocation;
import net.minecraftforge.fluids.Fluid;
import net.minecraftforge.fluids.FluidRegistry;

public class FluidChaosBase extends Fluid {

protected byte[] color = new byte[] { (byte) 255, (byte) 255, (byte) 255, (byte) 255 };

public FluidChaosBase(String fluidName, ResourceLocation still, ResourceLocation flowing) {
	super(fluidName, still, flowing);
	this.setUnlocalizedName(fluidName).setGaseous(false);
	FluidRegistry.registerFluid(this);
}

@Override
public int getColor() {
	return this.color[0] << 24 | this.color[1] << 16 | this.color[2] << 8 | this.color[3];
}

public void setColor(byte r, byte g, byte b, byte a) {
	this.color[0] = r;
	this.color[1] = g;
	this.color[2] = b;
	this.color[3] = a;
}

public void setColor(int r, int g, int b, int a) {
	this.color[0] = (byte) r;
	this.color[1] = (byte) g;
	this.color[2] = (byte) b;
	this.color[3] = (byte) a;
}

}

 

Have I done something wrong here, or is the problem elsewhere?

[hugo_the_dwarf]

Some how I feel like there is something scaling up everything by 2

 

GL11.glScalef(x, y, z);

 

Also regarding the fluid bar not being in the center each time, you should be able to use

 

this.guiLeft and this.guiTop to get obviously the starting point of the left and top of when the GUI is drawn. Which is normally the ScaledResolution.getScaledWidth() / 2 - sizex / 2

 

it's better to add and subtract locations from guiLeft and guiTop for relative locations. If you have a hard point sometimes resizing the screen or changing the GUI Scale in the MC options > video settings can throw it off.

 

 

For some of my HUD stuff in my mod I use

 

ScaledResolution res = event.getResolution();

int bottomScreen = res.getScaledHeight(), halfHeight = bottomScreen / 2;

int rightScreen = res.getScaledWidth(), halfWidth = rightScreen / 2;

 

as I don't have a gui to get the left and top from. just the raw screen

 

EDIT:

as for the color, try hard setting it 0xFF0000 < Red if it's still white there could be a location where a GL11.glColor4f() is being used. I found that drawing colored text would change it, forcing me to reset my GL color back to a solid white before drawing anymore textures.

[IceMetalPunk]

I've narrowed down the color problem. I realized my getColor() method was returning -1, so after a lot of breakpoint/stepping debugging, I've determined that my setColor() method is storing negative values in the local color array instead of the positive ones passed in. Is it unsafe in Java to cast an int directly to a byte? (If so, I'm assuming that would be because all ints are signed while, I take it, bytes are unsigned?) If so, what's the accepted way to make that conversion, since Java seems to assume all constant numerical values are ints without a cast? (I'm about to try Byte.valueOf() to see if that helps the implicit cast go more smoothly, but meanwhile, if there's a better way, someone please let me know.)

 

And if it's not obvious, I'm relatively new to Java programming, having spent most of my time with PHP, GML, JavaScript, and C++, so sometimes these little quirks of Java catch me.

 

*EDIT* Okay, turns out you can't pass an int to Byte.valueOf(). More importantly, I did a bit of reading, and apparently it's not possible to have an unsigned byte--or any unsigned values--in Java? That's...annoying. So I'm about to (grudgingly) change the array over to shorts to give enough bits to hold the full 0-255 range...hopefully that will work.

 

Is the article I read wrong, or is there really no way to have an unsigned byte in Java?

[IceMetalPunk]

There are no unsigned types in Java, except maybe char, which doesn't really count.

Guava has some handy methods in it's UnsignedBytes resp. UnsignedInts classes though.

Darn. Just when I was starting to really like Java, I learn about its downfalls Oh, well, using shorts has fixed the problem and everything works as it should now, even if it takes 16 bits just to get past 127 >_<

 

Thank you everyone for your help!