Preloading Graphics

Java 2D
#1

I did a bit of testing with Java and its ability to draw different graphics on the screen. I used the BufferStrategy example that Jeff has posted many times before (the one in his shooter). In the main thread’s loop, I made many images fly and bounce accross the screen. These images varied in size and shape. With 100’s of images on the screen, I didn’t notice any slowdown- this was even with a rotating image (using code found in Abuse’s 4k shooter- from a post depicting a bug in java 1.5 with rotating images- see below link). There wasn’t any slowdown assuming that the graphics had already been preloaded-That is, before the main thread was started, these 100’s of images had been stored in memory one way or another.

I am developing a type of scroller game that requires many images on the screen at once. Rather than develop a method of pre-loading images (this could be a huge strain on memory), is there a fast and reliable way of drawing images that I could do on the fly? For example, ten seconds into the first level of the scroller, monster B shows up- monster B’s graphics are stored and loaded the instant monster B is spawned. The alternative to this would be to load monster B’s graphics at the start of the level. However, what if I have 100’s of monsters? What if there are 45 variations on monster B? What if monster B has 60 different frames of sprites to animate? Pre-loading all of these images seems clunky and inefficient.

If this is not possible to do these on the fly, is there a better method to “pre-load” images than to store them all in a vector/array type object? Perhaps level one requires that monster A, B, and C’s graphics need to be preloaded- Is there a way I can do so without the need to keep reference to these images. Does the virtual machine keep track of which image files have been loaded so the next time they’re used it is done faster? Even moreso, is there a way that I can specify to load images in video memory rather somewhere else? (Worst case is I cannot load images on the fly, so perhaps they can be stored in VMem.)

When creating rotations of an image, one method is to have Java store each possible angle as another image object. (see http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=2D;action=display;num=1076627809) for code reference.) How processor intense is this code? Would it be too much to request the virtual machine to create and rotate an image on the fly depending on where a certain object (monster) is looking? If these image rotations need to be preloaded as well, this only inflates the already huge pre-load buffer. I don’t want to have to create and store 360 image objects for every possible angle my monster could be looking. Not to mention, if that monster had 30 unique frames of idle animation, that’s 30 * 360 images to store! It would make more sense to do such on the fly, however, I do not have the environment created to test this situation under computational stress. Has anyone had experience in this with care to speed?

I appreciate any help you guys could give me. I’m not asking for a handout- rather conceptual goals. Perhaps I can chat one on one with somebody about my full design path to see if I’m on the right track? Bear in mind that this is my first venture into Java gaming. Right now I am trying to conceptualize how I am to code everything. It makes more sense to get important ideas such as image loading out of the way before they become an issue. Sure I can create simple cliche Java game with two slow moving monsters on the screen- but that is not my goal. It would be silly to travel down an inefficient coding path directed at such an example only to have my “image loading methods” not work as fast when I want to have more than 2 monsters on the screen. Perhaps I am expecting too much of Java to have 10-20 monsters flying around the screen, flashing lights, blaring sounds, and 30 or so bullets flying at a speedy player-controlled ship? (See the game Cho Ren Sha 68k for an example of my intended gameplay.)

#2

Conceptually, preloading is is strategy for any media-intense presentation. Years ago, I developed multimedia CD-Roms when a 4x CD-Rom was fast. The techniques are universal: if you do anything that takes time, you either let the user know it’s happening by telling them with some sort of “Loading…” message or progress bar, or you try to sneak it in when they won’t notice, a little bit at a time while the program has idle time.

My opinion is that it’s simplest to have logical breaks in your game/presentation when you want this to occur. Even AAA games have pauses in between levels to dump the stuff that isn’t needed anymore and load the new level/monster/audio/etc. So in your scroller game, maybe you set up key breaks when the character reaches a flag or special spot. Play a little temporary animation, music loop for a few seconds, or do something else to entertain the player (or just a progress bar for simplicity) and load in your next set of data.

