Using disproptionate sprite sheets
well i'm thinking of playing with animation and movement for my (self) game programming studies. but when i want to use sprites they seem "hard" to use. i mean from what i've read when reading in your sprites, they should be the same size, so all you'll have to do is "point" to them in your code and they'll render.
but how are you to do that if they look like this:
"http://www.panelmonkey.org/tg/MrDw_VileX132bit.gif"
will i have to redo the whole sheet and make them (the cells i read they were called) the same size? is there a program that will do such a thing for you?
if any clarification in what i'm trying to do or say is needed, please tell me [smile]
[edit: de-linked image so poster can fix it]
[edit by OP: relinked to see if bandwidth image would come up.
it did not. oh well. it stays de-linked now.]
[Edited by - Alpha_ProgDes on July 5, 2004 10:53:10 PM]
No bugs on gamedev? Oh no, I'd say those _are_ bugs, wasps to be specific. o_O While an interesting image, that is definitely not work safe, so please fix your linkage quickly - wherever you have that image uploaded does not allow direct linking, you need to re-route through a webpage local to that server or put your image somewhere else.
confused......
what exactly is wrong?
what's so harmful about megaman(-esque) sprites?
what exactly is wrong?
what's so harmful about megaman(-esque) sprites?
Nothing is really wrong with the sheet. You can have your cells any size you like, mixing different sizes on a single sheet. The issue with this is that you then need a way of moving through this image (loaded into a surface or texture) to extract the correct animation frame.
If all of your cells are the same size, you can simple move to the next frame of an animation by adding the standard cell width to the current position.
So to move from the current frame to the next, just add 4 pixels.
If your cells are different sizes, you have to somehow store each cell's width (and height for multiple animations) so you know how many pixels you need to move along.
So cell width for frame 1 = 4.
Cell width for frame 2 = 6.
....
So, really, you could use the sheets "as is", but it would make life a lot easier if you standardise their layout.
Steele.
If all of your cells are the same size, you can simple move to the next frame of an animation by adding the standard cell width to the current position.
+--- current framev| 1 | 2 | 3 | 4 ||****|****|****|****| Cell width = 4|****|****|****|****||****|****|****|****| ^next-+So to move from the current frame to the next, just add 4 pixels.
If your cells are different sizes, you have to somehow store each cell's width (and height for multiple animations) so you know how many pixels you need to move along.
+--- current framev| 1 | 2 | 3 | 4 ||****|******|****|****||****|******|****|****||****|******|****|****| ^next-+So cell width for frame 1 = 4.
Cell width for frame 2 = 6.
....
So, really, you could use the sheets "as is", but it would make life a lot easier if you standardise their layout.
Steele.
you could make all of the frames the size of the largest frame by adding more background like black or whatever and mask the extra
A simple method of dealing with uneven sprite sheets is to use border colors.
For example, each sprite will contain a 1-pixel border of a special color. As your loading routine scans the bitmap, when it finds that special color it creates a new tile, sets the upper left corner to that point, and then scans to the right and down. Whenever it encounters that border color, it sets the bottom/rigth bounds. Now, you know exactly the box boundary of your tile. Continue the scan, skipping over the section you just collected. You just repeat this until you can find no more tiles.
For example, each sprite will contain a 1-pixel border of a special color. As your loading routine scans the bitmap, when it finds that special color it creates a new tile, sets the upper left corner to that point, and then scans to the right and down. Whenever it encounters that border color, it sets the bottom/rigth bounds. Now, you know exactly the box boundary of your tile. Continue the scan, skipping over the section you just collected. You just repeat this until you can find no more tiles.
When using borders like wolf said, it helps if their only uneven in one plane, IE, diffrent widths, or heights, not both. Just helps makes things eaiser on the programmer.
Personaly, I like to edit them so their nice and orderly. Saves everyone some headache, especaly if you want to change things later. And if your using "borrowed" graphics, at least you can say you changed them somewhat :)
Personaly, I like to edit them so their nice and orderly. Saves everyone some headache, especaly if you want to change things later. And if your using "borrowed" graphics, at least you can say you changed them somewhat :)
In my current side project, I'm using an .ini file for each sheet of sprites... Basically the .ini has coordinates for each sprite/frame, like "FRAME 32 0 32 64" would mean a frame whose top left corner is at 32,0 and it's 32x64 pixels in size.
Codewise, every time the game loads an image it'll look for a matching .ini (eg. ship.tga -> ship.ini) and if there is one then it sets up a list of frames. If the file doesn't exist then it just makes one frame that's the size of the whole image.
Codewise, every time the game loads an image it'll look for a matching .ini (eg. ship.tga -> ship.ini) and if there is one then it sets up a list of frames. If the file doesn't exist then it just makes one frame that's the size of the whole image.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
