[ysuter]

what is the most efficient way to handle huge 16x16 tileset areas, where a character can walk/jump around (scrolling). I use the 7210 SDK with a screenresolution of 128x128 - so a lot of stuff has to be drawn. here some ideas I'm playing around with.

a) redrawing all 64(+8 when moving) tiles per frame
b) having a 128x128 prerendered image. now when scrolling I just need to draw 8 additional tiles on the left/right (depending in which direction the player is moving.
if the side-tiles are completely visible an update of the whole center-image is necessary.

I mean, the memory constraint makes the task not very easy and as I handle all the used tiles already in-memory I don't have much mem left. using solution b) needs a full-framesize image to be allocated and I doubt that a second frame-allocation is possible anymore (but wich is necessary).
So I when I conclude my analysis it seems, it seems that a) is the way to go.

tricks like not updating unmoved and static areas could speed up processing time. but it would result is visible fps-differences - so additional time-controling algorithms will be necessary.

any other ideas or points to take in account? help is very much appreciated! =)

[doctordwarf]

To fix maximal framerate use System.currentTimeMillis(); and
Thread.currentThread().sleep(MILLIS_PER_FRAME - timeTaken);

[dannyc4]

@ysuter: You must take in account that method calls are very slow... If you call drawImage() 72 times you shouldn't expect 20 fps. Same goes for drawPixels() 72 times. It probably leaves you with about 13 or 14 fps, though the latter is faster.

So you are better off using that second option. BTW Memory full? How???

If you do want to use first option you may look into using a short[] array framebuffer, then use drawPixels() once to blit it all (15 ms on a s30). Furthermore, filling the framebuffer can be done very fast! This way you should be able to get 15+fps.

But I guess you really have to test yourself what's best, most easy and acceptable for you.

[ysuter]

@drDwarf: the trick is very nice and I saw it in different examples. I will definetly use something like this.
related to this topic I would like to ask, what is the **usage**-different between implementing a *.yield() or *.sleep() method. I even saw examples, which used both (from the benchmark source code):

if (time < 60) {
Thread.sleep(60 - time);
} else {
Thread.yield();
}

after reading the specification of the yield method I thought, that this might be the best way to go.. but after changing the code of my midlet, i experienced strange input-handling (especially on the emulator). it seemed that the input callbacks to keypressed/release where delayed.
The problem causing the delays is probably, that I took to much time forcing my rendering methods to spend to much time and not ginving the system.thread enough time to process in time.

I like the benchmark-code and therefor I think using a similar codedesign. but 60ms for a frame? resulting in 16fps max.. is that common? (hrmm.. I have my roots in the asm/win32 dev so I don't know all the (interesting) details of midlets)

-------------------------------

@danny: I know and it didn't worked very well so that I'm still optimizing the rendering concept. It's quite hard to find a way which ist flexible and efficient. One problem to ensure a constant fps is to update wisely the moment to update incomming regions when moving around.
mem-probs.. well, in the last game I did I hab to preload a lot of resources and raw-data to load all at the same time and there I encountered strange thinks when allocating the datas. suddenly I couldn't load any tilesets anymore (null referenz return).. even a System.gc() call couldn't solve these problems. I had to reorganise to make it run again..

[doctordwarf]

seemed that the input callbacks to keypressed/release where delayed.

Probably your input hadling thread was the same one as drawing one.
You commanded it to sleep.. well, it slept and, hence, delayed event dispatching :)

[ysuter]

not, that cannot be the solution, because when using sleep the input-delay doesn't occure. when using yield, the rendering seems to be faster, but the input reacts differently.. well, will have to make further tests to find the explanation.