Image Loads In IDE But Not When Exported - Creating Referred Library

May 6, 2014

So I am making a basic game and i am loading the images as such :

try {
background = ImageIO.read(new File(res/textures/bg.jpg"));
buildingManager.getButton().setCupcake_normal(ImageIO.read(new File("res/textures/cupcake normal.png")));
buildingManager.getButton().setCupcake_clicked(ImageIO.read(new File("res/textures/cupcake clicked.png")));
} catch (IOException e) {
e.printStackTrace();
}

A lot of sites say i have to add the folder where the folders are in as an class folder. So i did that but i dont get the same icon with the folder. i get this instead : code.PNG

Also i see the images inside the exported jar but they cant be reached, how do i fix this?

View Replies

Software To Display Image On Screen Using Particular Library

Jul 30, 2014

I am writing a piece of software to display an image on the screen using a particular library. The library lets me create an Atlas out of texture file data, to fetch Textures out of the Atlas using the textures' names, and to draw the textures by calling Renderer.draw(texture). It doesn't make a great deal of sense to create more than one of an Atlas or Renderer. I previously designed my code as follows:

public class SystemAssets {
static Atlas atlas;
public static void initializeAtlas(String pathToTextureFiles) {
atlas = new Atlas(pathToTextureFiles);
}
public static Texture getTexture(String textureName) {
return atlas.getTexture(textureName);
}
}

Similarly, I made a TextureRenderer class whose sole purpose is to provide static access to a Renderer. But many people seem to say that opening up a class like this to global access is bad. I cannot think of any better alternative, however. My core update/draw logic currently works something like this:

public class Game extends AbstractGame {
public void init() {
Screen current = new FirstScreen();
TextureRenderer.initialize();

[code]...

Making a Renderer object belong to the Game or Screen class doesn't make much sense to me, as there doesn't seem to really be a 'has-a' relationship between them; it's more of a 'uses-a', so that seems to imply that it would be best to just call Renderer.draw(thing) from outside the class rather than making it a data member. This would make my main code essentially call the various methods in order to get or print some form of data, much like System.out.println(). And of course, making one of the classes a subclass of Renderer makes even less sense. But making data members static for the purpose of global access and using singletons are often cited as 'bad' programming practices. This problem also arises in a lot of other scenarios in my program, ie. when I want to serialize Thing data members like texture filenames; do I put the serializer as a static data member in a class for global access and call it like I would a function, or do I put it in a class? And it seems like the Renderer will have to be initialized at the start of the program, which would take place in the init() method in Game, then be used to draw Textures in the Screen, so it would have to be accessible from both locations.

edit: In case it's suggested to put these in the main class, that's unfortunately going to be difficult without using static variables; the library recommends having the main class creating an Application object, which is essentially a black box that actually does all the work of calling Game's init() and draw() methods (via a Game object passed into its constructor) and looping until the program exits. AbstractGame and Screen are classes supplied by the library, so it doesn't seem like I can easily give Game any data that AbstractGame doesn't specifically ask for.