×

Discussion Board

Results 1 to 9 of 9
  1. #1
    Regular Contributor
    Join Date
    Sep 2004
    Location
    Adelaide
    Posts
    73

    Java Game freeze by unknown reason

    Hi guys,
    I wrote a j2me game using standard MIDP2.0 API. It has no sound, it does not use any external apis. It is just a simple 2D arcade game.

    I test it on Nokia 6630. The game apprently freezes after a minute playing during game play. The screen freeze and the phone does not respond to any input. I had to switch off the phone and restart it.

    The game runs perfectly on any non-symbian phones. I am wondering do I need to port the game onto Symbian Java ....

    Anyone has any suggestion?

    Kit

  2. #2
    Registered User
    Join Date
    Dec 2003
    Posts
    5
    Does it work on the 6630 emulator? Have you tried it on 6600?

    Try to call System.gc() on each game loop, any difference on stability (yes the game will be slower, but is it more stable?).

  3. #3
    Registered User
    Join Date
    Sep 2003
    Location
    London, UK
    Posts
    5
    Had a similar problem on the 6680 which I believe is in the same series of devices.

    It seems that the paint() method runs in a separate thread and if it takes too long, the main thread resumes execution. There is then the possibility that paint() is called again before the previous one is finished.

    The solution was to set a boolean - paintComplete - and check for it on entry to the paint method. If it's false then return. This variable is set to true at the end of the method.

    One other possibility is to synchronise the paint() method - didn' t try that though.
    Last edited by osullivp; 2005-06-17 at 15:00.

  4. #4
    Registered User
    Join Date
    Dec 2004
    Location
    Liverpool, United Kingdom
    Posts
    16
    In addition to the other suggestions, remember to call the game thread's yield() method in the main loop otherwise you're at risk of locking everything up.

    Also, you should call sleep() at the bottom of the loop.

    Here's what I mean:

    public void run() {
    while( ! gameOver ) {
    .. Game logic & paint calls
    Thread.currentThread().yield();
    try {
    Thread.currentThread().sleep(25);
    }catch(InterruptedException ie){}
    }


    Ideally, you want to lock your main loop to 24 frames per second so you'll have to do some calculations at the top and bottom of the loop to find out how long you should goto sleep for.

    However, your problem sounds like a low memory issue. If you are calling Image.createImage() in your main loop then you're going to frag the memory, which can also cause the phone to lock up when the fragments become too small.
    Allocate all images before you go into the loop.

    --Mario

  5. #5
    Registered User
    Join Date
    Feb 2004
    Location
    TLV
    Posts
    20

    Re: Java Game freeze by unknown reason

    Just a confirmation to "osullivp" post:

    The game I'm currently developing is working fine on a 6600 but on 6630 or 6680: it just exits from time to time, without any explanation (except that it occurs at somehow graphics-intensive moments in the game...)

    Note: It's a pure MIDP-2 app that works very well on Sony-Ericssons and Motorollas.

    Solution to the problem:
    1) switching the code from { MIDP-2: GameCanvas / flushGraphics / drawRegion } to {NOKIA UI: FullCanvas / repaint + serviceRepaints / setClip + drawImage }
    2) and, most importantly: synchronizing the paint() method in my FullCanvas

    Next step: switching back to pure MIDP-2 and finding a solution that will work there too (will keep this thread updated...)

  6. #6
    Registered User
    Join Date
    Feb 2004
    Location
    TLV
    Posts
    20

    Re: Java Game freeze by unknown reason

    Follow-up on the previous post:

    The source of my problems on 6630 & 6680 was apparently not due to the lack of synchronization of the paint() method, but rather related to "Just In Time" compilation issues.

    More details in this precious thread: http://discussion.forum.nokia.com/fo...t=58010&page=2

  7. #7
    Registered User
    Join Date
    Jan 2004
    Posts
    1

    Re: Java Game freeze by unknown reason

    I have enountered this problem with 6630 and 6680 in at least 3 of my last games. Random lockups (well, not really random, it was always at the same point but this point of code is not always easy to find in a game), apparently wrong values in variables and so on.

    These bugs only occur in lengthy and/or complex methods which use many local variables (e.g. 10 or more). The only solution which worked for me up to now is to split those methods, and replace local variables with global ones which are only used by this method (this is UGLY of course, but at least it works).

    For the second problem - lags while the JIT is compiling new code on the fly - I usually simulate each situation in the game while showing a loading screen. Thats not always easy todo, but works fine then.

    Btw, the JIT-Bugs are not limited to S60v3 only. They appeared already on Siemens CX65/C65 where the workaround is the same: changing local variables into global ones.

  8. #8
    Registered User
    Join Date
    Sep 2004
    Posts
    1

    Re: Java Game freeze by unknown reason

    I had similar issue. The game would freeze within a minute of gameplay. I narrowed down the problem to image flipping done using MIDP2.0 drawRegion() method.

    If you are using drawRegion(), try working around it and that might solve the problem

  9. #9
    Regular Contributor
    Join Date
    Mar 2003
    Location
    UK
    Posts
    229

    Re: Java Game freeze by unknown reason

    I've just hit this issue too.

    For future reference, here's what I think is happening. If you use drawRegion to flip the whole of an Image object into the screen, a small amount of system memory is eaten up. My game dies after about 30 minutes of play. If however, you flip just a limited region of an image onto the screen, a stack load more is used. Internally, I bet the code is allocating a new piece of memory, copying the image data and flipping, then blitting that to the screen, but not cleaning up after itself.

    Do this every frame and it doesn't take more than 30 seconds or so to completely exhaust the system memory and *bang*, game locks up.

    I'll be dusting off the old Nokia UI tomorrow!

    Cheers,

    Steve

Posting Permissions

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