| Reply | « Previous Thread | Next Thread » |
|
Greetings,
I'm programming/porting game to Series30, 3510 namely and I have a big trouble to have similar speed (=key response) like on Series60. Do you know which processor is in this machine? I found only one for 7650: 104 Mhz ARM and have no comparision between these machines. If you have optimized, is there somewhere some list of methods better not call to? with times? for instance my code spends 20% in drawString and I would like to know all expensive methods. I've read bellow article, but it is only one example, I would like to have more information about methods. www.developer.com/ws/j2me/article.php/2234631 Some other books about optimization?I mean j2me specific. Or do you thing it is impossible to have it working on 3510 (animation of 3 images 30x40 pix 8bpp with background image)? In fact it is working now, but responses are different. like m$word on 486/25MHz ;-) Please, if you have any experience with 3510 and performace, tell me if I should optimize or surrender ;-) |
|
One of the things someone stated here some time ago: Just use paint() for painting... Do not implement any business/game logic in the paint method. This is because repaint() is an event and there is only one event handler. Thus while executing the repaint() event, no other events (like key events) can occur.
So if your paint method does a lot, consider using a framebuffer (either Image or short[]) that you fill from outside and just use paint() to draw that image or short[]. BTW the latter is faster on series 30. I guess that document you found is good enough to get started. And this forum also has a lot of topics about it; just do a search. gr, Danny |
|
BTW: I don't think anybody can tell you whether to optimize or surrender if we don't know what you create.
Unless it is some Doom like 3D game I guess you should optimize... |
|
Thank you very much.
Just few more questions. 1) Is it possible to run profiler with nokia api (displaying short[] is avaiable only in their SDK I'm afraid, and creating mutable images(for framebuffer) as well). BTW: Am I wrong or 'speedy' methods have no counterpart in standard MIDP? 2) How mechanism of double buffering works? Example: I want to measure time between displaying a thing and user keypress. Where is right place to put System.currentTimeMillis? Just now I have it on the end of paint method. But after finishing paint there is extra buffering (done by system) I think. Can I switch it off somehow? Better solution for measuring time? |
|
1) I'm never profiled j2me code yet (except for doing some currentTimeMillis() measuring), so I don't know.
MIDP doesn't include Nokia API like methods. I'm not sure how they perform against eachother. But, having read some topics on this forum, DirectGraphics should be faster with drawImage() than MIDP is. Probably because MIDP has to convert from PNG format. 2) Double buffering works quite simple and as I understand is default on each Nokia phone. When the paint() method is called, the Graphics reference will point to an offscreen Image. When the paint() method finishes, the system automaticly blits the offscreen image to the display. If the system doesn't support double buffering you would be drawing directly to the display and you might see the image building up (screen flicker). Beware: be sure not to mutate "painting related data" while the paint() method executes. This may also cause some screen flicker. Just put the currentTimeMillis() where it is required to measure time. If you use it for game loop triggering, don't put it in your paint() method, but create a thread to do game logic, image creation and time measurement. Note: you can force a repaint() by calling serviceRepaints() directly after it. gr, Danny |
| Reply | « Previous Thread | Next Thread » |
| Thread Tools | Search this Thread |
|---|---|