I think I may have found possible reasons for a slowdown, and I'd like your help in analyzing this as a possible solution.

My game is a 2D tile-based game.

The current world area is 128 by 128 tiles, each of which is 64 pixels.

The viewable area is 512x512 pixels, or 8 tiles on a side.

You should be able to move one tile in one second. Most characters have 8 frames of animation to display in that time, so I'd like to achieve 32 fps. (there are times in the game you should move faster, like on a speed potion).

Here is what I'm doing to paint the screen:

I have a thread that just draws the background. This is done the moment you start a movement... it uses two buffers and switches the buffers when movement stops, so it can take up 1000 ms to draw. I doubt this drawing is an issue.

To create the offScreenBuffer, which is FINALLY painted to the screen, I first blit the current BackgroundBuffer +/- the scrolling offsets.... this is one g.drawImage().

The foreground images must be interleaved with character images to achieve the depth illusion, so unfortunately they MUST be redrawn every frame. I have drawing rules which state that top-right is furthest away, and bottom-left is closest, giving us a diagonal "perspective" so to speak. In order to paint these images, I got the first thing I could think of to work: a nested loop that draws top-to-bottom, right-to-left.

This results in 192 checks to see if anything is there needing to be painted. And I think it is slow to do this.

I am wondering whether I should load foreground tiles, those non-moving images in the game that interleave with characters (trees, fountains, etc), into a Quadtree.

I'm thinking of creating a Quadtree that holds an object called MapCell, which contains three variables: foreground, character, and flying. If anything there needs to be painted, I'd just draw the image right then. My reasoning is that although g.drawImage might be slow, the following loop is likely slower:

I can't imagine that those comparisons are taking a significant amount of time.

If you think they are, I would first profile or at least do some experiments. You could for instance run a test where you have no comparisons in that loop. maybe split the loop in two parts, so that the appropriate number of foreground blits happen so you can get a measure of drawing the average amount of foreground tiles without any per-tile comparison.

My very next thing to test is going to be just how long it takes me to draw a frame.

Trying to achieve 32fps when it takes me 120 ms to draw a single frame isn't going to work.

At that point, though, I think I'm onto that other thread about FPS and 1.3.1, where there is NOTHING I can do as I have no acceleration of images right now. That's assuming that either drawImage or Memory copies are that slow.

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