loading textures on 64bit VM

hello,
it seems my texture loader doesnt work anymore when run in a 64bit environment. im not sure if the cause is the 64bit VM itself or if the file lying on a 64bit filesystem.

the image to load is a RGBA png file.

here is my code:

					InputStream is = Thread.currentThread().getContextClassLoader().getResourceAsStream(path);
					BufferedImage bi = ImageIO.read(is);
					is.close();
					
					byte[] databytes = ((DataBufferByte) bi.getRaster().getDataBuffer()).getData();
					ByteBuffer data = ByteBuffer.allocateDirect(databytes.length);
					data.order(ByteOrder.nativeOrder());
					data.put(databytes, 0, databytes.length);
					data.rewind();

					IntBuffer texb = IntBuffer.allocate(1);

					binding.genTextures(1, texb);
					binding.bindTexture(binding.TEXTURE_2D(), texb.get(0));
					binding.texParameter(binding.TEXTURE_2D(), binding.TEXTURE_MIN_FILTER(), binding.LINEAR());
					binding.texParameter(binding.TEXTURE_2D(), binding.TEXTURE_MAG_FILTER(), binding.LINEAR());
					binding.texParameter(binding.TEXTURE_2D(), binding.TEXTURE_WRAP_S(), binding.CLAMP());
					binding.texParameter(binding.TEXTURE_2D(), binding.TEXTURE_WRAP_T(), binding.CLAMP());
					binding.texEnvi(binding.TEXTURE_ENV(), binding.TEXTURE_ENV_MODE(), binding.MODULATE());
					binding.texImage2D(binding.TEXTURE_2D(), 0, binding.RGBA(), bi.getWidth(), bi.getHeight(), 0, binding.RGBA(), binding.UNSIGNED_BYTE(), data);

does anyone know what could be wrong? thanks!

You didn’t say what was wrong!

BTW, I noticed that JDK6_018 broke my texture loader too, after nearly 7 years of it working just fine. It seems that they’ve broken BufferedImage.TYPE_INT_ARGB or whichever one it is, and swapped the order of all the bytes around. I should post a bug, but I can’t be arsed.

Cas :slight_smile:

thanks princec. you might be on the right track since it seems as if some byte channels are swapped.

for example here is a screenshot which is supposed to be yellow text with black outline

http://deviantsart.com/upload/ighd0l.png

i am also using jdk6_u18. i will try to revert and see if the problem persits.

Yes, that’s exactly the problem I had. I absolutely couldn’t figure out what it was until it dawned on my I’d updated Java to the latest JDK. I fixed it thusly:


	public static byte[] getRawImageBytes(BufferedImage bi) throws Exception {
		BufferedImage newBI;
		int type;
		switch (bi.getColorModel().getNumComponents()) {
			case 1:
				type = Image.LUMINANCE;
				newBI = bi;
				break;
			case 2:
				type = Image.LUMINANCE_ALPHA;
				newBI = bi;
				break;
			case 3:
				{
					type = Image.RGB;
					ComponentColorModel ccm = new ComponentColorModel(ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB), false, false, Transparency.OPAQUE, DataBuffer.TYPE_BYTE);
					newBI = new BufferedImage(ccm, ccm.createCompatibleWritableRaster(bi.getWidth(), bi.getHeight()), false, null);
					newBI.setData(bi.getRaster());
				}
				break;
			case 4:
				{
					type = Image.RGBA;
					ComponentColorModel ccm = new ComponentColorModel(ColorSpace.getInstance(ColorSpace.CS_LINEAR_RGB), true, false, Transparency.TRANSLUCENT, DataBuffer.TYPE_BYTE);
					newBI = new BufferedImage(ccm, ccm.createCompatibleWritableRaster(bi.getWidth(), bi.getHeight()), false, null);
					newBI.setData(bi.getRaster());
				}
				break;
			default:
				throw new Exception("Unsupported image type");
		}
		bi = newBI;
		return (byte[]) bi.getRaster().getDataElements(0, 0, bi.getWidth(), bi.getHeight(), null);
	}

(basically, any TYPE_INT_* images that get loaded are converted to a CompoentColorModel instead of a DirectColorModel, thus guaranteeing that they store their data in byte[] arrays in the right order).

Cas :slight_smile:

yeah princec you are right! thanks!
it was indeed the latest java version and not the 64bit VM.

thanks also for providing the source to fix this!