Jump to content

  • Log In with Google      Sign In   
  • Create Account


Performance regarding dimensions of a tile in pixels


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 FetDaniel   Members   -  Reputation: 122

Like
0Likes
Like

Posted 06 April 2011 - 06:22 AM

I tried searching but found nothing relevant so here goes.

I've studied some tile sets and many are 16x16, and some are 32x32. I've found some 30x30 also. But my limited findings suggest that there are more tiles that have a size that is base 2. Like 16x16.

This could be from tradition, performance or some other practical use.

The thing is I don't know why people choose a base 2 size. I'd like to know your thoughts.
I'd like to know because I'm making a game in Java that is tilebased but not isometric (as of now).


PS: I'm also looking for good pixelartists for a amateur game. Please message me if you are interested.

Sponsor:

#2 Vectorian   Members   -  Reputation: 109

Like
1Likes
Like

Posted 06 April 2011 - 06:41 AM

When textures are stored on the graphics card, they are upscaled to the closest power-of-two size, so 257x257 becomes a 512x12 sized texture in memory. Also in ye olde times graphics card did not support non-power-of-two texture sizes at all.

There is no penalty whlie drawing the texture for non-standard sizes.



#3 Helicobster   Members   -  Reputation: 195

Like
1Likes
Like

Posted 07 April 2011 - 03:00 AM

When textures are stored on the graphics card, they are upscaled to the closest power-of-two size, so 257x257 becomes a 512x12 sized texture in memory. Also in ye olde times graphics card did not support non-power-of-two texture sizes at all.


Nope - most GPUs these days support non-power-of-two texture sizes. If it supports OpenGL 2.0, it'll support any reasonable resolution you can throw at it.

There is still a slight advantage to power-of-two texture sizes, though. When creating MIP-maps for trilinear-filtered texturing, each level of the MIP-map is half the size of the one before it. If the texture's size is a power of two, then each pixel of each MIP-map level can be made by simply averaging four pixels from the level before it. This 'binning' reduction is easier to optimise, and it gives cleaner & more predictable results than resampling the image. It's usually handled by the GPU, but you can still reasonably expect power-of-two textures to load a little faster, and/or look a little better at a distance.

There's no disadvantage to using power-of-two texture sizes, either, so while it's not necessary at all, it's kinda habitual. Much like if you're selling random stuff in a garage sale, you're more likely to offer things for $5, $20 or $100, than for more arbitrary prices like $7, $23.45 or $102. Round numbers are nice.

#4 FetDaniel   Members   -  Reputation: 122

Like
0Likes
Like

Posted 08 April 2011 - 03:33 AM

When textures are stored on the graphics card, they are upscaled to the closest power-of-two size, so 257x257 becomes a 512x12 sized texture in memory. Also in ye olde times graphics card did not support non-power-of-two texture sizes at all.

There is no penalty whlie drawing the texture for non-standard sizes.





When textures are stored on the graphics card, they are upscaled to the closest power-of-two size, so 257x257 becomes a 512x12 sized texture in memory. Also in ye olde times graphics card did not support non-power-of-two texture sizes at all.


Nope - most GPUs these days support non-power-of-two texture sizes. If it supports OpenGL 2.0, it'll support any reasonable resolution you can throw at it.

There is still a slight advantage to power-of-two texture sizes, though. When creating MIP-maps for trilinear-filtered texturing, each level of the MIP-map is half the size of the one before it. If the texture's size is a power of two, then each pixel of each MIP-map level can be made by simply averaging four pixels from the level before it. This 'binning' reduction is easier to optimise, and it gives cleaner & more predictable results than resampling the image. It's usually handled by the GPU, but you can still reasonably expect power-of-two textures to load a little faster, and/or look a little better at a distance.

There's no disadvantage to using power-of-two texture sizes, either, so while it's not necessary at all, it's kinda habitual. Much like if you're selling random stuff in a garage sale, you're more likely to offer things for $5, $20 or $100, than for more arbitrary prices like $7, $23.45 or $102. Round numbers are nice.


Thank you both for very good and informative answers!

#5 Ravyne   Crossbones+   -  Reputation: 6779

Like
1Likes
Like

Posted 08 April 2011 - 01:08 PM

Data that is a power of two tends to have good properties as it passes through memory, CPU caches and registers -- historically, the reason is that you see power-of-2 in tile engines is that, in their heyday, most tile-engines were not hardware accelerated, and relied on software renderer.

For example, a typical CPU register is 2 (oldschool), 4 (32-bit), 8(64-bit/MMX/3DNow!), 16 (SSE) and now 32 (upcoming AVX instruction set) bytes wide -- so with proper alignment you could pack a ton of pixels into exactly one register, or an even multiple of registers, as pixels passed through the CPU -- which is particularly efficient when you're doing things like transparency, translucency or masking. Cache lines in the L1, L2 and now L3 caches are also powers of two on both CPUs and GPUs, and memory buses transfer data in sizes which are Po2 as well. Then, Po2 also gains you the ability to use bit-shifts and bit-masks in your renderer, instead of multiplying/adding/subtracting these arbitrary numbers that are odd for the CPU to deal with -- particularly in the old days, a shift was *way* faster than a multiply -- but they're only equivalent when you're multiplying by a power of two. In many software renderers there was a "fast-path" for aligned-Po2 blits, and non-Po2 or unaligned blits would fall back, at least partially, to a more-general, slower render path.

I remember back in the day a lot of naive amateur game developers would use odd size-tiles like 25x25 because they wanted to have a single "center" pixel -- and this, of course, destroyed their performance.

Its not required any more, but there are still good reasons for it that are tied to hardware in a way that simply isn't going to go away. Its always going to be easier to make Po2 stuff faster in hardware with less effort -- in other words, making Po2 fast is low-hanging fruit for hardware designers -- so I don't see non-Po2 reaching *absolute* parity.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS