[java] progress bar while loading ressources

I have never actually used the GF4J but I''d say likely not. Its either FINISHED or NOTFINISHED. You would have to write your own loader code to give back progress. Or make the initial connection, read approximate size through header and count bytes received so far. But thats halfway to loading it yourself.

You could always have an idle animation running, or maybe a progress bar that goes down after it gets to the end. Ok that would just be annoying...

most likly the answer is no. when using such helper functions to load images you would need to be able to supply a callback (or ovverride a particular udateprogress() member function) in order to update the progress bar on screen. you could override the file read functions so that they give you status data. so when you open files you can call your own update progress bar funtion then call the original parent function for normal file handling. this is untested though should work (i have done such things using OOP with c++, and the same theory should apply to java unless its broken in some way).

you could always split the bmp into smaller bmps. the show the progess of each bmp. you could even take all the smaller bmps and blit them to a single large one again if need be. if you choose this route you should do it like follows:
1. create a large bmp
2. for all bmps:
2a. display "Loading Image X"
2b. load image
2c. blit image to correct loaction on large bmp
2d. "unload" image
by doing this you will limit ram requirments. though i feel you should keep the image stored in a split fashion and try to use a tiled barchground vs a songle large image if possible.

be warned i never used the gf4j lib nor have do i do much java coding. this is theory and should be applicable for nearly all langauges (OOP and non OOP alike, how ever function overriding is more difficult in non OOP langauges unless the lib allows you to do this thourgh some specilized fuctions).

Thank you very much for your ideas.

The animation:
The idea of the animation seems a simple and easy half-solution. But since the app runs on blitting basis, nothing will happen until the whole bitmap is loaded. To draw and blit while loadind i''ll need to research a little with threads and the organisation will be a little more complex.

The callback:
I''m afraid i can''t override the bitmap loading method. The code source isn''t accessible. And even if i could, i don''t know how i could do.
How to know how many bytes are already transfered from a file into memory ?
The idea of a callback is nice but i''ve no idea how to implement it. I and may have no possibility to do it.

The bitmap splitting:
Hmm... maybe the simpliest and most interesting way.
For accuracy, i''ll explain the situation more precisely:
The big bitmap is in fact the background map of the game, which can be go from 1000x1000 to about 5000x5000 (arbitrary).
this bmp (currently) is generated by a routine using a data file. the routine can be changed to split the bmp, this shouldn''t be a problem.
The questions now: in how much parts should it be splitted, what tile size ? Should it be 100x100 tiles, 1000x1000 tiles, what''s optimal?
Is it better to let the tiles separeted in the memory or to reconstruct the big one after loading ?
Do i gain any processing time when i call paint("part of the big") instead calling several times paint("smaller tile")?
Or do i not have to matter about this because it has very few influances on ressources and performances ?


But thanks already.