×

Discussion Board

Results 1 to 12 of 12
  1. #1
    Registered User
    Join Date
    Jul 2003
    Posts
    9

    30 FPS on S40 DP 1.0 device?

    Hello developers out there!

    I read this article about the J2ME game Miki's World (Java Game Porting) that you can find here (http://www.forum.nokia.com/info/sw.n..._v1_0.pdf.html). The authors say that they achive more than 30 FPS on Series 40 devices (see chapter 2.3.2 of that article).
    Since they use the Nokia 7210 (Series 40 Developer Platform 1.0) for Miki's World as reference device for that platform it sounds as that they are able to produce 30 FPS on that device. I have a Nokia 6070 (Series 40 2nd Edition) and wrote a J2ME application, but I am far far away from 30 FPS. If I use very primitive and less graphics I can get around 10 FPS on my device, even on 128x128 (native is 128x160).

    So I thought that my device is much slower than the Nokia 7210, but on JBenchmark (http://www.jbenchmark.com/index.jsp) it is stated that my device has a better CPU and overall performance than the Nokia 7210. So I downloaded a benchmarking JAR from JBenchmark for my device. The test results for MIDP1 Game test were 47 Frames.

    I am at the end with my knowlegde. How should it be possible to achive 30 FPS on Nokia 6070, or on a S40 DP 1.0 device?

    If anyone of you has a suggestion or benchmarking results for S40 DP 1.0 devices, any help would be appreciated.

  2. #2
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: 30 FPS on S40 DP 1.0 device?

    I've worked on a very large number of 7210 games, and I don't remember seeing any of them run at 30fps. I'm not going to say it's impossible, since I've made the mistake before of underestimating the 7210, and been made to look a fool!

    I wouldn't even aim to run at 30fps on a 7210. The display is passive (not active, TFT), so the update is very slow.

    I would consider 10fps as the target speed for a game on the 7210. Most devices are faster than the 7210, and so you will get better fps rates on better phones. The few devices that are slower will still give you a minimum-passable rate of at least 5fps. That sounds crap, but those devices do not represent big download volumes.

    From a game perspective, two things tend to be slow on the 7210.

    1. Game logic. You can make your game faster by simplifying the logic. Of course, this can have a negative impact on the play experience.

    2. Drawing images. Generally, it's less the number of pixels and more the number of individual images that makes a difference. There is an overhead for every call to drawImage(). Fewer, bigger images will draw faster. The downside here is memory... you don't have much, and the garbage collector is not defragmenting.

    You may get better performance using the Nokia-specific API for drawing pixel arrays rather then Image objects. However, you will reduce the portability of the code, and potentially increase the total cost of development.

    You may get better performance (don't quote me) by using many small PNGs, and avoiding the use of setClip() to isolate frames from animation strips. Downside here is an increase both in heap usage and JAR size.

    I would not spend time optimising a 7210 build to get more performance than is necessary, at a cost of development time, portability and feature set.

  3. #3
    Registered User
    Join Date
    Jul 2003
    Posts
    9

    Re: 30 FPS on S40 DP 1.0 device?

    Thank you grahamhughes for the fast and detailed answer.

    The suggestions you made are more or less the same I read already from books and forums. But now I got the same answers form a person with a lot of experience. Thus confirming those statements.

    The good news for me is that there seems to be a wrong (or misleading) documentation in the Miki's World document and in the results of JBenchmark (at least the interpretation of them).

    The bad news is that I now need to find and implement a solution for dealing with less than 30 fps for the game I am writing currently. I developed it mainly on a Nokia 6288 where I have no problems to get 30 FPS. Somehow I need to ensure that the speed of the NPCs is the same on different devices, even with less than 30 FPS. Since I don't know the FPS for all devices the game should run on, it must be determined automatically.

    That seems to be a tough problem, since the moving speed of the NPCs differs by screen size and FPS. I hoped it is okay to use a fix factor for each screen size that is used to scale the velocity of the NPCs. Unfortunately it seems not to be enough.

    Anyway, thxs again for your help.

  4. #4
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: 30 FPS on S40 DP 1.0 device?

    Quote Originally Posted by jonnyw View Post
    The good news for me is that there seems to be a wrong (or misleading) documentation in the Miki's World document and in the results of JBenchmark (at least the interpretation of them).
    That document is dated 2003 so, accuracy aside, I wouldn't regard it as a good guide to mobile phone game porting. The range of phones has increased dramatically since then.

    JBenchmark... is a useful resource. It's a convenient place to get rough specifications, and to get an idea about speed. Speed-wise, I only ever look at the headline figure, not the details. This does not give a precise indication of how a device will perform, but it does give you a picture of the relative crapness of different phones.

    Quote Originally Posted by jonnyw View Post
    The bad news is that I now need to find and implement a solution for dealing with less than 30 fps for the game I am writing currently. I developed it mainly on a Nokia 6288 where I have no problems to get 30 FPS. Somehow I need to ensure that the speed of the NPCs is the same on different devices, even with less than 30 FPS. Since I don't know the FPS for all devices the game should run on, it must be determined automatically.
    30fps is pretty fast for a game on a mid-range device. I'm afraid the 6288 is by no means the fastest phone, and the 7210 is not the slowest. Phones vary hugely, in a lot of different ways. Games that port well are generally those that can adapt to some extent at run-time.

    I'd recommend you place some maximum speed on the frame-rate (by timing the game-loop, and inserting a calculated sleep()). Never sleep for zero ms, though. Always have a sleep() of at least (say) 15ms. It sounds like it should slow the game down, but it tends to improve responsiveness, by ensuring that there is time to deliver keyPress() events.

  5. #5
    Registered User
    Join Date
    Jul 2003
    Posts
    9

    Re: 30 FPS on S40 DP 1.0 device?

    Quote Originally Posted by grahamhughes View Post
    That document is dated 2003 so, accuracy aside, I wouldn't regard it as a good guide to mobile phone game porting. The range of phones has increased dramatically since then.
    You are pretty right. I think this document is a good starting point. At least to see the issues of porting. In order to do game porting today a more complex solution might be necessary. A document grouping device specifica can found at http://javaverified.com .

    Quote Originally Posted by grahamhughes View Post
    30fps is pretty fast for a game on a mid-range device. I'm afraid the 6288 is by no means the fastest phone, and the 7210 is not the slowest.
    Are you afraid because it is possible to run 30 FPS on a 6288?

    Quote Originally Posted by grahamhughes View Post
    I'd recommend you place some maximum speed on the frame-rate (by timing the game-loop, and inserting a calculated sleep()). Never sleep for zero ms, though. Always have a sleep() of at least (say) 15ms. It sounds like it should slow the game down, but it tends to improve responsiveness, by ensuring that there is time to deliver keyPress() events.
    Thank you for the suggestion, I already do that. The general game loop looks like

    while(continueExecution)
    {
    long startTime = System.currentTimeMillis();
    repaint();
    serviceRepaints();
    Thread.yield();
    long duration = System.currentTimeMillis() - startTime;
    if (duration < TIME_STEP)
    Thread.sleep(TIME_STEP - (int)duration);
    }

    While the paint method looks like (of course very simplified)

    public void paint(Graphics g)
    {
    //retrieve input and move player
    inputGame();
    //move the NPCs
    npcs.move();
    //draw everything to the screen
    drawGraphics(g);
    }

    The main question is now how to ensure that moving NPCs is the same independent on FPS and screen size?
    Say you developed the game for fullscreen 240x320 and that the device is able to produce 30 FPS (which is the maximum frame rate as ensured by TIME_STEP). If the move method is implemented as follows

    public void move()
    {
    x += vx;
    y += vy;
    }

    then the NPC would need 240 frames to move from x=0 to x=240 when the velocity is vx=1 and vy=0, so it takes 240/60=4 seconds to cross the screen.
    If you port that game to a device with fullscreen 128x160 you might scale the used images by a factor of 0.5 (I know that 0.5 isn't absolutely correct, but to ease the calculation let us assume it is). If you still use vx=1 and vy=0 as velocity the NPC would only need 128 frames to move once accross the screen, i.e. 128/60=2 seconds. That is twice as fast as on the other device. In order to get the same gaming experience you need to scale the velocity also by a factor of 0.5. (Assume further that x is a double instead of an int value, so that we don't run into problems with velocity values below <1). After scaling the velcoity and images you again need around 240 frames to move the NPC from left to right.
    All this calculation assumes that 30 FPS are reached all over time. So once the device (128x160) reaches only 10 FPS you have a problem: instead of 4 seconds you now need 3*4=12 seconds to move the NPC from left to right.

    Since the FPS you get with your game is highly dependent on your implementation and the device it is running on, it isn't enough (possible) to check the device descriptions (e.g. from JBenchmark) to know the scaling factor for the velocity.
    Even more worse is the point that usualy porting is done for reference devices that represent a group of devices with similar specifia like screen size and maximum JAR size, ... I would assume that the reference device has the lowest performance of the group of devices. So even if you know the velocity scaling factor of the reference device it might be that the NPC runs much faster on other devices belonging to the same group.

    The only solution to deal with that problem I can see is to develop an algorithm that takes the current FPS of the device into account.

  6. #6
    Super Contributor
    Join Date
    Jan 2008
    Location
    Amravati, India
    Posts
    546

    Re: 30 FPS on S40 DP 1.0 device?

    Quote Originally Posted by jonnyw View Post
    then the NPC would need 240 frames to move from x=0 to x=240 when the velocity is vx=1 and vy=0, so it takes 240/60=4 seconds to cross the screen.
    It should be 240/30 = 8 seconds
    Because it's 30 fps and not 60 fps...

  7. #7
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: 30 FPS on S40 DP 1.0 device?

    Are you afraid because it is possible to run 30 FPS on a 6288?
    Some people think that a good plan is to run the game at the maximum possible speed of the device, and not lock a maximum speed as you are (wisely) doing.

    Your loop... I recommend you move the update and input handling out of the paint() and into the run(). Some (crappier) devices struggle if the paint() method takes too long. The system also sends paint() messages to your app, so updates might happen when you're not expecting them. Also, since your run() loop knows how much time has elapsed, you can use this information to adjust your animation.

    If you use time-based animation and movement, keep the frame-rate lock you already have. Otherwise, on much faster devices, plugging small units of time into your algorithm might give unusual results (like, zero).

    Thread.yield() is pretty much useless, since unless there is a higher-priority thread in a runnable state at that instant it won't do anything. It works better if you make sure your sleep() time is never zero.

    Choosing reference devices for mobile development has to account for many factors. You don't necessarily choose the slowest phones. So yes, there will be faster phones, but also slower.

    Main device variations are: screen size, heap size, JAR size and performance. But also: API availability, sound player capability and quality of JRE implementation.

    Cheers,
    Graham.

  8. #8
    Registered User
    Join Date
    Jul 2003
    Posts
    9

    Re: 30 FPS on S40 DP 1.0 device?

    Quote Originally Posted by grahamhughes View Post
    Your loop... I recommend you move the update and input handling out of the paint() and into the run(). Some (crappier) devices struggle if the paint() method takes too long. The system also sends paint() messages to your app, so updates might happen when you're not expecting them.
    Due to your suggestion I will change my implementaion back to the run method version. My first implementaion was exactly as you suggest. Then I read that book about J2ME programming where the other (above) version is suggested, and I changed my code.

    Quote Originally Posted by grahamhughes View Post
    Thread.yield() is pretty much useless, since unless there is a higher-priority thread in a runnable state at that instant it won't do anything. It works better if you make sure your sleep() time is never zero.
    Exactly it is useless as long as it is ensured that sleep is called. Maybe I will change that also (it is from the book as well).

    All in all I would like to thank for the nice discussions (also for the correction on my mathematics).

  9. #9
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: 30 FPS on S40 DP 1.0 device?

    Hmmmm... I think you should throw that book away and go with your instincts...

    Another point on event handling (I'm guessing you do this already)... keep game logic out of any event, including keyPressed(). All you want in the key events is to record the event (probably in a queue).

    I've seen games literally littered with yield()s, and no good ever comes of it. The difference between a sleep() and a yield(), is that a sleep() will always cause another thread to run. Thread.yield() has a nasty habit of taking thread priority into account. There is no requirement for a JVM to implement a priority model, and if it does, no requirement that specifies whether the event thread(s) should run at a higher or lower priority than normal. So, yield() might do what you want, but that depends very much on the implementation. Code that runs nicely on Nokias can suddenly become rubbish on less well implemented VMs.

    Porting MIDP games is my specialist area, and I'm happy to share my experience. Glad if I have been of help.

    Cheers,
    Graham.

  10. #10
    Registered User
    Join Date
    Aug 2008
    Location
    Berlin
    Posts
    18

    Re: 30 FPS on S40 DP 1.0 device?

    Maybe you can manage to make the animation time based rather than frame based.

    Example:
    You want the item to move from x1=0 to x2=50 in duration=4000 milliseconds. When the animation starts, you store the start time (currentTimeMillis). Calculate the progress every frame with (currentTime - startTime) / duration. The position is x1 + (x2-x1) * progress.

    This way the framerate doesn't matter.

    I can give you some classes which automate this process, if you send me your eMail.

  11. #11
    Registered User
    Join Date
    Jul 2003
    Posts
    9

    Re: 30 FPS on S40 DP 1.0 device?

    @graham:

    Thx for the hint with the event methods, I did that already. Due to your explanation about yield, I will replace it by sleep.
    I read two books about J2ME - game programming. During reading I thought the first one is much better than the second. Now it seems that both are not very good. Do you have a recommendation for a good one?

    Since you are a specialist in porting, you might tell me how professional porting companies/game studios work. Do they have hundreds of devices laying around, where they perform the testing? If so, are there any alternatives? The only option that I know to get access to some devices to perform test is a platform/programm by Nokia. It is the programm where you can access real devices by a. Nokia framework. I don't know the name yet, but you can find it here on the Nokia pages.
    Since I am a private person I don't have the money to buy that many devices or participate in Nokia's programm, but I would like to support the game on as many devices as possible, because I plan to sell the game.

    Is there any documentation on how to do porting (tutorial, hints)?

    @xisari:

    Thy for your offer, I would like to see your code examples. How do I give my e-mail to you?

    @all:
    I searched the internet regarding time-based animation. I think the "fixed interval time-based animation" technique you can find here http://www.sacredsoftware.net/tutori...nimation.xhtml is the best one to use.

    But there are still some issues:
    1.This technique depends heavily on the timer and its resolution. The timer resolution must be very accurate. If I remember right I read that on some devices the resolution is 40 ms, which seems not be accurate enough. A time resolution of 40 ms means that within a timeperiod of 40 ms you can call System.getCurrentTime() and you get the same result.
    2.The device must still be performant enought that it is able to run the game logic with 25-30 FPS.
    3.The problem is not only moving a sprite, but also the animation of different frames of the sprite.

    Due to all these problems I thought that it might makes sense to not support those devices that aren't able to produce, say, 25 FPS. But if you want to sell your game, the sellers want from you that you support as many devices as possible. That is something I don't really understand.
    1.The more devices you must support the more expensive the development costs are. I heared that 50% of the overall development cost belong to porting.
    2.The device manufactures should be happy that older devices aren't supported, since the people have another reason to update their device.

  12. #12
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: 30 FPS on S40 DP 1.0 device?

    Yes, basically, porting shops have a thousand phones.

    Games studios, on the other hand, are a different matter. In general, game development and porting are handled by different teams, and frequently by different companies. Many games studios will only develop the game, not port it. Instead, they will develop to a set of "reference" devices, usually selected by the publisher.

    Different companies will choose different reference devices, but (assuming you're not working in 3D), the top choices include:

    * Nokia 7210 (128x128, 200k heap, 64k JAR)

    * Sony Ericsson K700 (176x220, 500k heap + 800k image-heap, around 500k JAR)

    * Motorola V3 (176x204, 800k heap, quite slow but popular)

    * Sony Ericsson K800 (240x320, 3Mb heap, 3G downloads and fast performance)

    Realistically, you are not going to port a game to hundreds of devices single-handed.

    Big question is: to whom to you plan to sell it?

    The easiest way to make some money from writing a mobile Java game you wrote alone, is to use it as a demo to help you get a job with a game studio...

    Cheers,
    Graham.

Similar Threads

  1. What we want is a basic function device.
    By hendrysong in forum General Development Questions
    Replies: 1
    Last Post: 2008-06-06, 04:02
  2. Installing Certificates on Nokia S40 device
    By danielv in forum Mobile Java Networking & Messaging & Security
    Replies: 8
    Last Post: 2006-11-15, 01:16
  3. Nokia手机主要参数列表
    By cqucyf in forum [Archived] Other Programming Discussion 关于其他编程技术的讨论
    Replies: 0
    Last Post: 2005-05-04, 16:34
  4. Switching back to Series 60 SDK v1.2, Builder X
    By fabiano_pmj in forum Symbian Tools & SDKs
    Replies: 2
    Last Post: 2005-01-19, 17:11
  5. Error after typing bldmake bldfiles
    By uckermark-girl in forum Symbian Tools & SDKs
    Replies: 1
    Last Post: 2005-01-19, 07:48

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×