You can also try using Matthias’ pure java decoders to see if those improve load times.
Are you sure JPG is the best solution? Every time you save a JPG you are losing information and making it more “lossy” i.e. lower quality. Many users will be able to spot JPG artifacts, and it will make your game look much less professional. PNG/GIF/TGA may also be more efficient to load than JPG, depending on the situation.
Yeah, I usually only use PNG for that reason. I guess he forgot to save them as PNG.
I’ll take a look at that texture-loader. Thanks 
EDIT: Since I’m using Java2D for all of this, I’ll hold on to that link until I start work on the sequel using lwjgl
[/quote]
I believe it is faster to load one big image than ten small, even if its not because of texture binding.
As long as you show a nice loading screen (maybe even with a progress bar), some loading time is just fine. With such a small amount of resources (anything < 100MB on 1GB+ machines should hardly be a problem) loading everything at the start (option 1) gives by far the best user experience IMHO.
Overall option 2 just multiplies the total loading time for the user (because you’d have to load the same resources over and over again), and option 3 is frickin hard to get right (usually will result in stuttering and other horrors or just crash the game due to some complex bug).
So option 1 has my vote ;D I find this relatively easy to implement using game states: make loading resources a separate game state that runs before everything else. I think you may also need some resource manager that can load and hold all resources at the start and make them available to game components when needed (e.g. something like http://slick.cokeandcode.com/wiki/doku.php?id=resource_manager_tutorial).
P.s. consider using Slick (http://slick.cokeandcode.com/) if you find that the game runs too slow after all. It’s quite easy to get started with and gives good performance.
Good luck!
[quote]Well, I tried what you said about resizing the images and scaling them once loaded (not every render! I hope that was a brainfart ^^). This cut the load-time to 1/10!! Which made me very suspicious… I opened the image my artist sent me, saved it as a new jpg with the original resolution, and ended up with a file almost the same size as the original.
This new file, however, loads 8 times faster than with the original background!!! There must be some extra information hiding in the version he sent me. Perhaps he hasn’t flattened the image, so all the layer-data was still in it. I’ll ask him.
WTF?!
[/quote]
Yeah I meant after you load them and yes, you can save things at very high quality (especially with photoshop) which really bloats the files.
I dont think you can save layer information in jpg. I would also try using png and saving things at a lightly lower quality. It is what I do and you lose very little detail if you do it right.
I totally agree. For me JPG is a no-go. I’ve never used JPG backgrounds in games before, and I think I wont use them. He is right about how the user thinks about your game, if he spots JPG artifacts.
Also, better try out a lower compression for (in case you use them) your PNG’s. I’ve heard it around the TMW (The mana world) wikis, that saving PNG’s with commpression grade “6”.
This only applies on GIMP2-users and only if you use PNG. The guy on the TMW-forum tried various compression grades for PNG-Images and found out that using compression grade “6” (in gimp) seemed to give the best ratio between loading time and file size. I am sure there are different compression options in other Image editors too, so you could try these out.
I thought PNG was supposed to be lossless.
Eh. yes it is… You can still compress something, even if it should be lossless.
Oh… well… That’s peculiar. Photoshop doesn’t let you choose.
Really? omg… I just googled it and it seems to be true 
I just found this forum question on google: http://newsgroup.xnview.com/viewtopic.php?t=4101
Just another guy confirming, that compression level 6 would be the best.
Oh, and I always thought such compression levels only apply on gimp…
And finally, if your artists are using Photoshop it looks like photoshop automatically saves png’s with compression level 6 by default, so my suggestion wouldn’t help you…
How cheeky! I might consider changing, then. Is there any reason I shouldn’t just use 9 compression?
If you use photoshop you know that when you create a new file or image you get a lot of options. Your choice will greatly effect the size of files and what not.
Resolution and color mode are the big ones. There are more options with advanced but I don’t really use that much.
Can’t say that this is in my place to give advice seeing as I’m sort of a newb myself, but I for one believe that unless you’re not concerned with the memory consumption at all, I would suggest option 2. I actually asked a similar question in the past.
You could make a class meant for loading resources upon request. For instance, in my project, I wrote something along the lines of…
(Keep in mind that I’m programming with Slick2D)
public class Resources
{
HashMap images; // Cached images
String imageLoc; // Folder for images
public Resources()
{
images = new HashMap<String, Image>();
imageLoc = "res/images/";
}
public void getImage(String fileName
{
// Checks for image in cache...
Image image = images.get(fileName);
// If the image was not found in cache...
if(image == null)
{
// Tries to load the image using the file name given, and caches it
try
{
image = new Image(imageLoc + fileName);
images.put(fileName, image);
}
// Fails to load the image... what a sad day...
catch (SlickException e)
{
e.printStackTrace();
}
}
// Gimmeh mah image!
return image;
}
public void release()
{
// All resources are released to save memory
}
}
This code is untested, but it demonstrates the helpfulness of hash maps in some instances. Dunno if this will be useful to you, but I just felt like posting it. I always prefer to make many hash maps for different types of resources, and make a few methods for retrieving the resources like the one above. I also make load methods which load a requested resource while returning nothing serving only as a lightweight version of the get methods.
P.S. Sorry for the sloppyness
Greater compression may lead to smaller file size, but also much greater load times.
Before changing the compression strength, you should be thinking about other more significant parameters: indexed colours, bit depth, transparency, etc.
Here’s a couple handy tools for optimizing PNG/JPG/etc:
http://trimage.org/
Unfortunately, these tools may “over-compress” images – meaning the file size is small, but the loading (decompression) time is longer than usual. Because of this, you might be better off saving the images yourself, choosing the right parameters and compression settings with Gimp/Photoshop.
Thanks for all these great replies, guys! I’ll be doing my own testing around with my PNGs to see how it works for me. I have a debugger set up so I can see how many nano-seconds I’m allowed to sleep each update, and a load-time calculation for the images, so I should be able to muster up some results. Probably a good idea to test both on my laptop (Geforce 525M) and my desktop (Geforce 9600GT; yep, still holds it’s own in newer games ^^).
This post should help you with Java2D in general.
This post should explain the whole roadmap with Java gaming and your eventual migration to OpenGL.
Good luck!
I prefer OP’s 2nd option. Don’t split the load time. Let the user starts a game and they could go make a coffee, ice skating, chopping some wood, p**ping, or slapping a bear before they experience the smooth gameplay.
EDIT: option 1 I meant.
??? option 2 was splitting the load-time, so it loads levels at the start of each level ?!?