×

Discussion Board

Results 1 to 5 of 5
  1. #1
    Registered User
    Join Date
    Mar 2004
    Posts
    18

    g3d material.duplicate fails on 6630

    I'm currently developing a g3d based game for a wide range of handset. I'm using the 6630 as my base development platform as it's fast and quite reliable. So far I've had no problems untill today. Suddenly I get a ClassCast Exception when I'm trying to duplicate a Material.

    The code is something like:

    Material duplicateMaterial=(Material)existingMaterial.duplicate();

    My first hunch was that it was related to memory issues, but I had to rule this out because the exception only occured when I did NOT load my sky dome texture, which is 256x256 pixels..

    A collegue of mine suggested that I should try to insert a sleep before duplicating the material, which actually solved the problem. This would be a really ugly and unreliable solution in my oppinion!.. Not the way to go.

    The exception does NOT occur in the DP2 beta emulator, but only on the 6630 (havn't tested on any other Nokia handsets as they are not to my avail at the moment).. I tested the application on a competing handset with g3d support, which didn't fail with the ClassCastException.

    The material I'm trying to duplicate is loaded at the application startup, where as the duplicate it self is not executed before the application enters the main game loop (i.e. selects start game from the menu).

    Anyone had any expirience with this bizarre problem?

  2. #2
    Registered User
    Join Date
    Mar 2004
    Posts
    18
    Hmm... This is EXREEMLY wierd...

    It tried to do an instanceof Material to see what type of object the Material.duplicate() metode returned in the cases where it fails...

    Look like this:

    public Material material[]; // Defined and set when constucting the mesh.. This works.. The mesh is shown correctly when rendered.

    Object3D newMaterial=material[i].duplicate();

    Main.errorTest="duplicate material - "+newMaterial;

    if(newMaterial!=null) {
    if(newMaterial instanceof Material) {
    copy.material[i]=(Material)newMaterial;

    Main.errorTest="Create copy 2m6 ("+i+")";

    copy.appearance[i].setMaterial(copy.material[i]);
    }
    else
    Main.alert("instanceof Material failed!");
    }
    else
    Main.alert("duplicate Material is null!");


    The main alert outputs the string to an alertbox and includes the errorTest string too. In cases where the check fails, the original material is set instead of the copy, so the mesh can be rendered to screen afterwards.

    Anyway.. When testing this code I can actually see what object I'm trying to cast to a Material object. To my surprise I've just had it come back with a TriangleStripArray object instead of a Material object... ??.. How's this possible when I'm doing a duplicate() of a material...

    I don't get it!

  3. #3
    Registered User
    Join Date
    Mar 2004
    Posts
    18
    You guys at Nokia migth wanna look into this as a potential implementation bug.

    If I constuct my own Material object and set the properties from the source material object (i.e. newMat.setShinyness(sourceMat.getShinyness()) etc. etc.) it obviously doesn't fail...

    Actually I first thought that the source material was locked or something, but that didn't seem to be it...

    Anyway, if you need more info on this feel free to contact me.. I think my email is listed in my profile, otherwise look at www.kiloo.com for contact info.

  4. #4
    Nokia Developer Expert
    Join Date
    Mar 2003
    Posts
    2
    Which SW version does your phone have? (*#0000# to find out.) This sounds like a bug we've encountered with early 6630 versions.

    The bug is not in M3G itself, but rather M3G exposes a flaw within the Java VM that is very unlikely to be encountered any other way. To make a long story short, it is possible for certain internal state to get corrupted when repeatedly creating and destroying M3G objects, in the extreme case with results like yours. This usually requires either lots of objects, or very bad luck; I'm not sure which one is the case here. :-)

    As far as workarounds go, avoiding unnecessary garbage collection by reusing objects instead should go a long way. Calling System.gc() before duplicating may also help in some cases. Unfortunately, I don't think either one is a waterproof solution, but they should make it a very rare case in practice.

    I believe this issue has been fixed in later 6630's, and shouldn't concern any phones more recent than that at all.

    -kr

  5. #5
    Registered User
    Join Date
    Mar 2004
    Posts
    18
    The firmware version of my 6630 is:

    V 3.45.113
    04-01-05
    RM-1

Posting Permissions

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