Slowdive's Little Daily Blog

[youngneil1]

Great, just pushed it . If it's ok, I will go with 7.1 for the time being (happy here that everything is up & running ).

[slowdive]

That's perfectly fine. I have many versions of Android SDK on my machine and may already have the 7.1 SDK.

[youngneil1]

Thank you - if this causes trouble, please give me a heads up and I will find a way to integrate the 8.0.

I am looking into

Code: Select all

public SKBitmap GetFromBitmapList(string fileNameWithOutExt)

right now (from IBx) for learning purposes and understanding how to use the resources more efficiently.

Conncerning this one here,

A check is made in the platform specific code to see if the device is running out of memory allowed for this app and clear the bitmap list as need.

,
where can I find the memory threshold for clearing the bitmap list, please (or generally the platform specific code for doing so)?

[slowdive]

It is not in IBx or IBbasic yet. I have it in the IBmini that is on Google play. I'll post the code from my Android studio code base for that app when I get home for you to see.

[youngneil1]

Awesome, I was just curious how it is done. I think in normal IB I will ponder a bit about resource usage, too (especially load on demand for areas and - then separated - encounters, maybe convos too). Areas will have to be, at least with a part of the info contained, all in memory at the same time due to world time driven movers requirements (the routines go through all areas iirc). I may need to remember details there and adjust quite a bit of code. Info from neighbouring areas will be needed for the seamless world system, too.

[slowdive]

I believe that area, encounter, and conversation objects should take up very little memory. It is just the load time that is annoying on mobile devices. Bitmaps on the other hand do take up lots of memory and should be shed when needed. What I do is check the device's current memory use for the app allocation compared to the maximum that an app can use. When it gets close to maxing out then clear the bitmaps list.

[slowdive]

Here is what I've used in Android (located in the MainActivity.java):

Code: Select all

/**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that was raised.
     */
    public void onTrimMemory(int level)
    {
        String info = "::" + Build.MANUFACTURER + ":" + Build.MODEL;
        // Determine which lifecycle or system event was raised.
        switch (level)
        {

            case ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN:

                /*
                   Release any UI objects that currently hold memory.

                   The user interface has moved to the background.
                */
                //Toast.makeText(this, "TRIM_MEMORY_UI_HIDDEN", Toast.LENGTH_SHORT).show();
                mGameView.cc.commonBitmapList.clear();
                mGameView.cc.tileGDIBitmapList.clear();
                break;

            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE:
                //Toast.makeText(this, "TRIM_MEMORY_RUNNING_MODERATE", Toast.LENGTH_SHORT).show();
                break;

            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW:
                //Toast.makeText(this, "TRIM_MEMORY_RUNNING_LOW", Toast.LENGTH_SHORT).show();
                mGameView.cc.commonBitmapList.clear();
                mGameView.cc.tileGDIBitmapList.clear();
                break;

            case ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL:

                /*
                   Release any memory that your app doesn't need to run.

                   The device is running low on memory while the app is running.
                   The event raised indicates the severity of the memory-related event.
                   If the event is TRIM_MEMORY_RUNNING_CRITICAL, then the system will
                   begin killing background processes.
                */
                //Toast.makeText(this, "TRIM_MEMORY_RUNNING_CRITICAL", Toast.LENGTH_SHORT).show();
                mGameView.cc.commonBitmapList.clear();
                mGameView.cc.tileGDIBitmapList.clear();
                break;

            case ComponentCallbacks2.TRIM_MEMORY_BACKGROUND:
                //Toast.makeText(this, "TRIM_MEMORY_BACKGROUND", Toast.LENGTH_SHORT).show();
                mGameView.cc.commonBitmapList.clear();
                mGameView.cc.tileGDIBitmapList.clear();
                break;

            case ComponentCallbacks2.TRIM_MEMORY_MODERATE:
                //Toast.makeText(this, "TRIM_MEMORY_MODERATE", Toast.LENGTH_SHORT).show();
                break;

            case ComponentCallbacks2.TRIM_MEMORY_COMPLETE:

                /*
                   Release as much memory as the process can.

                   The app is on the LRU list and the system is running low on memory.
                   The event raised indicates where the app sits within the LRU list.
                   If the event is TRIM_MEMORY_COMPLETE, the process will be one of
                   the first to be terminated.
                */
                //Toast.makeText(this, "TRIM_MEMORY_COMPLETE", Toast.LENGTH_SHORT).show();
                mGameView.cc.commonBitmapList.clear();
                mGameView.cc.tileGDIBitmapList.clear();
                break;

            default:
                /*
                  Release any non-critical data structures.

                  The app received an unrecognized memory level value
                  from the system. Treat this as a generic low-memory message.
                */
                break;
        }
    }


