| Re: [AD] tests on OS X (was Re: SF.net SVN: alleg:[15387] allegro/branches/5.1/src/opengl) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sat, 25 Feb 2012 09:34:40 +1100
Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > It fails here as well. I just ran it and copied to
> > http://allegro5.org/tests.py
> >
> > http://alleg.de/tests/run%20on%202012-02-24%2000:30osx/test_out.txt
> > http://alleg.de/tests/run%20on%202012-02-24%2000:30osx/test%20pieslice%20%5Bhw%5D.png
> > http://alleg.de/tests/run%20on%202012-02-24%2000:30osx/test%20pieslice%20%5Bsw%5D.png
> >
> > Not sure why it fails, the only difference is that in software mode
> > a pixel is missing.
>
> I see another pixel difference near the top left of the green slice.
>
> BTW, a way to check differences is to load two images as separate
> layers in the Gimp (or something) and use a Difference blender.
> Grain extract seems to work even better.
>
I think the software version is wrong in any case. SiegeLord: Any idea
why the pixel is missing?
> >
> > http://alleg.de/tests/run%20on%202012-02-24%2000:30osx/test%20texture%2015b%20RGB_555%20%5Bsw%5D.png
> > http://alleg.de/tests/run%20on%202012-02-24%2000:30osx/test%20texture%2015b%20RGB_555%20%5Bhw%5D.png
>
> Perhaps something to do with GL_ALPHA_BIAS?
>
Indeed. I changed the 1 to 0.999 which makes it work :(
> > http://alleg.de/tests/run%20on%202012-02-24%2000:30osx/test%20bmp%20indexed%20%5Bsw%5D.png
> > http://alleg.de/tests/run%20on%202012-02-24%2000:30osx/test%20bmp%20indexed%20%5Bhw%5D.png
>
> Missing implementation of ALLEGRO_KEEP_INDEX.
>
It doesn't look like NSImage has any palette support at all. [1] We
could always get a CGImage from it and see if it somehow retains the
palette image into it... but for now it's much easier to just use
libpng :P
Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> On 24 Feb 2012, at 23:34 , Peter Wang wrote:
> > Ugh, try changing the lines in the OS X native image loader from:
> >
> > r *= 255 / a;
> >
> > to
> >
> > r = r * a / 255;
> >
> > like the other loaders have.
>
> OS X loads images with pre-multiplied alpha, if I remember correctly.
> This used to be not the way Allegro stored bitmaps, and so the alpha
> channel was divided out. If that's no longer needed, just leave the
> data as is.
I changed it to: r = r * 255 / a which improves accuracy a lot,
obviously. It's still not pixel exact the same - some precision always
gets lost (e.g. if a is 1 then the only possible values for r are 0 and
1 instead of any value from 0 to 255 with libpng). But Apple seems to
premultiply the components quite early on, possibly already in
NSImage *image = [[NSImage alloc] initWithData:nsdata];
At least my (not very thorough) attempts to extract the raw rgba values
failed. So for now the solution would be to use libpng.
> >
> > http://alleg.de/tests/run%20on%202012-02-24%2000:30osx/test%20blend%20add%20src_one%20%5Bsw%5D.png
> > http://alleg.de/tests/run%20on%202012-02-24%2000:30osx/test%20blend%20add%20src_one%20%5Bhw%5D.png
>
> Possibly the same problem with the alpha channel.
>
It was loading of green.png with ALLEGRO_NO_PREMULTIPLIED_ALPHA. Why
are we using that flag so much in the tests?
[1]
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/nsimage_Class/Reference/Reference.html