On 21 January 2011 15:21, Claude Heiland-Allen <[email protected]> wrote:
> On 21/01/11 06:58, David Griffiths wrote: > >> On Thu, 2011-01-20 at 22:26 +0100, Kassen wrote: >> >>> Yeah, I think that could be the problem. >>> >> >> Gabor; > The problem is lack of an alpha channel. It's skewed in that way as it's >> expecting 4 bytes per pixel but it's getting 3. >> > > Ah! It looked to me like it could be miss-reporting its dimensions, originally, so this makes perfect sense. Phew. tricky stuff. Cluade; To be more explicit: pixels are contiguous in each row, but there might need > to be gaps between the rows in memory as each row needs to start aligned to > a certain number of bytes. With 4 channels (RGBA) this works fine with the > default alignment of 4, but with 3 channels you'd need a multiple of 4 > pixels in each row otherwise you'd get diagonal weirdness (and potentially a > buffer overflow crash). > > Ok, I follow this, I think. Are you saying that even without alpha channel bytes the image might display as long as it has a certain amount of pixels, as the pixels "get back in sync"? Wouldn't we expect that kind of image to be non-diagonal but instead have odd colours? Also, to summarise; *POT textures are preferred for performance (probably with alpha?) *NPOT textures will work as long as they have a alpha channel. *NPOT textures without alpha should work as long as their dimensions are integer powers of 4. Is that right? I still think I have one texture (terras2) that breaks these rules, though one dimension is indeed a multiple of 4. Maybe one is enough, as long as it's the dimension lines are scanned in? PHEW! Great detective work here! Yours, Kas.