[youngneil1]

That's very insightful to see . Very nice that memory level warning events exist and that the code can react to different levels of severity.

The reaction is always a full wipe of the bitmap list(s). When comparing this to current IB (which is inferior as it does not work with memory itself , but just with number of bitmaps in list), one difference is that IB currently tries to avoid the full wipe by regularly removing only a part of the bitmaps in the list (those added first, bottom of stack). The goal is to keep the memory imprint of the bitmaps at a comfortable level all of the time, never reaching the wipe zone (well, at least rarely). I imagine (and that might very well be wrong) that after wipe a reload of lots of bitmaps will be neccessary, potentially pausing the game for quite a bit. Furthermore, another assumption is that nearing high memory usage the game gets slower, so the goal is to avoid this also (by deleting enough bitmaps regularly). Now, by deleting from bottom of the stack the chance increases that bitmaps not needed right now will be deleted first (from map sections long behind the party). Obviously, this not true all the time but just an increased chance. The amount of regularly deleted bitmaps gets the more aggressive, the higher the memory usage is in IB.

The drawback of all of this in IB is 1) all the assumptions might be wrong and not much is gained and 2) the constant deletion and reload of bitmaps is affecting perfomance actually worse than the big swipes.

Still, it might be worth to experiment a bit with the idea of not fully wiping at the lower, less critcal levels of memory usage, but to only do a partial deletion there (ideally from button of stack). Now, another problem is that the IBx bitmap list contains all the graphics, not only tiles. This makes the bottom of stack assumption much less helpful.

Anyhow and for whatever it's worth, this is the IB code doing what I describe above:

Code: Select all

 if (gv.mod.loadedTileBitmaps.Count > 400)
                {
                    try
                    {
                        foreach (Bitmap bm in gv.mod.loadedTileBitmaps)
                        {
                            bm.Dispose();
                        }

                        //these two lists keep an exact order so each bitmap stored in one corrsponds with a name in the other
                        gv.mod.loadedTileBitmaps.Clear();
                        gv.mod.loadedTileBitmapsNames.Clear();
                    }
                    catch
                    {

                    }

                }

                if (gv.mod.loadedTileBitmaps.Count > 250)
                {
                    int cullNumber = ((gv.mod.loadedTileBitmaps.Count / 10) + 2);
                    try
                    {
                        if (gv.mod.loadedTileBitmaps != null)
                        {
                            for (int i = 0; i < cullNumber; i++)
                            {
                                gv.mod.loadedTileBitmaps[i].Dispose();
                                gv.mod.loadedTileBitmaps.RemoveAt(i);
                                gv.mod.loadedTileBitmapsNames.RemoveAt(i);

                            }

                        }
                        //these two lists keep an exact order so each bitmap stored in one corresponds with a name in the other
                    }
                    catch
                    {
                        //addLogText("red", "caught error");
                    }

[slowdive]

From my experience when doing some tests a long time ago on android, loading a json file and deserializing it is very slow. Loading a bitmap is very fast. So if the Bitmap list has been emptied, only the bitmaps currently needed for the current screen will be loaded and that will likely be so fast that the user will not notice it. This emptying of the bitmap list would be a rare occurance from what I have experienced in the Android IBmini app (the app tracks the number of times a device triggers one of the memory events and they have been rare...mostly really old or cheap devices with 512MB or less of RAM) It would be similar to the first time entering the mainmap and loading all the new tiles shown on the screen which happens very quickly. Again, my experience is that loading all the areas, conversations, and encounters one at a time and deserializing them is an excruciatingly slow process so that is the main thing I want to fix as far as loading stuff goes. I think the OnDemand loading of areas, convos, and encounters should fix this.

[youngneil1]

Alright, it is good to hear your first hand experience there. It is a relief that the bitmaps can be loaded so swiftly .

I think I wil turn my attention again to either continuing the documentation or try to get some fresh stuff in (point distribution based character creation, cool down time for traits and maybe spells, voice over option for dialogues, walk animations for all our gliding creatures and props, idle animations...). Choices, choices ...

But first I will have a great time with Let's go down to Dungeon Town !