×

Discussion Board

Page 1 of 3 123 LastLast
Results 1 to 15 of 34
  1. #1
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Cracow, Poland
    Posts
    50

    Nokia Series 40 Timer Accuracy

    Hello Everybody,

    I'm developing a game for Nokia platform which uses a lot of animation (sprites), therefore I had to design a thread that "ticks" in order to synchronize displaying the sprites properly. However, I'm not sure what is the accuracy for the internal timer i.e. what is the lowest difference between two calls to System.getCurrentTimeMillis(). Now my thread ticks every 50ms and it seems to be OK with Nokia 6610 (but I cannot check the other phones, because the emulator is too fast to find out whether the game is too complicated = too slow or not).

    I dug through all Nokia technical docs, but I haven't found anything about that...

    Has anyone encountered similiar problem? If so, please let me know, I'm really looking forward to your answer.

    Best regards,
    Bart

  2. #2
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    >>what is the lowest difference between two calls to >>System.getCurrentTimeMillis().

    Zero if you are lucky

    >>therefore I had to design a thread

    Why use a thread at all ???

  3. #3
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Cracow, Poland
    Posts
    50
    Yeah - 0 is possible - of course, but I didn't mean that particular case ;-)

    Thread is much better than timer because of two reasons:
    1) there are problems with suspending/pausing timer
    2) I'm not quite sure if you can control the timer's frequency e.g. if a timer is scheduled for periodical execution every X ms, and what happens if a) a task takes Y ms (Y < X) b) a task takes Y ms (Y > X) - I'd like the timer to behave in such way that It waits (Y - X) and then executes my function again, but I think it's X...

  4. #4
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    I didn't mean to use Timer or whatsoever...

    All you need is to poll the current time, see if your sprite's internal frame / movement "timer" (= ms delay between frame switches / movement) has fired and you are ready to go...

  5. #5
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Cracow, Poland
    Posts
    50
    I don't agree with you. Polling a time, as you suggest, must be put somewhere in the code. As you probably know the only way to do it on J2ME platform is to have a thread (or an instance of Timer class, which is, in fact, a system thread that calls an appropriate method). In both cases there is a thread that must wait the required time (tick frequency) and then execute a piece of code (e.g. that switches a frame, moves a sprite etc.).

    What I was asking, was the granularity of System.getCurrentTimeMillis() method, which is important for other factors like - maximum speed of a sprite (which also depends on how many pixels a sprite is moved in a tick) and maximum animation frame rate.

    As I prefer a good design over a temporary solution, I had designed a timer thread the calls a tick() method for all registered listeners e.g. sprites. It's up to the tick() method to decide whether a frame should be switched, a sprite should be moved, not to the caller.

    I hope I made it clear ;-)

    Thanks for your help.

  6. #6
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    Well, I did get your point earlier, I only think you are overdoing your design for a game with lots of animation.

    Yes, time polling is done "somewhere in the code", as well as your execution of calling registered listeners that in turn draw themselves / switch frames.

    "Granularity" of System.getCurrentTimeMillis() is one millisecond.

  7. #7
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Cracow, Poland
    Posts
    50
    Well, I consider you, Albech, as an expert on J2ME as I've seen a lot of yours posts. However, I still don't agree with you ;-) I can assure you that I'm aware of J2ME limitations and I use OO design not only because I'm used to that, but rather because of other advantages like time savings, code readibility etc.

  8. #8
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    >>Well, I consider you, Albech, as an expert on J2ME as I've seen
    >>a lot of yours posts. However, I still don't agree with you ;-) I
    >>can assure you that I'm aware of J2ME limitations and I use
    >>OO design not only because I'm used to that, but rather
    >>because of other advantages like time savings, code readibility
    >>etc.

    Thanks for the kudos

    Well, I do not fight OOP design per se - having programmed large software systems myself for more than over a decade, I know the advantages OOP have.

    The reason why I may sound a bit strict sometimes is, that all my input here is related to games running at maximum speed possible.
    If you are ok with your design and the results - great!

    I just always spent more time with proper OO design and even typing alone than actually coding :-)

    peace, bartekn, peace..

  9. #9
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Cracow, Poland
    Posts
    50
    Let it be! ;-)

    I really like your point of view of getting a game to run as fast as possible, this is exactly what I really want - a game should run as fast as possible, with a small memory footprint, if possible.

    I'm carefully reading your posts on other threads as I find them really valuable for me, good tips.

    Thanks, a lot. If it's possible I'd like to see one of your games, I offer the same from my side, when it's finished (I hope it'll be finished within 1-2 months).

    I'm also implementing a MIDP 1.0 emulator which could be used on a web. Have you any experience in that field?

  10. #10
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    >>I'm carefully reading your posts on other threads as I find
    >>them really valuable for me, good tips.

    Good to hear

    >>Thanks, a lot. If it's possible I'd like to see one of your games,
    >>I offer the same from my side, when it's finished (I hope it'll be
    >>finished within 1-2 months).

    Sure. Our last mobile game XGRA for Acclaim is currently presented at the Games Convention in Leipzig / Germany, afterwards it'll be officially released.
    Maybe I can convince Acclaim to release a public demo version...
    Will yours be commercial, too?

    >>I'm also implementing a MIDP 1.0 emulator which could be
    >>used on a web. Have you any experience in that field?

    Nice idea - yes, we've messed around with a similiar thing (although for a different platform) in the past - how are you progressing with that?

  11. #11
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Cracow, Poland
    Posts
    50
    It will be definitely commercial, however there will be a demo free for all, with a limited number of levels.

    Regarding the emulator thing, now it runs a pure J2ME app (however it can run only a class that extends a Canvas), I use it to test my game, if there is a new feature added to game that uses not implemented method/class, then it is being added to the emulator as well ;-)

    Now I'm about implementing Nokia specific UI, especially DirectGraphics and FullCanvas. I plan to release my emulator as a commercial product also.

    There will be a beta testing of game/emulator available to the public.

  12. #12
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    Sounds way cool,

    >>There will be a beta testing of game/emulator available to the public.

    Any time frame? I'd like to test 'em!

  13. #13
    Regular Contributor
    Join Date
    Mar 2003
    Location
    Silicon Scally
    Posts
    69
    "Our last mobile game XGRA for Acclaim"

    Is this the one: http://test2.o2online.de/o2/kunden/m...OnlineBild.gif? It looks very good! I take it the track is texture mapped? I'm being so nosey because I'm currently working on a title with a texture mapped track and dynamically scaled sprites - and was hoping it was going to be the first of its kind!

    Carl.

  14. #14
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    >>Is this the one: >>http://test2.o2online.de/o2/kunden/...=OnlineBild.gif? It looks very good!

    Gotcha, yes it is...
    But these shots are very, very old...argh...

    >>I take it the track is texture mapped?

    Right.

    >>I'm being so nosey because I'm currently working on a title
    >>with a texture mapped track and dynamically scaled sprites -
    >>and was hoping it was going to be the first of its kind!

    Not anymore, sorry for that...
    Any details about your game?

  15. #15
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Cracow, Poland
    Posts
    50
    The game should be ready in 1-2 months, now it's playable, but I'm not going to public it yet, the same applies to emulator, but it will be available later on, as I must implement a lot of javax.microedition.lcdui.* classes (mainly these that extend Screen class).

    I'll let you know as soon as the game and emulator is ready for beta testing, as a matter of fact, the beta testing will be available both for gamers that have a Java enabled phone and for those who want to play on the emulator ;-)

    The screenshots look pretty good, is it a CollinMcRay on J2ME? ;-))

    I'm interested in the max FPS of your game, and if it's playable for Nokia Series 40 (because of the passive display issues)...

Posting Permissions

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