Even if you can preload the entire game into RAM at the start, will you always want to do that? Is it likely that the player will reach the 500th monster without a single pause? So preloading hundreds of MB of stuff at the start, even if possible, might be unnecessary. Maybe you do your dumping/loading every time the player dies. If you know that he’s already gotten past Monsters A and B, you could dump those out and load two new ones when the player dies and you get a few seconds of pause. As long as you keep ahead of the player based on predictions of what is coming next, you can keep a workable buffer of “stuff.” If the player does catch up and you need to pause, design breaks in the game like I mentioned above. Some sort of mid-level song & dance to give you a chance to clean up and get ready the next wave. If you really can’t predict what the player will encounter (in a giant game level, for example, where the player could go anywhere and the monsters are not confined to regions) and you don’t want a pause, you might need to preload everything that is possible for the player to get to.

#3

Stanky is right. Unless you want to build an elaborate loading buffer of sorts, you will probably notice when you try and load images in the middle of playing.

In general, it is common practice to pre-load data required for a level or area at the very begining, as this avoids the over head of object creation (and loading) during your main game loop

#4

Thanks guys for your help.

I am aware of the proper media loading strategies. However, I was looking for ways to approach such differently. Your answers seem to suggest that there is no fast way to load media in Java. My question is then, are there fastER ways to load than others?

My current method is at the start of a particular gamestate (It could be a new level or the title screen), determine all objects that will be used. Once a list has been created, I load all media used by those objects into some sort of storage device. (Array, Vector - it doesn’t matter. The point is each media object has a variable to reference it.)

Is there a faster or more memory efficient way to do this?

#5

[quote]Your answers seem to suggest that there is no fast way to load media in Java.
[/quote]
I didn’t make any claims that Java loads media faster or slower than any other application loading a large amount of data from files.

[quote]Perhaps I am expecting too much of Java to have 10-20 monsters flying around the screen, flashing lights, blaring sounds, and 30 or so bullets flying at a speedy player-controlled ship?
[/quote]
Depends how big those monsters are and what your minimum system requirements are, but I don’t think you are asking too much at all.

[quote]My question is then, are there fastER ways to load than others?
[/quote]
I think the general process you described sounds fine: determine what you need, load it into memory. Once it’s in memory, that doesn’t mean you can draw it all to the screen at once, of course.

In my opinion, load time and memory are both less valuable than render time. If you spend a few seconds loading hundreds of files, rotating dozens of images, drawing text to buffered images, and other precalculated graphics operations–as long as all of that effort goes to save you render time when the game is in action and you have to draw the screen in about 0.03 seconds, it was worth it.

#6

Newbie disclaimer - I’m not a coder, I don’t code professionally, in fact you may grit your teeth to find out what I do for a living. Anyways, you guys are warned. ;D

I’m assuming the idea that a loading screen is necessary is because the process is blocking because it’s busy doing io. Therefore, when you go to the ‘next stage,’ the game does all the IO before the gameplaying stage to keep the game playing pace, err playable.

If you try to callup IO to load up MonsterSpriteA into your game every time MonsterA is walking into your screen, you will always receive a ‘hiccup’ in the gamepace right before the monster strolls onscreen, and everybody will find that annoying (and predictable). The smaller the file, the smaller the hiccup. (are my assumptions correct?)

However, how about if you use a different thread to make IO calls, and have the thread pass over the object whenever it is good and ready? That way, your gamethread can keep playing along, and not worry about blocking due to IO. The downside to this is, that you can’t have that thread make the calls on the fly, because it will still take time for that new thread to grab the image. What would probably end up resulting is that the game thread simply shows ‘nothing’, or rather, an invisible object pummelling you and you having no idea why, because the other thread is still loading the sprite. Or null pointer crashing (more or less, but you get the idea)

