I swear I once saw a human horde member with powers similar to Rio Blast once, but I can't find a picture of him now. If anyone has pictures of the lesser known members of the Horde, for example, the three guys that appeared on MOTU in the sorcerous origin story, that would help, or even any other odd members of the horde. I plan on adding more to the Horde sprite sheet and when It's finished I will post it. Im working on jsut about every MOTU/POP character I can think of, but just thought I would put these up for now. (for a game about exploration or relaxation you can make the character on screen small so you can display a lot of the background and surrounding area, for a 1 on 1 fighting game you can have intense close up focussing on the characters themselves, for a platformer you will always want to make sure enough of the level is visible so that the player can quickly see the path they want to take instead of having leap-of-faith type moments or potentially missing the correct route, etc.I don't know if there are any other spriters out there on the board, but thought I would share what I'm working on with you guys. This is much better than choosing an arbitrary size.Įven though you can make pretty much any game with 16x16 graphics, having proportional sizing is a lot better and engaging. Using this you can then measure the size of the box you drew and base your sprites on that size. You'll want to be thinking about how much background you are showing and how many characters can fit on screen at one time and draw the box accordingly. Or just draw a mock-up on a scrap of paper and try to copy the sizing from that. Regarding actual useful information: I would suggest you open a canvas at the size of your games window and just draw a rectangle at about the size that you think would be best for what you want.
the full image on your hard drive not the individual elements/sprites on the image) you may want to make sure they are not going to be so wastefully padded like in my example.Īlso I believe most cards only accept texture sizes up to 2048 or 4096. Tl dr: sprite size doesn't matter but for large sprite sheets/bg images (i.e. your graphics cards in-built memory) not the computer's memory and is generally between 128MB and 1024MB (but even 128MB can hold 170 512x512 bitmaps so perhaps worrying about size at all is just being pedantic). For an example a 1025x1025 background image would be memory padded to 2048x2048, whilst just shrinking it by 1 pixel in both dimensions would lose pretty much nothing at all and would require no padding- as for that difference in memory requirements:(1025x1025x3 col channels = 3MB in texture memory, 2048x2048x3 colour channels = 12MB in texture memory) but images below 512x512 aren't worth worrying about because the difference in texture memory by today's standards are not even worth thinking about although as I've kept mentioning this is texture memory (i.e. So yeah technically the image size (i.e full spritesheet or background image -not individual sprites-) may matter if you are using really low level stuff or using huge non power of two images may be padded up to the next PO2 dimensions (or I could be wrong), which will just waste a bit of memory. I'd guess the higher level API's do this automagically for you.
It is graphics card & driver dependant, some ONLY support power of two textures (1,2,4,8,16,32,64,128,256,512,1024.) which will mean the graphics will not even show up, more modern graphics cards should be fine although I think it may cause a very minor, almost insignificant, slowdown.īumping up the images to the next PO2 dimensions in the app immediately after the image has loaded is an easy one-off task which is pretty much negligible in terms of performance, this should mean the textures should work on all graphics cards. * While individual sprite size is irrelevant the size of the full image loaded to texture memory might not be. However with high level APIs like SDL, Allegro and the like (basically any library which you can just call a draw image function) you don't even have to worry about it at all. That isn't necessarily technically true when working in low level APIs like openGL* (well for the whole image/spritesheet, not individual sprites). Since technical limitations don't dictate sprite dimensions anymore