Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  How to use character images?  (Read 658 times)
0 Members and 1 Guest are viewing this topic.
Offline kutucuk

Senior Devvie


Medals: 5
Exp: 3 years



« Posted 2013-04-14 05:15:25 »

Well, I don't even know what they are called But please look at this image first: http://opengameart.org/sites/default/files/TikiBoss.PNG
The image is from GravityGames, at http://opengameart.org/content/tiki-chomp-rpg-style

Anyway, I was looking for some images to practice, because I am tired of trying to animate my own bizarre drawings (One of my animations was a red rectangle, then a red circle, then blue ones Cheesy )
So I decided to look for some character images to animate. By the way, I started to learn LibGDX, and its basics were more simple for me to grasp when it came to image drawing than Java2D to me, surprisingly.
I was expecting to find 4-5 image files of the same character with different parts of the motion (One has one foot up, the other has the other foot up etc). But I found images like this one.

I know we are supposed to use TextureAtlas or something like that for our images, but I always combined the images into a single png myself (like the one in the link). And libGDX provided me a pack file for easy management. Then I can get TextureRegions with their names easily.

These don't come with one of those.

So, I want to ask, how do we use these?
Do we just crop the image and make 4 image files and combine them again (I was about to do so, but seemed idiotic)?
Or do we calculate the x and y location, height and weight of the image and draw it? (Like, the first image is 12x12, then the for the second, I have to draw the bits betwen 13-24 x, and 12 y, and in the second line it will be 12 x and 13-24 y)

What is the approach if I don't have a .pack file like I have when I use TexturePacker with libgdx?
Online Phased
« Reply #1 - Posted 2013-04-14 05:18:01 »

LibGDX should have a animator class, just read up about it, I don't know much about LibGDX but I am sure it has one.
Offline kutucuk

Senior Devvie


Medals: 5
Exp: 3 years



« Reply #2 - Posted 2013-04-14 05:32:34 »

I looked into it, and there is one approach: Assume all the images has the same height and weight (which might be, but not in this one) and also assume that all of the images are aligned, then calculate the height and weight of every region containing the character.

So, if I have 400x400 image with 16 characters (8/8), if it is aligned, then I would get the first image height and weight (400/8 is x etc).

But look at the example: 7th row would be a pain. You can process the first 3, then 4th, but the others are tough. Because a calculation like 400/8 won't bring them.
What would your approach be to this?

I am not asking anything specific to libgdx, I just want to know how you guys process these images.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline coltonoscopy

Junior Devvie


Medals: 2



« Reply #3 - Posted 2013-04-14 08:57:33 »

The image you're referring to is called a "sprite sheet" and is used fairly ubiquitously in terms of 2D game animation. libgdx does offer the TextureAtlas option, and in a situation where you wanted to dissect an existing sprite sheet that hasn't been "packed", you would more than likely have to piece it apart image by image using a tool like GIMP to repack the image and turn it into a TextureAtlas. This is how you would go about using it the "libgdx" way, at least as far as my present experience has shown. Otherwise, you could just go about dissecting the sprite sheet at runtime based on the dimensions of each image (i.e., make a Texture that is 24 x 16 for one image and another Texture that's 26 x 16 for another, etc.). Assuming all of the images have the same height and width is fine if you design your sprite sheet this way, and indeed, you see a lot of sprite sheets that have consistent dimensions, but the sprite sheet shown here has some sprites that are differently sized. This has in-game repercussions as well in terms of collision detection, but this is fairly easy if you use box-based collision detection that depends on the size of the sprite to begin with. Dissecting the sheet into separate images and creating the TextureAtlas would probably be easier and the route I would take, if just a little bit tedious, but it's up to you.

Straight flippin.
Offline kutucuk

Senior Devvie


Medals: 5
Exp: 3 years



« Reply #4 - Posted 2013-04-14 18:11:47 »

For now I decided not to use that one. I have to start from simpler stuff. I found another sprite sheet and all of the images have same size. I just did math there (This: TextureRegion.split(ship, ship.getWidth() / 4, ship.getHeight())Wink
It works well.

What I thought at first is what you suggest to me, coltonoscopy. Although I told that it sounded stupid, I fail to come up with a wiser one (Calculating the tile dimensions is more stupid than this if the dimensions are not equal).

I guess I could use them easier if I crop the images and pack it using TexturePacker. Of course because this is just a practice project, I went with an easier sprite sheet this time Smiley
BTW, I liked the sprite sheet notion Cheesy

But still, I would like to learn other approaches to these kind of situations Smiley
Offline Zhon

Junior Devvie


Medals: 4



« Reply #5 - Posted 2013-04-15 02:03:51 »

In libGDX I just use:

spritebatch.draw(your_texture, posX, posY, srcX, srcY, endX, endY);

src X and Y = the points to start the "clipping" region.
end X and Y = are the ending points to the clipping region.

lwjgl:
1  
2  
3  
4  
glTexCoord2f(scrX/W, srcY/H)         vertex...top_left
glTexCoord2f((srcX+endX)/W, srcY/H)      vertex...top_right
glTexCoord2f((srcX+endX)/W, (srcY+endY)/H)   vertex...bottom_right
glTexCoord2f((srcX)/W, (srcY+endY)/H)      vertex...bottom_left

W and H are the dimensions of your spritesheet.

Probably unhelpful, I guess your problems is related to something else..
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (38 views)
2014-12-15 09:26:44

Mr.CodeIt (31 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (99 views)
2014-12-08 04:46:31

JscottyBieshaar (60 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (38 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!