However, if you can ‘foreshadow’ the coming of the sprite, such as a tree graphic or whatnot, then you could have it loading up in your thread while you were walking over there, so by the time you get to the tree, the img will be loaded and will display it correctly.

This would be real handy for online games, where users can upload their custom sprites (avatars?) to the server, and upload it on the fly to clients that need to view it. Almost like a… browser with game rules. :stuck_out_tongue:

So, the real trick is not how you can load images, but rather when you can load the images. If it’s like a zelda clone, where you can walk to a different part of town, if you know that you are within a certain distance to that unique looking tree, start grabbing the tree image so that by the time you get there, the tree will render on screen. Should you do it when you are one screen width’s away from the tree? How fast does the screen scroll towards the three? How much time can you afford to loading time?

I’ve been thinking about a very very simple graphic mud client with display of 320*240 (think Old School Nintendo graphics), storing most of the graphics locally, downloading changes on the fly when necessary like a browser cache (small screen real estate helps my situation). The reasoning is that I could get rid of the idea of zones, and have the whole world in one big giant map, and the main loading time for the majority of the files would only be when you start up the game.

That’s the gist, apologies if this whole post offers no real value. Oh yeah, and is it possible to devote a seperate thread to disk IO like stated above in the first place?

#7

The problem isn’t the time it takes to read a file. It also needs CPU power for the reading itself (w/o DMA it could be quite alot), for decrunching and for allocating ram.

Also you won’t need 360 rotation steps. 32 should look ok-ish (you can also just mirror half of em the time you blit em onto screen). Another option would be using opengl, you would also get nice filtering that way (for free). With 1.5b2 (an the nice opengl pipeline) you also could get rotations accelerated within java2d.

Usually you’ll just need to do it how Stanky said. Load everything you need now (eg for this level/room), , and then you just load the stuff you need now… etc :slight_smile:

Just look at Q3 - most levels (together with all textures, geometry, models, sounds, physics, weapons whatsoever) fit nicely into 64mb. Can you really create enough content for making streaming a senseful option? (If you know Ikaruga - it’s only about 18mb [the whole game with everything including music]).

#8

Ikaruga’s that small?! I guess I didn’t notice since my ISO is bundled with Border Down (Dreamcast version).

Given that this is my first venture into game programming, I am finding it a bit difficult to grasp certain concepts. My teachings have heavilly been gartered towards code efficiency and readability, so anything remotely wastefull throws red flags in my face. Hell, I used to think doublebuffering was a horrid way to draw- I figure making a ‘copy’ of the ‘screen’ was inefficient since I’ve already got a working ‘screen’ already. The same goes with preloading. I figure that too many programs are written with the idea of having infinate memory. I’d rather write something more processor intense and require a beefier system than write something which requires a user to sit there while his hard drive thrashes with the page file. But, it looks like that I don’t have that luxury and thus, I must preload- however inefficient my mind thinks it is.

#9

Hey Funk. It may make you feel better to keep in mind that you are trading space efficiency for time efficiency. :slight_smile:

#10

space costs only as much as RAM costs (pretty cheap ;D), but time is priceless :wink:

#11

Yep, it’s really that small. All textures and graphics in general have only the needed resolution. It just doesnt make any sense to use 512x512 textures for a thing wich is only about 32x32 pixels. As a sideeffect the textures looks much sharper (because they dont need to be downsampled that much).

Also the music is produced with DC’s soundchip, therefore it isn’t much bigger then midis (but it sounds much better). The GC version of Ikaruga actually uses recorded DC music (haha).

You may asking yourself why they (Treasure) made it that small. It’s kinda odd, since the DC CDs (actually they are called GDs) can hold about 1gb. Well, they did so in order to keep the loading times at a minimum.

Btw you usually have two choices, either you make your programm memory efficient or fast (C compiler switches). That rule is usually true. You have to sacrifice some ram in order to get a huge speed adventage (eg caching, preloading etc).