Problem with image drawing and FPS

[matheus23]

@Ultroman

@matheus23

same as Ultroman, but you won’t need to “load” the BufferedImage from the HashMap everytime you want to draw it, which is bad (or slow), because it needs to “search” through the map with an algorithm. The more Images you have, the longer it will take to get it from the HashMap.
Just take a reference to the Image, which is then actually stored in another class and only loaded once.

What is the difference from your method to mine, except for the dedicated class? My suggestion was essentially the same: “have a HashMap of BufferedImages with a String as key”. I’ve done somewhat what you said for my game, and put my static HashMap of images in a ResourceHolder class, so I can access it from every class that has a reference to the ResourceHolder, like my Creator-class and my draw-method in the Game-class.

Do you mean you give the Tile-class a BufferedImage as a parameter in the constructor from the Tile-class? So you’re linking the image to the Tile-class instead of looking it up every update?

Just to clarify; this could come off as a whiney post, but I’d just love to know how much I can gain from changing to your proposed method compared to mine. I was under the impression HashMap lookups were pretty instantaneous.

Hmmm…
Yes. The only difference between your method and mine is the constructor stuff, and removing the lookup from the render method.

And I don’t know how long a lookup in HashMap takes. I’m really not sure, but I’m sure a field “lookup” is much faster. And since rendering methods are called very very often, I thought that could be a huge difference… But I’m just checking how long a HashMap lookup would take… (I am also pretty sure that HashMap lookup time is dependent on the number of entrys. So it would take much longer if you’d have tons of sprites… and that’d be bad…).

Could be possible that would fall into the “premature optimization” bag…

[Ultroman]

@matheus23

Hmmm…
Yes. The only difference between your method and mine is the constructor stuff, and removing the lookup from the render method.

And I don’t know how long a lookup in HashMap takes. I’m really not sure, but I’m sure a field “lookup” is much faster. And since rendering methods are called very very often, I thought that could be a huge difference… But I’m just checking how long a HashMap lookup would take… (I am also pretty sure that HashMap lookup time is dependent on the number of entrys. So it would take much longer if you’d have tons of sprites… and that’d be bad…).

Could be possible that would fall into the “premature optimization” bag…

The more I think about it, the more I know you’re right
I’d hate to find out now that my teachers are full of it, and that HashMaps aren’t instantaneous.

[Ultroman]

@Ultroman

I’d hate to find out now that my teachers are full of it, and that HashMaps aren’t instantaneous.

Well, seems they’re halfway right…or something. This is a very interesting read on performance of lists, sets and maps.

[jonjava]

I know this problem very well. You should not draw all the tiles simultaneously, only the ones that are visible. This way you can easily get around 1k visible tiles without much fps drop with simple java2d. At least I don’t get any FPS drop while filling the screen with pink 1px height tiles on my netbook in this applet: http://jonjavaweb.orgfree.com/TestApplet.html (press W to insert pink tiles).

If you minimize the window where the applet is and maximize it again you get a glimpse of how and how fast the tiles are drawn on the screen. There should be around 50+ tiles per platform that are fit inside the screen + a few more extra to make sure you don’t get undrawn tiles when moving the screen. So adding 20 pink tiles to each visible pillar/tile coordinate you should get around 20*50=1k tiles.

Then again why you’d need that many 1 pixel height tiles ontop of each other is very rare and performace shouldn’t be an issue if you stick to minimum of 8px height tiles, even on larger screen sizes.

here’s a post discussing a bit more in depth on how to draw only the visible tiles instead of ALL the tiles in the map: http://www.java-gaming.org/topics/drawing-isometric-tiles-inside-a-screen/24922/msg/212780/view.html

[EDIT]: Also, make sure you don’t load a seperate bufferedImage for every single tile in your game. Similar tiles should share the same bufferedImage. Take a look at this post for more info: http://www.java-gaming.org/topics/loading-multiple-images/24878/msg/212071/view.html

[Quadro]

1. dont draw textures on tiles you can’t see, probably the biggest thing here

2. don’t overide the paint method(I’m assuming you’re doing that, if not disregard this), run your painting in a thread, the performance increase is noticeable, on my machine cpu usage goes from 60 to 20

3. don’t use a lot of transparent images

4. limit your framerate, it can mean the difference from your game using 20 cpu or 5, a human can’t tell the difference from 100fps and 800fps

also check your code for slowdowns, I always monitor the FPS on games I’m making so the moment I do something where the frames jump from from somwhere over 1000 to 40 I can find what is causing it

[JESTERRRRRR]

I seem to remember having this problem, and solving it with Volatile images and bufferstrategy