JIT / loading time and need of clearing Image cache[SOLVED]

yerbamate

Hello, friends :)

I just found out that the forum is not zoho hosted anymore. Anyway, here's the deal:

I'm creating a simple adventure game, so far so good but, when starting the game, it runs a little slow, I guess due to JIT – please correct me if I'm wrong. Therefore, I want to implement a loading screen before allowing the player to take over the control. I can figure out how to create a loading based in some time interval, but,

is it possible to synchronize the loading time with the time JIT will take to allocate all the content in the memory, compile/etc (don't really know how it works)?

Since it will be different in different machines, I would like to have it done properly, not based in some fixed time. I'm sorry if it has been asked before but, searching the forums, I didn't found the answer. Thank you in advance!

quark

One way to do it is have the game assets load in a separate thread. The main thread would then display the splash / loading screen until the other thread has finished loading.

I suggest you have a look here for information on using threads with Processing.

PhiLho

"I guess due to JIT – please correct me if I'm wrong"

Probably wrong...

The Jit compiler kicks in after a Java program has run for some time, but fully: ie. after the program has did a number of loops, object creations, etc. It will then analyze the code that has ran, and will compile to native code the slowest code, like nested loops and such. It will do this all the time the program runs, inspecting it from bottlenecks.

So, if you just wait some time before running, the Jit just won't do its work...

Beside, I guess the slow start might be because of data loading, like images and such. That's the main bottleneck of an application, in general.

As quark said, you can load these resources, or do your complex init code (eg. pre-computing offline images) in a thread, to keep the interface responsive while using the CPU / I/O.

In a topic of the forum one, we discussed about splash screens, to show some image or even some simple animation, while a job is done in background.

yerbamate

@quark - sounds logic enough, looks like a proper way of doing things. Thank you :) @PhiLho - you may be right - you should earn a prize for being such a helpful person since the last forum! But let me explain further more. My level constructor sets a few vector of objects, each object composed of data such as coordinates, bool isColideable, the sprite and so on - e.g. scenery obstacles When the level starts, all images are already displayed, UI, player controls, everything works but in the first 2~5 seconds the game lags, even with the sprites already loaded. That's why JIT came in my mind. Just to clear another image related question, in the beta releases of Processing 2 we had to clear the image cache after loading an image - not doing so would result in ever growing memory usage until freezing the system. Is it still necessary to clear this cache manualu? Not much of a problem but, since I'm used to it and it mey be an outdated techinique, is always good to be updated about stuff like that. Thank you guys once again!

GoToLoop

Is it still necessary to clear this cache manually?

Even though that was fixed before the stable release, for massive amount of images, it can be necessary yet!

yerbamate

Thanks, GoTo. I see that all the guys/girls from the old forum are still active here :).

dimkir

@yerbamate,

you may find it useful to check your code for "loitering" or "memoy loitering".

This is situation when in your code you don't use certain object anymore (refernce to your GameLevel object or specific PImage), but your java code still has reference to it and thus Garbage Collector cannot clean it from memory.

Let's say that for convenience you use global array of PImages to store all imags in your game.

PImage[] activeGameImages = new PImage[100]; 
int loadedImagesCount = 0;


// when you load your Level 1 of the image, you will load specific graphics
// for that level
String[] level_1_image_files = {"level1_grass.png", level1_sky.png", "level1_boss.png", "...... "};
for( String imageName : level_1_image_files){
    activeGameImages[loadedImagesCount++] = loadImage(imageName);
}

// so now your user is playing Level 1 and obviously he sees those images
// which you display
...
 image(activeGameImages[12], x, y); // level1 boss
...


// now your user progresses to the Level 2
// you need to load images to memory for graphcis in Level 2

//
String[] level_2_image_files = {"level2_ice.png", level2_mountain.png", "level2_boss.png", "level2_dog.png"};
for( String imageName : level_2_image_files){
    // this command will add the images. to the whole active list of images.
    activeGameImages[loadedImagesCount++] = loadImage(imageName);
}

// now your user is playing Level 2, 
// he sees images for level2 : mountains, dog, ice and maybe even grass from level1
...
image(activeGameImages[21],x,y);  // mountains
image(activeGameImages[22],x,y);   // dog
image(activeGameImages[23],x,y);   // ice
image(activeGameImages[10], x, y); // level 1 grass
...
// but he will not see anymore level1_boss.png 

So from this example we can say that PImage containing image data for level_1boss is "loitered". It's loaded in memory. It will not be used anymore, because according to your gameplay Level1 is gone and won't be played anymore.

But it is still referenced from our activeGameImages **array and, because it is refrenced GarbageCollector cannot get rid of it. To make GC understand that you won't use PImage with level1_boss, you need to **nullify the reference:

activeGameImages[12] = null; // this will tell GC that this object is not used anymore.

Lotering becomes harder to detect when you use a lot of object with different lifespans or when you have objects referencing to other objects to other objects. Eg.: you may for example use "level1_grass.png" across all levels of your game. But "level1_boss.png" only in the first level. And usually it happens when there're few dozens of the objects with different life-cycles, sometimes loaded twice from file and so on.