Using LWJGL color API?

Could anyone break down how to use the Color API of LWJGL to me? From my testing, all of these colors are apparently the same:


// Color c = new Color(r, g, b, a);

Color c = new Color(255, 155, 0, 255);
Color c = new Color(155, 255, 0, 255);
Color c = new Color(100, 200, 0, 255);

I searched on google for about an hour and didn’t come up with anything substantial. Although I am aware of bitshifting. Do I need to shift


// Vertices, the order is not important. XYZW instead of XYZ
float[] vertices = {
		-0.5f, 0.5f, 0f, 1f,
		-0.5f, -0.5f, 0f, 1f,
		0.5f, -0.5f, 0f, 1f,
		0.5f, 0.5f, 0f, 1f
};
FloatBuffer verticesBuffer = BufferUtils.createFloatBuffer(vertices.length);
verticesBuffer.put(vertices);
verticesBuffer.flip();

float[] colors = {
		1f, 0f, 0f, 1f,
		0f, 1f, 0f, 1f,
		0f, 0f, 1f, 1f,
		1f, 1f, 1f, 1f,
};
FloatBuffer colorsBuffer = BufferUtils.createFloatBuffer(colors.length);
colorsBuffer.put(colors);
colorsBuffer.flip();

First of all LWJGL does not know about the Color object, so you cant use these.
Secondly, OpenGL(LWJGL) works with floats as color, with values ranging from 0 to 1.

A wise bunny would use unsigned bytes for colours with OpenGL.

Cas :slight_smile:

Color color = new Color(255, 255, 255, 255);
byte red = (byte)(color.getRed()-128);
byte green = (byte)(color.getGreen()-128);
byte blue = (byte)(color.getBlue()-128);
byte alpha = (byte)(color.getAlpha()-128);
GL11.glColor4b(red, green, blue, alpha);

I was thinking more like glColor4ub(color.getRedByte(), color.getGreenByte(), color.getBlueByte(), color.getAlphaByte());

(Assuming this is the LWJGL Color class)

Cas :slight_smile:

Or pack RGBA into a float and interleave it with the rest of your vertex data. :slight_smile: (a la LibGDX’s 2D SpriteBatch)

Indeed, the bytes thing is a good idea. Could anyone give me a small example of how to convert bytes to a color, though? It’d be very, very helpful indeed.

Divide each component by 255f (need the f or you’ll get integer division)

I think he meant packing RGBA bytes into a FloatBuffer.

	public static float packRGBA(int r, int g, int b, int a) {
		return Float.intBitsToFloat((r << 0) | (g << 8) | (b << 16) | (a << 24));
	}

Usage:


FloatBuffer fb = ...;
fb.put(x);
fb.put(y);
fb.put(z);
fb.put(packRGBA(r,g,b,a));

So would I only need 1 color “vertex” when interleaving color with position in my FloatBuffer? From what it looks like, that seems to be the case.

Adding this snippet of code to ask: Am I going about this the correct way? I need 4 floats (one representing each of r, g, b, a) and they’re supposed to be values between 0 and 1. I’m trying to convert from a hexadecimal integer (eg 0xFFFFFFFF) to the four floats.


	protected float[] getRGBA(int color) {
		return new float[] {
				(color & 0xFF) / 255f,
				(color >> 8 & 0xFF) / 255f,
				(color >> 16 & 0xFF) / 255f,
				(color >> 24 & 0xFF) / 255f
		};
	}

Am I thinking about this the right way?

Why not use [icode]glColor4f()[/icode] instead of [icode]glColor4b()[/icode]? Is there any benefit of it? I’m using Java2D’s [icode]Color[/icode] object in LWJGL like this.


Color c = Color.PURPLE;

int red    = c.getRed();
int blue   = c.getBlue();
int green  = c.getGreen();
int alpha  = c.getAlpha();

glColor4f(red, blue, green, alpha);

And it works for me. Is there any wrong in it?

Yes.
glColor4f expects Floats, not ints.

You can give it ints, since it’ll convert them to floats implicitly, but the problem is, that the expected floats should be in range 0 to 1, but if you give it int’s they can only be either 0 or 1, nothing in between.

I don’t really know what [icode]c.getRed();[/icode], etc. return, but assuming they return the color component in range 0 to 255, you’d need to divide by [icode]255f[/icode], as sproingie said:


Color c = Color.PURPLE;

float red    = c.getRed() / 255f;
float blue   = c.getBlue() / 255f;
float green  = c.getGreen() / 255f;
float alpha  = c.getAlpha() / 255f;

glColor4f(red, blue, green, alpha);

Hey, I found that there is [icode]glColor4i[/icode] function which directly takes integers ranging from [icode]0…255[/icode] saving us from dividing each time. Also, Java2D’s Color object gives the components in that range only as ints. This is certainly not a big performance optimization but certainly helps me since I’m somewhat poor in maths.

glColor4i takes ints in the entire range of integers, not just 0…255. It’s practically useless.

Cas :slight_smile:

@princec

Thanks for pointing out. Now I made two functions [icode]setColor()[/icode] and [icode]getColor()[/icode] as sproingie said.


private Color color = Color.BLACK;

public void setColor(Color c)
{
    color = c;
    glColor4f(
        (float) (color.getRed() / 255f),
        (float) (color.getBlue() / 255f),
        (float) (color.getGreen() / 255f),
        (float) (color.getAlpha() / 255f)
    );
}

public Color getColor()
{
    return color;
}

… though why you’d be using immediate mode OpenGL for anything serious is a question.

Cas :slight_smile:

He can always use much, much faster and still almost as easy to use as immediate mode display lists. :wink:

Yeah, but it’s all deprecated tech that’s going nowhere… far better to get the hang of vertex arrays and VBOs, because that’s what all the drivers are headed towards.

Cas :slight_smile: