for some reason I cannot create images in any classes but my main one which extends applet.When I pass main into other classes to load images or something, there are no errors but the images dont show up. Does anyone have a solution to this? thanks

Oh, I found out i can use Toolkit.getDefaultToolkit().getImage to load the images in other classes. Thanks.

I now have a new problem when trying to convert from Image to bufferedImage to find the colour of the pixels for collision detection. I am trying to find which pixels have 0 alphaI am not sure if the buffered image contains anything as I can't draw it, but the image does that I'm trying to copy from.

Also, you shouldn't be using the Toolkit to read your images. Instead, use ImageIO.

1 2 3 4 5

BufferedImageimage = ImageIO.read(newFile("/Computer/folder/image.png"));//orBufferedImageimage2 = ImageIO.read(Thread.currentThread().getContextClassLoader().getResourceAsStream("/resources/image.png");//The first will look on your disk (or in a URL).//The second will look in the classpath (useful for JAR files).

Usually when you read a BufferedImage from a file it isn't INT_ARGB, so I typically will create a new BufferedImage with the correct type and then draw into that.

wow, thanks! I didn't really want to use the toolkit either, I just didn't see an alternative other than ImageIO, and when I used that, I don't know why but it made my speed stay at 3 fps even when they had finished loading. (Normally 70-80fps). Do you think this maybe because of some load error that kept popping up even after the image is created which slows down the program? (my program is a plain applet - not JApplet or swing or anything) and why would this happen? thanks.

wow, thanks! I didn't really want to use the toolkit either, I just didn't see an alternative other than ImageIO, and when I used that, I don't know why but it made my speed stay at 3 fps even when they had finished loading. (Normally 70-80fps). Do you think this maybe because of some load error that kept popping up even after the image is created which slows down the program? (my program is a plain applet - not JApplet or swing or anything) and why would this happen? thanks.

That slow-down could be a result of the version of Java you are using. Check you are upto-date 'java -version'.

wow, thanks! I didn't really want to use the toolkit either, I just didn't see an alternative other than ImageIO, and when I used that, I don't know why but it made my speed stay at 3 fps even when they had finished loading. (Normally 70-80fps). Do you think this maybe because of some load error that kept popping up even after the image is created which slows down the program? (my program is a plain applet - not JApplet or swing or anything) and why would this happen? thanks.

Yeah, Java2D kinda sucks when you want to squeeze anything out that isn't pretty simple. Bonbon is right that transparency really hurts it - most likely when you were using ImageIO the transparency actually started working, and then of course it took a lot longer. There can also be weird problems with Java2D keeping images cached even when you don't want it to anymore, so you can say myImage.flush() when you're done with it to try to alleviate that.

Good, thanks for that. I haven't ever used hex in Java before, actually. It's one of those things I stupidly avoided for a while. I've always hated dealing with Raster.getPixel() because of the weirdness of having to pass in another array.

So alpha is the first byte even though usually when setting it (like with the method I posted above) at occurs last? It makes sense that it is literally A then R then G then B, but it seems in most places the paradigm is to go RGBA instead.

Good, thanks for that. I haven't ever used hex in Java before, actually. It's one of those things I stupidly avoided for a while. I've always hated dealing with Raster.getPixel() because of the weirdness of having to pass in another array.

So alpha is the first byte even though usually when setting it (like with the method I posted above) at occurs last? It makes sense that it is literally A then R then G then B, but it seems in most places the paradigm is to go RGBA instead.

I'd never noticed it myself, but it appears the javadoc for much of the java.awt.Color class is misleading in that regard.In many places it refers to colors containing alpha as "RGBA", when it infact means "ARGB".In particular the javadoc (and name of the int parameter!) for this constructor have been badly chosen.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org