[Fluxus] texture types (was Re: png diagonal oddness)

[Kassen]

On 21 January 2011 15:21, Claude Heiland-Allen <claude at goto10.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20110121/db8b077c/attachment.html>