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.

/** @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. */publicTextureRegion (Texturetexture, intx, inty, intwidth, intheight) {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...

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).

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

1

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.

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.

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.

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

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.

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

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org