Will Start Working On Sprites, But...


Jourdy288

Well-Known Member
Joined
Jul 3, 2009
Messages
2,562
Age
29
What is the ideal size in pixels to make 2D sprites? 100x100 maybe?
 
Jourdy288 said:
What is the ideal size in pixels to make 2D sprites? 100x100 maybe?
Try to make them as large as possible if they aren't pixel based. I mean, really: as large as possible. 8000x6000 preferred.

If they ARE pixel based (meaning: they're supposed to look blocky), then it depends on the game how large they should be, but the norm is to use base2-even numbers, like 32x32, 64x64, 128x128, 256x256, 512x512, 1024x1024, 2048x2048 etc. I've also seen combinations of those numbers for non-square sprites like 32x64.

The reason why base2-images are used is that you can use them as OpenGL-textures without wasting pixels (because when you use OpenGL, you have to have base2 sizes for your textures on many graphics cards so if you use non-base2-sizes, you have to use textures that are larger than the images to store them). Also, you can often do some drawing optimizations when the images are base2, so yeah, really no reason why you would use anything else than base2 images.
 
Last edited by a moderator:
This question doesn't make any sense as it stands.

Sprites can be any size from 1 pixel square to larger than the screen of the game you're working on.

Try to reduce the amount of free space around a sprite, as wasted space just takes up memory. So if your total sprite is 24x30 pixels, using a 100x100 sized image is a lot of wasted memory, something like 32x32 would be more appropriate in this example.

Obviously the size of the sprites will depend on the game that requires them.

Also it is a waste of space if you have a basic image that only has small changes in different frames - in this case it's often better just to draw just the changes and place them on top of the basic image. Eg if you have a face and only the eyes move/blink, then don't create 10 face frames, just draw the eyes and place them on top of a face sprite.

Does that make any sense?
 
iprice said:
Also it is a waste of space if you have a basic image that only has small changes in different frames - in this case it's often better just to draw just the changes and place them on top of the basic image. Eg if you have a face and only the eyes move/blink, then don't create 10 face frames, just draw the eyes and place them on top of a face sprite.

Does that make any sense?
Actually, I don't see why you would want to separate the eyes in this case (requiring alpha tests and another pass to draw etc). I would myself just use multiple face sprites, especially if I'm using OpenGL instead of SDL (ugh) since there really isn't a reason why you'd want to optimize small things like that when you have multipass shaders and such that you don't want to run more than necessary.
 
Last edited by a moderator:
Perhaps it's because I come from the 8bit school of computer gaming, that I try to optimise everything in my games - just because you can have huge graphics and textures nowadays doesn't mean that you should. Doesn't make it wrong either, just that many programmers don't optimise code or graphics like they used to - hence increasing file sizes and bloatware. Each to their own. Their are 1001 solutions to every problem :)
 
iprice said:
Perhaps it's because I come from the 8bit school of computer gaming, that I try to optimise everything in my games - just because you can have huge graphics and textures nowadays doesn't mean that you should. Doesn't make it wrong either, just that many programmers don't optimise code or graphics like they used to - hence increasing file sizes and bloatware. Each to their own. Their are 1001 solutions to every problem :)
No you got my point wrong -- "optimizations" in this case would require more cycles than what you'd need if you'd just have multiple images (alpha testing, blending, custom shaders get messed up because of overdraws etc). Well, unless the face is 1024x1024 and the eyes 3x3 or something.
 
Last edited by a moderator:
Chances are that it would be more efficient if you're using color-keyed transparency. I'm pretty sure that SDL can handle that with no issues; doubt GL can though.
 
BTW Jourdy, I don't think we've seen any of your work. Would you mind uploading some to show us?
 
OK, here's the GIF of one I made by modifying a picture of a dendrite:

1177528.jpg
 
Jourdy288 said:
OK, here's the GIF of one I made by modifying a picture of a dendrite:

1177528.jpg
I think that we'll need a little more than that to be able to make any decisions. A portfolio would be nice! :)
 
Last edited by a moderator:
I a couple hundred fish sprites, but lost them :(

I'll keep working on sprites though, I'll show you good ones soon enough :)
 
Sphinxter said:
Dude, SVG.
What do you use to create those? I think I saw there was a gimp plugin for .svg, but I don't know if there's a free app out there that's better suited to the task.

Edit: Inkscape I guess?
 
Last edited by a moderator:
Lunatic said:
Sphinxter said:
Dude, SVG.
What do you use to create those? I think I saw there was a gimp plugin for .svg, but I don't know if there's a free app out there that's better suited to the task.
I'm using GIMP, this was before I knew better for SVG.. but I'll look into that plugin, thanks.
 
Last edited by a moderator:
iprice said:
There's an online bitmap to vector image utiltity here - http://vectormagic.com/home

I've used it in the past and got respectable results, considering.
Yes, I even own a "pro" copy of it, but the results you get by using it are often very chaotic. You get 28-layered SVGs for example, or shapes that look right but are implemented in a too complex way (a square might be implemented using 16 bezier vertices instead of just 4 normal corner vertices).

And why create something using pixels first just to then vectorize it? Don't see the point, especially since it's simpler to create a vector image than a rasterized image imho.
 
Last edited by a moderator:
I don't use vectors normally and I wanted to create a smoother version of a scaled sprite, which is why I used it. It did the job.

I'm not a graphics artist by any stretch of the imagination, but I can get by, so tools like this are of use to me sometimes.
 
dflemstr said:
iprice said:
Also it is a waste of space if you have a basic image that only has small changes in different frames - in this case it's often better just to draw just the changes and place them on top of the basic image. Eg if you have a face and only the eyes move/blink, then don't create 10 face frames, just draw the eyes and place them on top of a face sprite.

Does that make any sense?
Actually, I don't see why you would want to separate the eyes in this case (requiring alpha tests and another pass to draw etc). I would myself just use multiple face sprites, especially if I'm using OpenGL instead of SDL (ugh) since there really isn't a reason why you'd want to optimize small things like that when you have multipass shaders and such that you don't want to run more than necessary.

You would separate eye, mouth, hair stand animation, etc. and overlay it because it saves a ton of memory. And you don't have an image the same size as the face with just the eyes on it, you have a rectangle just slightly larger than the eyes themselves. And there won't be a lot of alpha tests if the sprites are RLE encoded; you'll just draw the pixels of the eye sprite that have information in them. Also if you have sprites broken up like face, eyes, and mouth, then you can combine different mouth animation with different eye animation, without having to store every possible combination as a full face sprite.

All of this is assuming of course that you are dealing with larger sprites, like portrait sprites.

Cheers,
Michael
 
Last edited by a moderator:
Back
Top