Best way to do a tile-based map
Hello everybody-
This should be a simple thing but I just can't get it to work. I'm making a tile-based top-down online rpg (application, not applet), and I pretty much have most of it done except I can't get the map to display and scroll right. i will admit that java graphics isn't really my thing, but i just can't get it. Its been so frustrating that i actually quite develpment on my game and quit for awhile, but i decided to try again. What I have is an array if images that make up the map, and then i manipulate the array depending where the character is so i only draw the tiles necessary. what i want to do is to combine all the tiles i need for the particular position, draw that image to the screen (so i don't have to draw each tile individually to the screen). then i could move that large image depending where the character moved, and add tiles to it depending on which way the character moves. I just can't get it to work however. I've looked at double-bufferning posts and that gave me some ideas, but not enough for my particular situation. if anybody has any experience in this i would be more than greatful. thank you
[1160 byte] By [
kevinp34a] at [2007-9-28 1:49:01]
I know exactly what you are talking about, I had your problem a while back when I was doing mobile phone games.
To reduce the number of cell draws needed, cells were only drawn when at the edges of the view area. (all other cells were maintained from the previously drawn frame.)
It gets pretty complicated, but it will work - stick with it.
I would post some code - but I don't have it anymore - and it was pretty specific to J2ME MIDP API (java mobile phone).
p.s. When I did it, I had to include several additional optimisation, these made it incredibly complex :(
I will try to describe it, but without pictures, It will probably be in vain. (don't worry if you don't understand it :P)
here is the summary of the logic :-
the backbuffer had dimensions SCREEN_WIDTH+CELL_WIDTH*2, SCREEN_HEIGHT+CELL_HEIGHT*2 (I effectively had a border that was CELL_WIDTH wide, and CELL_HEIGHT tall.)
this meant new cells only had to be drawn every time the view area passed over a cell boundary.
however, doing this, meant it was super smooth until it hit a cell boundary, at which point it had to draw all the cells in the newly exposed column and/or row - which caused a jerk.
To get around this, I devised a speculative rendering, where by the next column/row was pre-rendered over a series of game frames.
(each column/row had its own buffer into which the pre-rendering was done)
On average 2-4 times as many edge cells had to be rendered than needed, but, because the camera moved slowly, this could be distributed over approx. 10 game frames.
By distributing the rendering of the edge cells over a number of game frames, I hoped to remove the jerk experienced as the camera crossed a cell boundary.
The system worked... ish... but I never finished it :(
basically, these were crazy optimisations that were only necessary because I was developing for mobile phones.
On mobile phones the speed of rendering is relative to the number of draw calls, NOT the actual area of the screen being repainted.
e.g.
fillRect(0,0,50,50)
fillRect(0,50,50,50)
will take almost twice as long as
fillRect(0,0,100,100)
even though you are only painting 1/2 the area.
