Loading stuff...when should it be done?

Newbie & Debugging Questions
#1

I’m about to have to generalize loading of resources for my 2D sidescroller (both a regular PC-game and an applet-version). I am fortunate enough to have 2 artists making backgrounds and animations for me, and this will result in many images. I’ve done some calculating, and for the basic game with a few different tilesets and about 60 monsters, I’ll be hitting 50-60mb of image-data. I’m wondering which would be the least irritating way of loading these images, while still having a sane memory-footprint, and I was thinking of doing one of 3 things:

  1. Load everything into objects at launch (easy way out)
    Pros: No loading times at all once you’ve started it up
    Cons: High memory usage

  2. Load just the menus at start-up, and then loading level-specific images when starting the level (semi-easy way out)
    Pros: Lower memory usage
    Cons: Load times each time you enter a level

  3. Procedural loading, which loads images in a separate thread, while you’re progressing through the level (hard way)
    Pros: Very low memory usage, and no (visible) load-times
    Cons: Hard to implement; prone for errors; what if the image takes longer to load than we want it to (player is shot through a cannon or something, and moves so fast through the level, that the loading of new things can’t keep up

From a gamer’s viewpoint, obviously the first one would be preferable, and 50-60mb isn’t really that much, but with game-objects and sounds and everything, it might end up being 200mb of memory usage. Is this acceptable?

#2

I really think 200mb is okey. But this wouldn’t really be the proper way :smiley:

The proper way to do this, would be point 2 from your list :slight_smile:
EDIT: IMO ;D

#3

I disagree, option 1 is the best option, also since if you are using OpenGL, textures are stored in VRAM anyway. If the rest of the 200MB is audio…then you have different problems :wink:

Stay well away from Option 3 ;D

#4

You’re very kind to assume I’m using OpenGL, but I’m actually still using Java2D :wink: I don’t find it so slow at all, for my needs. As long as you code with performance in mind from the beginning, it really performs well.
I’m definitely going to try working with lwjgl and libgdx, and possibly some other libraries, before doing any coding on the sequel ^^
I’m trying to do a big project with Java2D, as to really feel why I should have a need for OpenGL. So far I don’t see it, but I hope I will. You could say I’m already seeing it, since I realize none of what I’m doing is taking advantage of the GPU or VRAM, but for my little 2D worlds, I’m havng a hard time seeing why I should change before I hit 3D.

Would number 1 still be a viable option if I’m not using Java2D?

And thanks for the warning about option 3. I was really fearing that one.

#5

Well, different games different methods. You decide really. For relatively small games, I’d just load it in at once. Your audio don’t have to be massive too - look into vorbis (I don’t work a lot with audio, but I’m fairly sure that’s what it’s called). If you end up having too much, and it takes too long you might want to rethink.

Think about how many and how long loading screens you want to offer your players. Program your game without hotswap a few hours, and you’ll notice if the load is unbearable.

#6

Thanks. For now it seems to take about 1 second to load 1 tileset, 1 player and 1 monster. I’m thinking that, as long as I make a loading screen, with info which is about as funny as The Sims, it shouldn’t bother players too much. Personally, I find it much more frustrating to wait each time I enter a map, than to wait a bit when I start the game.

#7

Ideally you should pick option 3, but it would be a challenge to implement and may not be worth the effort for a simple game.

Option 1 is the “worst” choice IMO – having long wait times at the beginning of an online game is a sure way to lose players. Who wants to wait more than a minute just to load a casual web game?

Another idea would be to load only the bare minimum when the game first boots up – so that the user can immediately see the main menu – and then load all of the assets once the user decides to hit “Play.”

#8

Nah… I totally disagree with Option 3.

But that’s only for Level-based systems. I’d propably decide Option 3, if I had only 1 big world map for example, so something like a open-world, when It would actually make sense to limit the stuff loaded, and where there are no seperated “levels”.

If you have Levels, I’d totally go with Option 2, (as already said). That’s because you usually have to load the level itself, I’d just go with loading the assets at the same time. This is what Portal [2], Team Fortress, many other FPS and whatnot does.

But I agree with Mads about Option 1. In case you only have a bit of data to load, it wouldn’t be too bad to just load everything at startup (propably with loading-screen), but since you have 2 artists, and think they would produce a lot of artwork, I think that option could not be the best.

Also, you said you would need 1 second for 1 tileset 1 player and 1 monster. Is that true? Is it really a second, or just a couple of milliseconds? How many pixels are there? What Image format? Cause I’m wondering. This shouldn’t actually take that long.

#9

I like your last remark. You can definitely load something like the main menu, and then let the player set up characters while a different thread loads. This applies to any game, but one might want to ask oneself how much of a necessity fast loading for the particular game is.

Your other lines are making an assumption that I don’t feel is fair. You assume that there is tons and tons of data. In 99% of the games here on JGO, this is not the case. If that is the case, you cant even load all of it because of RAM restriction, and there would be a lot of unnecessary loading.

For one second, you barely even need to inform the player what he is waiting for. If you make a loading screen, you can definitely make people wait ten seconds (enormous amounts of data can be read), and if you make it the sligtest bit interesting (reading, tips, or interactive), you can get away with a lot more loading time!

#10

Like most have said, for smaller games option 1 is much better as you will not be loading gigs worth of textures and 3D models. I use to play a crap load of flash games on kongregate and some games had rather long load times (5-10mins) and thats not including DL time but what I hated most was having to go through a loading screen every time the game changed rooms or something. A one time loading screen with maybe a few sec delay between room transfers would be kiss magnificent.

Option 2 is typical for games and option 3 is like…boy oh boy I don’t think I could ever do that.

#11

Thanks for all the great replies. For now, I don’t know exactly how much data I’m going to end up with, so I’ll go ahead with Option 1, while still considering I have to be able to smoothly go to Option 2 whilst coding. Shouldn’t be too hard with a tilemap and a few backgrounds.

About the 1 second load-time, while merely a quick assumption, it holds true. It’s just 27 images so far, racking up a staggering 41kb. When I added my new backgrounds (240kb), it jumped to 4300ms.
That’s a LOT!

I’m loading them all from my jar-file using something similar to this (placing it in a HashMap for easy reference):
monsterImages.put(“MonsterWalking1”, ImageIO.read(getClass().getResource("/resources/monsterImages/MonsterWalking1.png")));

Is that bad? I thought ImageIO was the way to go. I AM on a crippled laptop, but it does have a dual-core. I don’t get it.

#12

We are making a big 2D sidescroller and were obviously using Option 2
because if that we weren’t really worried about mapchange time
it now is way to long and we have to cut some things and optimize

my point is option 1 is simply not possible, the game would load for an insane amount of time
option 3 is really advanced and hard to do, without lags n stuff.

#13

If you’re not using a sprite atlas… Something about having a bad time.

#14

Yeah, I guess I should get around to that, huh? :slight_smile:
Thing is, I only have a few test-images implemented so far, and I haven’t made sprite-atlases for them.

I must admit I wasn’t really sure why they were so loved and sought after, but I guess this is the reason. Insane load-times with multiple image-loads. I didn’t think it was that big a deal…

But then how can it take 3000ms to load 2 backgroundImages worth 100-140kb each? They’re 1366x768, but gosh darn it that’s a lot of time!

EDIT: I forgot that it reads it in as arrays, so no matter how small the image.size, it will still take up the same space in memory, whether it’s a low-compression jpg or a huge bmp. Silly Catface

#15

They are mostly useful for OpenGL games that aren’t using multi-texturing, texture arrays, or other modern techniques. For these games (e.g. Slick2D games) you can only have one texture bound by OpenGL at a time. Binding a new texture is not free – and binding many textures per frame will cost you. Also, if you’re batching sprites (like in LibGDX or Slick’s VertexArrayRenderer), switching to a new texture requires “flushing” the batch.

For these reasons, at least for an OpenGL game, sprite sheets should really be the first thing you do when optimizing performance, as they can greatly reduce texture binds. A software renderer (Java2D) won’t benefit much from sprite sheets, but since Java2D may take advantage of hardware acceleration under the hood (depending on the platform), it seems like a good idea to use them anyways.

1366x768 is insanely huge and probably unnecessary. Have you thought about using tiles? Or vector graphics? And what do you mean by this:

[quote]I forgot that it reads it in as arrays, so no matter how small the image.size, it will still take up the same space in memory, whether it’s a low-compression jpg or a huge bmp. Silly Catface
[/quote]

#16

[/quote]
Well, for the background I was just thinking of having 2-3 such backgrounds per level side-by-side, that scroll a tiny bit with the player, so you start off the level just viewing the first image, and then veeery slowly you scroll into the second image when moving right. I’m doing parallax-scrolling, so other than that background, there’ll be a layer of clouds and such represented by small images placed around the map in various positions, which move a little faster than the background, also relative to the player.

What I meant, was that if I load an image, whether it’s a bmp of 4mb or the same image compressed as a jpg, it’ll have just as many pixels representing it when loaded to memory, right?

#17

Not sure if this would work but maybe lower the resolution of your background images keeping the aspect ratio of your game in check as well. Then scale them when you render. This would cost more cpu I guess (although I never see a performance hit) but it would lower your loading time and overall memory foot print.

I think the class loader is slower then just getting from a file path that is not part of a class. ImageIO.read(new File(path)); I have no proof and have not tested it but since I switched to loading from a class, I feel like things are slower.

Also, under the hood, java does a great deal on hardware. If it was all soft-ware rendering we could not get 1/10 the performance we do. The problem is, we have no control over how it is “trying” to get hardware accelerated.

#18

(Small confession - haven’t read thread beyond OP)

I load everything at startup. But then I’ve only got assets that number in the tens of megabytes.

Cas :slight_smile:

#19

I have just this suggestion:

Take the easiest path. Once it’s clear, the easiest path is not sufficient, take the next step.

On one hand, it’s nice to have the resources to do a deep analysis of the problem and know everything in advance, like the amount of resources that will be needed.
On the other hand, I presonally, don’t belive in this kind of system.
It is just not possible for the specifications and for the numbers not to change while building the system. Just not possible… maybe in NASA…
The software evolves and some parts need to be refactored or rewritten anyway.

So take the easier path, it just might be enough.

#20

Fixed by weirdness!

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?!

When I port from applet to fullscreen application, putting all my resources in folders next to the .exe instead of in the jar-file, I’ll see if it changes the load-time. The original plan was to launch it as an applet, but since then we’ve decided to do a regular full-screen game.