[Solved] Libgdx Bug (hope not)

Newbie & Debugging Questions
#1

I have this (sprites.png)

http://dl.dropbox.com/u/54138920/img/sprites.png

also have this


Texture sprites = new Texture(Gdx.files.internal("res/sprites.png"));
textures.put("ship", new TextureRegion(sprites, 0, 0, 80, 42));
textures.put("missile", new TextureRegion(sprites, 0, 50, 32, 16));

then why I get this?

http://dl.dropbox.com/u/54138920/img/po.jpg

;D
It should be drawing a ship (corret) and a missile, the red one right below ship on sprite map, but the missile won’t. “textures” is just a HashMap. I draw them normally with SpriteBatch. Any tips?

#2

I bet TextureRegion does take the coordinates of both rectangle corners and not top left corner + width and height. At the moment you request a region with negative height (16-50=-34), so you get the region 0,16,32,50 but with the y-coordinates flipped.

To get the correct region for the missile you need to use


textures.put("missile", new TextureRegion(sprites, 0, 50, 32, 66)); // 50 + 16
#3

Gonna try that ;D

#4

Well, not really…

From TextureRegion.java:

        /** @param width The width of the texture region. May be negative to flip the sprite when drawn.
         * @param height The height of the texture region. May be negative to flip the sprite when drawn. */
        public TextureRegion (Texture texture, int x, int y, int width, int height) {
                this.texture = texture;
                setRegion(x, y, width, height);
        }

I work a lot with TextureRegions, and never saw a single bug. What version do you use: a nighlies or a stable?
There are 2 constructors with such arguments, the second one takes floats instead of ints, as u/v/u2/v2 texture coordinates, so be careful to give ints if you want width/height. Just in case you changed your code before putting it here…

#5

Also, it might help to check the code you’re using to draw it with. That seems more likely to be the culprit than what you’re using to load it up.

I’m not familiar with the library, but it seems to me that you might be calling a method that changes the sprite’s region without intending to.

#6

Problem fixed :slight_smile:

three solutions above, all great. But the correct one is UprightPath’s. So I always thought when we construct a TextureRegion, the region was cropped right there. However when I looked the source, TextureRegion class is nothing but just (IMHO) holding link to Texture and 4 params (x, y, w, h). The 4 params have to mentioned again when you draw because I use SpriteBatch’s drawing method that receive boolean to flip (this game is shooter, so need many flips).

Thanks guy!

#7

You might simplify your life by using Sprite (which is the tiniest bit faster too).

#8

Okay I’ll try it. What I like from TextureRegion is split method :slight_smile:

#9

TexturePacker is better. :slight_smile:
http://code.google.com/p/libgdx/wiki/TexturePacker

#10

Thank you very much. Fortunately I haven’t changed the code yet :stuck_out_tongue: However this class looks more complicated.

#11

Guess I’ll stick back to TextureRegion, it’s easier ;D

#12

Sprites are just extended texture regions with utility. Lot simpler.
First you create sprite just like you would do texture region. Then you can set position, size, scale, rotation origin, color, etc.
Drawing is simple as

sprite.draw(spriteBatch);

For textureRegion you have to do all those for yourself and usually that make cluttered rendering code(lots of hoops and branches) or you end up extending texture region and you find that you just made sprite0.2 without all those methods and untested code.

#13

It’s just because I want my entity class to do the logic and render itself according to it. Currently they update themself and draw themself with TextureRegion reference inside them. Ofc Sprite is worth to try.

#14

Then just put the sprite reference inside of that entity.That also give nice logic - render separation.

#15

Sprite merges model (position, rotation, etc) and view (drawing), so if you care about that, it isn’t a good choice. If ReBirth has an entity that holds model data and draws itself, Sprite seems like it would be fine.

#16

Is sprite also good when I use shifting, ie for animation by changing origin X and Y of main spritemap?