Obscure sprite dimensions

Started by
5 comments, last by Turd Burger 15 years, 5 months ago
Hi, apologies if this is already covered elsewhere - I dug around but couldn't find anything. 2D sprites are generally confined to a pixel height/width dimension that is a power of 2. 2x2, 4x4, 8x8, 16x16, 32x32, 64x64, 128x128 etc... Now, I'm fairly sure that this little rule came about as the result of some piece of graphics-relevant hardware only understanding those particular numbers. Given what you might know about what today's average computer is capable of (graphics wise etc...), could someone answer whether or not it is still neccessary to adhere to these dimensions when creating a sprite for use in a game or programme? Also, does the answer to this question differ if said game is tile based or non-tile based? EG: Could a game using 64x64 tiles accomodate a 76x30 animated character, and feasibley work hitch free on an even below average computer platform? Can anyone shead any light?
Advertisement
Quote:Original post by Turd Burger
Given what you might know about what today's average computer is capable of (graphics wise etc...), could someone answer whether or not it is still neccessary to adhere to these dimensions when creating a sprite for use in a game or programme?
It depends very heavily on your target hardware. From experience, ATI cards from even a couple of years ago take a huge performance hit from non-power-of-two textures. Recent high-end cards should have no problems, but cheap integrated GPUs may still have problems with them.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

There's no reason these days to stick with power of two for sprites and tiles, all it does is place arbitrary (and annoying) restrictions on your art (and artists). For 2d you'll want to pack multiple sprites into larger sprite sheets or texture atlases anyway to avoid texture switching, so you should be able to pack sprites of any size into your sheets without any additional work.

Sprite sheets may be created at design time, compile time or at run time depending on your needs and what works for you.
Hmmm...

Your stances on this seem to be opposing each other.

To address both opinions with one solution, would I perhaps just be better off using larger power-of-two sprites?

EG: I want to use a 76x30 sprite, but the smallest thing available (as a square) is 128x128, so I use that.

Is this a cop-out? or a healthy alternative?

Also, how do modern games, graphics and hardware cope with sprites that are a different size to the tiles in a tile based game?

Thanks for your help.
Quote:Original post by Turd Burger
Hmmm...

Your stances on this seem to be opposing each other.

Not really, swiftcoder says you should stick to power-of-two textures, and I suggest you should pack multiple sprites into a few larger textures to avoid texture switching. You can make your large sprite sheets power-of-two (I tend to use 1024x1024) and pack all sorts of oddly shaped sprites (10x20, 1x40, 45x72, etc. etc.) into it.
Quote:Original post by OrangyTang
Quote:Original post by Turd Burger
Your stances on this seem to be opposing each other.

Not really, swiftcoder says you should stick to power-of-two textures, and I suggest you should pack multiple sprites into a few larger textures to avoid texture switching. You can make your large sprite sheets power-of-two (I tend to use 1024x1024) and pack all sorts of oddly shaped sprites (10x20, 1x40, 45x72, etc. etc.) into it.
Right, this is the approach I use currently. If you use Pyglet, the loading code automatically packs sprites into larger textures for you, which saves a lot of time during development.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Ah, sorry.

I'm no programmer - just a pixel pusher, and wasn't asking from a technical point of view - just a logistic one.

I take it that your way, the power-of-two thing rule only need apply to the entire sprite sheet itself then, not the individual images.

This topic is closed to new replies.

Advertisement