Yeah I send it to sleep when the window is not focused, so it would not use 100% of the CPU.I am using Java2D and I use translucent images. I load each image, create a translucent counterpart and make all the pink pixels transparent.

Here's some of the stuff I do, if anyone notices what I should change just let me know.

I'm drawing out a map, so far only the walls and corridors. On top of the map I draw a cursor. I've just checked, and if I comment out the line which draws the map, the FPS goes up to 370. So obviously it is the map images that cause the problem...

If I get the image with createCompatibleVolatileImage() then the FPS goes up to 70-90, but then it isn't transparent. Even if I save a GIF image with a transparent background, it will make the background white.

I also tried resizing the images to 32x32 but the FPS remained the same...

I also tried using the -Dsun.java2d.ddforcevram=true arguement, but it didn't do a thing...

OK now I've tried loading the image not as a BufferedImage but as a simple Image:

Image img = Toolkit.getDefaultToolkit().getImage(path);

Interesting that this way I get 70 FPS. Still, this way I have to make the images transparent in a drawing program, and can't do it myself inside the application... but if I can't find any other way then this will be good as well...

Dude, use edit on your post to add new comments... this is ugly and unreadable what you do.

In windows under DirectX (default) alpha images aren't accelarated. Try to use OpenGL pipeline and see how it works, search forums to see how to enable it, it's a command at startup or a line of code of system proparty. Buffered images try their best to be accelerated, I think you should use them. If you load the image and then work anything on it, it loses accelerration. When you're done with your work, create a new BufferedImage with that data.

I create a compatible BufferedImage, pass through its data array and turn all the pink pixels into transparent. Then finally I create a new compatible image, and paint the modified BufferedImage on it.Looks like the problem all along was that I modified the compatible image's data array, so it stopped being accelerated.

Extremely minor nit-pick, but you're leaking a little bit of time once every secondIf you change "oneSecond = now;" into "oneSecond += 1000;", you stop the leaking. It probably won't affect the reported fps, though.

As far as I know, currentTimeMillis() is inaccurate, at least with windows. Try nanoTime() instead and remember to divide by 1.000.000 to convert nano to milli.

I cant exactly tell what you do with your transpant image, but there might be better ways. CreateCompatibleImage has the transparency options opaque, bitmask and translucent. If you just want masked images (pixel is visible or not, but no alpha), use bitmask transparency.You can read transparent GIFs (use bitmask transparency) and PNGs (support full alpha information) and draw them on a BufferedImage. So you dont need all this per pixel computation.

As far as I know, currentTimeMillis() is inaccurate, at least with windows. Try nanoTime() instead and remember to divide by 1.000.000 to convert nano to milli.

You can actually use Thread.sleep(long milis, int nanos), which means you can do this; Thread.sleep(nanoTime/1000000,(int)nanoTime%1000000); also note that the sleep is also inaccurate in itself, there is a couple ms delay in the call and the shorter you get it to sleep the more it will be inaccurate. You basicly have to compensate that aswell if you really wanna get accurate;

This is an example of a piece of code out of the book "Killer Game Programming in Java" which covers for it;

If the sleep( ) call sleeps for 12 ms instead of the desired 10 ms, then overSleepTime will be assigned 2 ms. On the next iteration of the loop, this value will be deducted from the sleep time, reducing it by 2 ms. In this way, sleep inaccuracies are corrected.

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