I've gone through the nice tutorial that creates a simple libgdx game catching raindrops in a bucket. I want to learn more about using images, so I tried replacing the raindrop with a baby.
When I try loading baby.png, I get the following error:
com.badlogic.gdx.utils.GdxRuntimeException: Texture width and height must be
powers of two: 60x83
How can I load an image of whatever size I want?
before loading the image write..
Texture.setEnforcePotImages(false);
you may do this in create function of application listner this is the easiest way if you don't want to create a texture atlas
A little reading led me to a description of TextureAtlas and TexturePacker, which combine a bunch of small images into one large one. That makes them faster to load and draw. As Vikalp says, you can also just disable the rule about image sizes if you don't care about the performance difference.
Texture.setEnforcePotImages(false);
You can learn more about game atlases in Udacity's HTML5 game class.
To create your own atlas, you can start by using the TexturePacker GUI, but I recommend eventually creating a command-line project to automatically pack your raw images.
I posted an example project that takes the example code from the bucket and raindrop tutorial, and switches to using a TextureAtlas. Now, I load the atlas and then load the images from the atlas.
atlas = new TextureAtlas(Gdx.files.internal("atlas/plank.pack"));
dropImage = atlas.findRegion("images/baby");
bucketImage = atlas.findRegion("images/bucket");
One bug I found is that the images wouldn't load in the HTML project. I found out that you can work around the bug by putting all your images in a subfolder.
I created a new project to hold the TexturePacker and any unit tests that I want to add later. The texture packer looks like this:
package com.github.donkirkby.plank;
import com.badlogic.gdx.tools.imagepacker.TexturePacker2;
public class PlankPacker {
public static void main (String[] args) throws Exception {
TexturePacker2.process(
"raw-assets", // source folder
"../plank-game-android/assets/atlas", // destination
"plank.pack"); // data file
}
}
You could also put the picture (top-left corner) into an 128x128 textures aswell:
Afaik is the using of non-power-of-two textures slower and takes more VRAM. Due the architecture of an GPU and "slow" handling of texture bindings in OpenGL, it's always recommended to put your images which are used at the same time into one big pow-two texture and grab them as regions of this texture to speed up your app.
The using and grabbing of your texture would look like:
Texture texture = Gdx.files.internal("data/yourtexture.png");
TextureRegion region = new TextureRegion(texture, 0, 0, 60, 83);
For drawing something like this:
batch.draw(region, positionX, positionY);
Related
So how can I store textures within lwjgl so that when I call a texture it does not have to go and open the file to get the texture, as this is time consuming and inefficient.
I am going to be creating an animation and need several images from a texture atlas, so how can I store the first sub pic to a specific term/variable to call later?
I am writing a 2D lunar lander-style game in Java and using the Slick2D library to handle the graphics. I am having a problem handling the background images.
Here is my problem:
I have 3 layers of details to paint on the background behind the spaceship (stars, mountains and land including landing sites). These are repainted each loop as the ship (centre of the screen) moves around.
The images for these layers are 4500 pixels wide by 1440 high. This is mainly to create some sense of variety (stars) and to be sufficiently wide to hold the generated mountains and land (the land includes the landing sites). Mountains and land are generated per turn and are polygons drawn into holding images.
Slick2d (or opengl) is complaining that it cannot handle images of this size - it says it can only handle textures that are 512 x 512 on my development PC. So... if I have been exploring different methods to work around this including:
a. doing polygon clipping in each loop to reduce my polygons (mountains and land) to the displayable screen size (640 x 480), but this seems mathematically challenging, or
b. splitting my layer images into 512x512 tiles and then updating the screen with the tiles, which is an extension of what I already do (wrapping the layers to create an 'infinite' world) so seems more do-able given my abilities.
My first question (or sense-check, really) is am I missing something? My images, although large, are minimal in terms of content, e.g. black background with a few lines on. Is there a way to compress these in Slick2D/opengl or have I missed something to do with settings that means I can make my card handle bigger images? (I'm assuming not, based on what I have read, but hope springs eternal.)
So, assuming I have not missed anything obvious, on to part 2...
As a quick "I might get away with this" workaround, I have reverted to using BufferedImages to hold the layers and then extracting portions of these into Slick2D images and painting these on the screen in each render loop. Doing it this way I am getting about 3 FPS, which is obviously a tad slow for a real-time game.
To create the BufferedImages I am using:
BufferedImage im_stars = new BufferedImage(bWIDTH, bHEIGHT, BufferedImage.TYPE_INT_ARGB);
Graphics2D gr_stars = im_stars.createGraphics();
... and then I draw my content onto them (stars, etc.)
In my render loop a do a bit of maths to work out which chunks of the images I need to display (to cope with wrapping/providing an 'infinite' experience) and then extract the relevant portions of BufferedImage to a Slick2D image(s) as follows:
Image i1_star = Tools.getImage(stars.getStarImg().getSubimage((int) x1, (int) y1, width, height));
g.drawImage(i1_star, 0, 0);
I have written a static helper method to convert my BufferedImage chunk to a Slick2D Image as follows:
protected static Image getImage(BufferedImage bi) {
Image im = null;
try {
im = new Image(BufferedImageUtil.getTexture("", bi));
} catch (IOException ex) {
Logger.getLogger(Tools.class.getName()).log(Level.SEVERE, null, ex);
}
return im;
}
I'm guessing this is a bad way to do things based on the FPS I am getting, although 3 seems very low. I was getting about 25 FPS when I was using code I'd written myself doing the same thing! So, is there an accelerated Slick2D/opengl way to do this that I am missing or am I back to having to either tile my background images or hold them as polygons and develop a polygon clipping routine?
Having done some more research, I have found that my graphics card can support up to 4096 x 4096 pixel images using Slick2D's:
BigImage.getMaxSingleImageSize();
I have reverted to using Slick2D image files with a width no larger than this size in my program and am now getting around 350 FPS so the BufferedImage work-around was definitely a bad idea.
My program packs a series of images and outputs them into an aste.png, and an aste.atlas. My code for packing is as follows:
public void pack(){
System.out.println("Packing should not be ordinarily called! If you did not have explicit intentions of Packing, please check ImageAtlas constructor.");
Settings settings = new Settings();
settings.maxWidth = 512;
settings.maxHeight = 512;
TexturePacker2.process(settings, "E:/Files/Eclipse Projects/StarFighters/StarFighters-android/assets/sprites/" + name,
"E:/Files/Eclipse Projects/StarFighters/StarFighters-android/assets/sprites/", name.substring(0,4));
}
I will not need to pack EVERY time I run the program which is why I can get away with absolute file paths(I'll only pack when I'm running desktop and have added new images), however, I only used absolute file paths because I cannot figure out how to do it otherwise. I am using the android assets folder. (The desktop is linked to the android assets folder) As I am running it from the desktop version, it's trying to goto the desktop path, when I need it to use the assets path, which Gdx.files.internal handles for me. (This problem is not essential to the function of my program)
Once I have packed the images I do as follows:
atlas = new TextureAtlas(Gdx.files.internal("sprites/aste.atlas"));
public Texture getTex(String imgname){
return atlas.findRegion(imgname).getTexture();
}
I pass in "sma_a2" as the imgname when I try and getTex();
my assets/sprites/asteroids directory has the following images:
big_a1.png
big_a2.png
med_a1.png
med_a2.png
sma_a1.png
sma_a2.png
Which were all successfully packed into the aste.png and aste.atlas
My problem is, no matter what fname I pass in the image I receive is the entire aste.png
I also was curious as to why I would use a pack instead of just the images, as I start with images, and then pack them, only to get images again..
Don't call getTexture() on the TextureRegion returned from findRegion.
The whole point of an atlas is that all of the textures you look up in it are in the "same" texture, but at different regions within that texture. This way you can "bind" one large texture in OpenGL (which is somewhat expensive) and then render lots of different pieces out of the texture.
Most of the other APIs in Libgdx that take a Texture should also work with a TextureRegion.
**My solution:**
Using "getTexture" returns the entire image, and texture regions store basically a rectangle which represents the regoin of the packaged image that is the individual image. So, basically drawing TextureRegions isn't much different then drawing Textures, so I just drew the TextureRegion. In my case that involved adding to a superclass, so that it supported Textures, and TextureRegions in subclasses. Subclasses specified whether to use Textures or TextureRegions using a boolean, and different SpriteBatch.draw() methods were called for each.
As for why to use them P.T. posted above as follows:
The whole point of an atlas is that all of the textures you look up in
it are in the "same" texture, but at different regions within that
texture. This way you can "bind" one large texture in OpenGL (which is
somewhat expensive) and then render lots of different pieces out of
the texture.
Most of the other APIs in Libgdx that take a Texture should also work
with a TextureRegion.
So sounds to me like it is more effcient/faster.
Im trying to create a vertical scrolling game that has a level that is 380 X 10000.
When I create the Texture to load the image I get this error:
Caused by: com.badlogic.gdx.utils.GdxRuntimeException: Texture width and height must be powers of two: 380x10000
I know i can get textures that are 512X512 to load fine. So what do i need to do to get this background image to load?
Assets{
public static Texture levels;
public static TextureRegion levelsRegion;
}
Load{
levels = loadTexture("data/levels.png"); <--------- Error occurs here.
levelsRegion = new TextureRegion(background, 0, 0, 380, 10000); <--- Doesnt get to this point
}
WWOOoooo 380x10000?? Are you targeting cellphones?? In case you are using GL 1.1, using GL2.0 will solve your -not power of two- problem. Not quite sure if your device will be able to load that texture!
PS: In case it does, consider splitting your texture anyway. Not all devices are able to load a 10000 pixel wide texture!
Use
Texture.setEnforcePotImages(false)
Then you can load non-square (non power of two long to be precize) images. Although it's very bad idea to load such a big image. Just split it to smaller parts and use them when you need to display them on screen.
For a game I'm making I am storing all the sprites for the map inside one large(er) image. I want to be able to create an instance of Image for each image inside of the larger image that has all the sprites.
So how would I create an instance of Image from a set position of another Image.
The basic solution (if all tiles in your tilesheet have the same size) is to use the getSubimage(xpos, ypos, XSIZE, YSIZE) method from the class BufferedImage.
Otherwise, you'll have to store a set of position and size for all sprites in another file.
Your question is similar to this others one.
Since you are using the java.awt.Image-class i am guessing you are trying to create a reasonable game using AWT? You really should take a look at a different technology like http://en.wikipedia.org/wiki/Java_OpenGL. The problem you ran into (partitioning a sprite-sheet) is typical for a lot of other problems (rotation...) you will run into if you try to develop a game without something like Open-GL.
Considering only the problem at-hand: you can easily solve this in Open-GL by binding the whole sprite-sheet as texture (glBindTexture()) and giving for each glVertex() a glTexCoord2f(), no need to cut-out parts of the sprite-sheet.