Understanding Deployment Frameworks - Reading from a JAR File
(Page 3 of 4 )
A Java archive (JAR) file is simply a compressed zip file containing all the code and multimedia files that you need for your game. It greatly reduces the amount of time that is required to launch your applet because players can download the game in a single HTTP request.
Before JAR files, one of the techniques developers used to reduce applet download times was to copy all the images to a single file. As shown in Figure 2-1, the individual smaller images would be located at different positions in the larger combined image in the form of a grid or a strip. Coordinate data and custom code was then used to cut out rectangles of image data from the different positions within the combined image once downloaded. Fortunately with JAR files today, such additional code is no longer necessary. You can access the individual images simply by opening them by their unique file names and directory paths relative to the archive root. If you have a sprite set that comes to you as a single image, you probably want to crop it into smaller images using an image editor before deployment. If for some reason you do need to crop smaller images from a larger image during run time, you can use the static methodcrop()in classImageLibof packagecom.croftsoft.core.awt.imagefor that purpose.
Figure 2-1. Ari Feldman’s “1945” Sprite set. Artwork copyright 2002, 2003 by Ari Feldman.
Another pre-JAR complication Java applet developers used to have to deal with was writing code to delay using an image until it was completely downloaded. In the early days of the Web, Internet connections were so slow that browsers would display incomplete image data as it was downloading so users could get a sense of what was coming and decide whether it was worth the wait. Applet developers that did not want to use an image until it was entirely loaded used the classjava.awt.MediaTrackerto track the progress of the download. This was especially important as HTTP requests were less reliable back then and sometimes requests to download images would fail completely. If game programmers did not track this, game players would occasionally be frustrated by playing shoot-em-up against enemy sprites that had the unfair advantage of invisibility due to a bad Internet connection.
Fortunately the necessity to program all that tracking, stalling, and download request reattempt logic goes away when you simply include your multimedia files in the same JAR file as your code. When you take this approach, you know your game code is guaranteed to load your images reliably and quickly without needing to resort to special precautions. If by chance your images do fail to download successfully, you cannot do much about it, as your code probably did not download either because it was in the same package.
One of the catches to placing all your image and other resource files within a JAR file is that you need to access these files using the java.lang.ClassLoader getResource()method. TheClassLoader reference that you use for this purpose must come from a class that is in the same JAR file as the resource file you are trying to access. This is because classes loaded from different JAR files are assigned their own
ClassLoaders. The path and file name argument to thegetResource()method is then relative to the root of the JAR file that is associated with that instance of theClassLoader.
URL imageURL
= getClass ( ).getClassLoader ( ).getResource ( imageFilename );
Image image = ImageIO.read ( imageURL );
Note that the object returned fromgetResource()is an instance of the classURLinstead ofFile. Here is another example that uses aURLto access the data:
URL bangAudioURL = getClass ( ).getClassLoader ()
.getResource ( BANG_AUDIO_FILENAME );
AudioClip bangAudioClip = Applet.newAudioClip ( bangAudioURL );
Another trick to this is that your path and file name argument to thegetResource()method, although relative to the root of the JAR archive, must not be preceded by a leading forward slash (/) to indicate the root directory. For example,media/dodger/bang.wavwould work but/media/dodger/bang.wavwould not. This is different from using thegetResource()method to pull files from the hard drive outside of the JAR file.
Next: Upgrading Clients with the Plug-In >>
More Java Articles
More By Apress Publishing
|
 This article is excerpted from chapter two of Advanced Java Game Programming, written by David Wallace Croft (Apress; ISBN: 1590591232). Check it out today at your favorite bookstore. Buy this book now.
|
|
