Is it my code or java2D thats being slow?

Newbie & Debugging Questions
#1

I have a 2D platformer game which runs at set at 60 fps, i only update tiles that are one the screen around the player, so about 12x8 tiles which are 64x64 in size. It runs fine but when i animate the tile by giving them an image they grab from another class, every time the update they tick to see if its time to update their animation if so, they grab a different image but this makes the game lag, the water animation has 3 slides each one is just blue with some different noise.

I also draw the player pixel by pixel and depending on the tiles hes standing on change the RGBA of each pixel to make it cool, e.g. i add transparency when in water so it looks like it.
tl;dr it only really slows down when >60% of the screen are water tiles but i have no idea how else i would implement them :S

#2

I haven’t done Java2D in a long time, but last time I did I remember everything having translucency being dead slow, and anti-aliased/smooth slowing things down as well.

#3

I havent done any anti-aliasing so that cant be it, also when i disable the water affecting the player sprite so the player is just drawn normal over the water it is still slow :confused:

#4

it’s slow.
especially for tile maps and the sort, and

[quote]I also draw the player pixel by pixel
[/quote]
sounds bad too for java2d

#5

aghh thanks :confused: :frowning: this means im going to have to go lurk the Jogl forum now and buy a new book, gah. Thanks though ;D

#6

well try Slick2D which has a similar API to java2D, using openGL (lwjgl)
libGdx is also possible

#7

Yeaa i could, thinking of using doing my A level computing project using JOGL though. Because i could see an examiner who doesn’t know what hes talking about thinking “hes using a library! That means he practically didn’t do anything himself!”

#8

Just to be sure, when you cycle through water images you’re just updating a BufferedImage to point to another, pre-loaded BufferedImage, and not creating a new BufferedImage each time, right?

I couldn’t be 100% sure from reading your original post, but are your water tiles created by drawing a translucent water image on top of another image? If so then I agree with appel that this is likely your problem, since translucent images most likely won’t be accelerated. But if they’re fully opaque then your problem is likely elsewhere.

#9

Yea all the water tiles access 3 static images in a loader class that are loaded from the start and each cycle through pretty randomly, with the picture changing around every 300ms.

Water tiles are drawn first then player is drawn translucent ontop of the tile, as play is smaller i thought be better to do this way round(less pixels to shade).
So the tiles are drawn fully opaque, but the images that are drawn are basicly 64x64 of randomly bluey coloured pixels, i think this might be whats slowing it down

#10

Hmm, I was able to paint about 3000-4000 small translucent images ranging in size from 1x1 to 32x32 in under 20 msec per frame.

I would keep checking because from the numbers you give Java 2D shouldn’t be that slow.

I just noticed that you are changing the value of a single pixel. That definitely is a no-no as it causes an image to become un-managed. http://www.jhlabs.com/ip/managed_images.html

#11

That’s an EXCELLENT article that everyone should read.

The last point is also the most important. The BufferedImage returned by ImageIO MUST be turned into a compatible image or else it will not be drawn efficiently. Line 87 shows how to create a BufferedImage and line 107 shows how to copy a BufferedImage into a compatible BufferedImage.

#12

That’s true; for some reason I was thinking the OP was only manipulating pixels for a single tile (64x64), which shouldn’t be a problem. If you’re doing a larger image performance’ll drop rapidly.

FWIW, if you do want to edit individual pixels, and you’re doing it on an image small enough that you’re OK with it being unmanaged, be sure to do it the “right” way (i.e., most performant):