×

Discussion Board

Page 1 of 2 12 LastLast
Results 1 to 15 of 18
  1. #1
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Eire
    Posts
    182

    Pausing a thread when the user leaves the MIDlet

    During an active play session if the game is interrupted it must be paused and saved and the user must be able to continue the game with a continue game option from the main menu.

    I can understand how to add a continue option to the main menu if the game gets paused and remove the option if it is not needed.

    But how to you keep all the game states saved when the user gets an incoming call and dose’nt come back to the game for at least 24h.

    Do you just pause the thread and then resume it when the user comes back to the game. Is this a possible solution. Would pausing the thread still mean that your game is holding stack memory for the time until the user comes back to the game.

    Reading the Developer Check list there are some difficult stuff there needing implementing ( well I suppose once you’ve done it once you’ll know how to implement it again for the next applications)

    You need to also do the above when a soft key is pressed and when a red soft key is pressed and when the application is exited and the user does not press the button.

    How do you save the game when an incoming call is received when you need to save it for long periods.

    I think using the showNotify() and hideNotify().

    But do you pause your thread… surely saving everthing to RMS is not a solution.


    Brian

  2. #2
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113
    I track hideNotify and showNotify and set boolean variable.

    1.
    I do not pause threads because I don't have them
    I use callSerially strategy.


    2.
    Red button does not pause your app, it closes your app
    surely saving everthing to RMS is not a solution.

    Surely it is
    That's what RMS is for - to be a persistent storage

  3. #3
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Eire
    Posts
    182
    doctordwarf you must answer nearly all my questions!!!

    1) callSerially ...... i will ask you more about this again, have only one thread inmy game and it suits the game perfect!

    2) Red buttton... accordig to nokia it should have 2 functions a long press and a short press... !!??



    If i got 19 variables to save i dont think tricking with RMS is too appealing... :-/

    I though something like having the MIDlet still running in the backgound was the solution maybe using some kind of yeild statement... i really dont know actually...

    Brian

  4. #4
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113
    1) callSerially ...... i will ask you more about this again, have only one thread inmy game and it suits the game perfect!

    It depends on the game type. For arcade it might be not the best solution..

    There is a description somewhere in Nokia tutorials.
    Basically it's as simple as
    Code:
    YourMainGameObject.update() {
    ....
    Display.getDisplay(refernceToTheMIDlet).callSerially(this);
    canvas.repaint();
    canvas.serviceRepaints();
    }
    This continiously paints and calls your code right after repaint.

    2) Red buttton... accordig to nokia it should have 2 functions a long press and a short press... !!??

    I don't really bother about it
    Pausing is handled by hideNotify and closing by MIDlet's destroyApp. It's phones headache to decide which method to call.

    If i got 19 variables to save i dont think tricking with RMS is too appealing... :-/

    Well, I'm doing a strategy game, so I already have methods to save/load game state.
    I think you'll have to deal with RMS. Anyway your app will be closed sometime and you'll have to save the gamestate.
    19 variables isn't too many

    I though something like having the MIDlet still running in the backgound was the solution maybe using some kind of yeild statement... i really dont know actually...

    I would strongly discourage this approach.
    Not talking about the fact that phone might not allow "background execution" this means that your MIDlet will continue consuming memory AND POWER. And anyway app might be closed somehow

  5. #5
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Eire
    Posts
    182
    Maybe i'm misunderstanding what Nokia want.

    In the Developer_Checklist_for_J2ME_Game.pdf

    Under the System Requirments Heading

    8) During game interaction the current game the current active game session is paused and saved (ready to be retrieved through the continue functionality ) when the following events occur

    - An incoming call is recieved
    - A softkey is pressed and the screen display changes
    - The red softkey is selected
    - The application is exited and the user does not quit the current game section.





    What exactly is required to be implemented.

    The last one seems the most tricky!!??

  6. #6
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395
    Don't worry about how many variables you save in RMS. The important thing is: don't save each one in a separate record. Use a ByteArrayOutputStream, wrapped in a DataOutputStream to write your entire state to a single byte array, then save it all in one record.

    Graham.

  7. #7
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Eire
    Posts
    182
    IS that what Nokia are expecting of you!?

    I just figured out this week saving to single RMS records.....LOL

    I will see i can figure out saving everything to one record....

    Graham to you implement the above, that nokia require?

  8. #8
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395
    I don't know about Nokia's expectations... I can tell you that writing a record to RMS is slow, and the time taken appears (for Series 40 phones) to be "per record", not "per byte". I mean, 100 records of 100 bytes each will take almost 100 times longer to write than 1 record of 10000 bytes, even though the amount of data is identical. So writing 19 variables separately might be painful, whereas writing them all in one go should be OK.

    To write multiple fields in one record, you will have to shove everything in a single byte array. You could assemble everything in a String, then use getBytes(), but I think a DataOutputStream is easier and more flexible.
    Code:
    ByteArrayOutputStream bout = new ByteArrayOutputStream ();
    DataOutputStream dout = new DataOutputStream (bout);
    
    dout.writeUTF ("some text");
    dout.writeInt (57);
    dout.writeBoolean (true);
    
    byte [] data = bout.toByteArray ();
    
    RecordStore rs = RecordStore.openRecordStore ("state", true);
    try {
        if (rs.getNumRecords () == 0) {
            rs.addRecord (data, 0, data.length);
        }
        else {
            rs.setRecord (1, data, 0, data.length);
        }
    }
    finally {
        rs.closeRecordStore ();
    }
    Reading back is the same, but in reverse... read the byte array, then use it to create a ByteArrayInputStream, then a DataInputStream. Read the information in the same order as it was written, using the corresponding readXxxx() methods.

    Graham.

  9. #9
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Eire
    Posts
    182
    Thanks graham will start getting this implemented!

    Is it possibel to put 30 varaibles in one record or is there a limit.

    I have 27 ints, 8 booleans and 3 chars


    Would they all fit in 1 record or is there actually no limit?

  10. #10
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395
    The total amount you can store in RMS varies from phone to phone... the MIDP 1.0 specification requires 8k, Series 40 devices typically have around 20k. There should be no limit to the maximum size of a record within this - I have created records as large as 10k. Size is the only limit, not number of values, as it is simply a stream of bytes. The writeUTF() method can't write a String longer that 32767 characters (I think!).

    ints take four bytes each, booleans take one and chars two, so I don't think you should have a problem on the size front.

    Graham.

  11. #11
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Eire
    Posts
    182

    Design q?

    Got a design question now related to RMS.

    I want to have the game saved if the application is forced to exit by say a phone call or if the red button is held down.

    Can I do this from destroyApp() ??


    Code:
    public void destroyApp(boolean unconditional) 
    	{
          	if (mgameCode.gameRunning == true)
    		{
    		try
    			{
    			db.saveEverything();
            			db.close();
          			} catch(Exception e) {}
    		}
          	notifyDestroyed();
        	}

    If not is there away to do this or are Nokia sending me around in circles??

  12. #12
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113
    Your MIDlet can just go offscreen without closing when call or SMS arrives. It does so on Series 60, not sure about Series 40.

    I prefer to track hideNotify event.

  13. #13
    Regular Contributor
    Join Date
    Aug 2003
    Location
    Eire
    Posts
    182
    Yeah thats true that hideNotify() is called but there is no need to save the game when it goes off screen, just pausing the thread woorks fine for that?

    I took a piece below from In the Developer_Checklist_for_J2ME_Game.pdf

    Under the System Requirments Heading

    Code:
    8) During game interaction the current game the current active game session is paused and saved (ready to be retrieved through the continue functionality ) when the following events occur
    
    - An incoming call is recieved
    - A softkey is pressed and the screen display changes
    - The red softkey is selected
    - The application is exited and the user does not quit the current game section.

    I have hideNotfiy() pausing the game but i need to handle whats requested in the extract above on Series40.


    Brian

  14. #14
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113
    I have hideNotfiy() pausing the game but i need to handle whats requested in the extract above on Series40.

    Well.. my game saves almost instantly, it takes much less than a second to save. Definitely less time that it takes message or call alert to disappear. That's why I stick to the most simple approach

    Your save might be same fast. I store much more than 19 variables. My typical save is more than a kilobyte

  15. #15
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395
    An incoming call on a Series 40 doesn't destroy the app, so hideNotify() is probably all you get (not even pauseApp(), I think, though you might get this on other phones - a call to pauseApp() is always followed by a call either to startApp() or destroyApp(), so don't do anything in startApp() that will break if it's repeated).

    An incoming SMS does nothing, just beeps. The app carries on running normally.

    Well, this is true on my phone...

Posting Permissions

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