RPG Tile Based Map Programming

Question

Does anybody have any experience in this area? I have an online rpg type game that I'm working on and its going fine, the only problem is that the map scrolls too slow so your character moves too slowly. For my map I simply extended a JPanel. For every tile the character moves(one tile = 32 pixels) the screen is redrawn 8 times (each redraw basically moves the whole screen 4 pixels in the desired direction) in this way the screen moves very smoothly and character animation is smooth, but it is also pretty slow. Can anybody offer any suggestions? I would love to talk with people who have done this type of thing before becuase it is my first stab at it. thanks.

Answer 1

the reason your drawing is slow, is because you are redrawing every cell, every frame. This is unnecessary, as you can reuse the cells you drew in the previous frame, by simply shifting them by the appropriate amount.
let me clarify:
I will use some real numbers to demonstrate the optimisation.
screenWidth=800, screenHeight=640, cellWidth=32, cellHeight=32;
scrollSpeed=8; // << the number of frames it takes to move by 1 complete cell
just to render the background, your current approach calls drawImage this many times every frame
(screenWidth/cellWidth+1)*(screenHeight/cellHeight+1)
e.g. (800/32 +1)*(640/32+1) = 546 cell redraws/frame
There are several approaches you can use to fix this, all require the use of a cellBuffer to cache the previously drawn cells.
1) draw the cellBuffer onto itself, and redraw all the cells that have become corrupt.
Approach will require (screenWidth/cellWidth+1)+(screenHeight/cellHeight+1) cell redraws
e.g. 800/32+1 +640/32+1 = 47 cell redraws/frame
2) have an oversized cellBuffer (with dimensions of screenWidth+cellWidth*2 by screenHeight+cellHeight*2).
With this method, redraw of exposed cells is only necessary every time you cross a cell boundary, not every frame rendered.
Assuming you are moving at a constant 4 pixels/frame as you describe in your question, that will mean
e.g. 800/32+1 +640/32+1 = 47 cell redraws every 8th frame (an average of 5.9 celldraws/frame)
This method has the lowest number of celldraws per frame. However, because you draw all newly exposed cells, in 1 go, you end up with choppy scrolling.
3) This method attempts to solve the problem of choppy scrolling, by using predictive edge cell drawing, and distributing the cell rendering over multiple frames. (giving a more consistant frame rate)
using this method, requires you to have 4 additional buffers (1 for each edge of the screen)
into these buffers, the predicted cells will be cached.
This algorithm has 2 important factors deciding its efficiency, if the viewport scrolls quickly, its efficiency will drop massively.
The accuracy to which you can predict which edge buffer to fill up first also greatly influences the algorithms efficiency - therefor it is better suited to use in an environment where the direction of scrolling doesn't change rapidly.
Best case performance is ((screenWidth/cellWidth+1)+(screenHeight/cellHeight+1))/scrollSpeed (assumes you are moving in both axis, if only moving in 1 axis, the performance would be even better)
e.g. ((800/32+1)+ (640/32+1))/8= 5.9 cells/frame
Worst case performance is ((screenWidth/cellWidth+1)*2 + (screenHeight/cellHeight+1)*2) /scrollSpeed
e.g. ((800/32+1)*2 + (640/32+1)*2)/8 = 52+42/8 = 11.8 cells/frame.
So, as long as you scroll at a constant 1 cell every 8 frames, this algorithm will give you a performance per frame of between
5.9 and 11.8 cells/frame.
As you can see, even the simple method highlighted in method 1) is approx. 9 times faster than your current method.
and, if the choppy scrolling of method 2), or the limitations imposed by method 3) are acceptable for your implementation, you can get an algorithm that will run approx. 50-100 times faster than your current method.