oh noes! the cursed switch statement strikes again. Well done for squashing it :)
On Wed, Feb 27, 2008 at 4:54 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > > Brian Fisher wrote: > > On Tue, Feb 26, 2008 at 12:07 PM, Lenard Lindstrom <[EMAIL PROTECTED]> > wrote: > > > >> For both pass and fail I get (0,0,0) --> 0, (255,255,255) --> 127. But > >> sf.unmap_rgb(0x000000ff) is (255,255,255), the same as sf.get_at((8,8)). > >> So the test should always fail. The question now becomes, why does it > pass? > >> > >> > > well if map_rgb returns 127, then the set_at should use 127 cause it > > calls the same SDL mapping func... it may not matter what 0xff unmaps > > to > > > > so what if you print out the contents of the PixelArray before the > > assert that fails? where in the array is the 0x000000ff? how is a > > failing paletted surface different from a passing paletted surface for > > that check? > > > I found the bug and squashed it. The fix is in SVN. A missing break > statement meant the 8 bit case was falling through in the switch > statement to the 16 bit case. > > -- > > > Lenard Lindstrom > <[EMAIL PROTECTED]> > >
