Ok, got it now, it seems that I have to modify the display's palette, not the display surface to achieve the desired effect. It's odd though, because I was fooling around with swapping the palettes on individual sprites and it seemed to work fine, its only the display surface that has this functionality, but not the display itself.
On Fri, Jul 30, 2010 at 4:08 PM, John Anderson <corporalmust...@gmail.com>wrote: > Hmm, using .setPalette() doesnt seem to help matters, perhaps it has > something to do with the way I've loaded images/ converted them? I've been > using the image loader from the "chimp" tut, maybe theres a flag I need to > set that I havent? The images are loaded from palettized .gifs and then > converted with no arguments to pixel format. > > > On Fri, Jul 30, 2010 at 3:47 PM, John Anderson > <corporalmust...@gmail.com>wrote: > >> ah, thats kind of akward syntax, but I think I can manage if I wrap it >> properly, thanks! >> >> >> On Fri, Jul 30, 2010 at 2:04 PM, Mel Collins <m...@raumkraut.net> wrote: >> >>> On 30 July 2010 19:10, John Anderson <corporalmust...@gmail.com> wrote: >>> > it seems that if I change the colours in the main palette (the display >>> > surface palette), all the sprites onscreen, rather than staying in >>> > their respective indicies on the palette, shift to the closest colour >>> > on the palette to their original colours. >>> >>> IIRC this is the behaviour when you use .set_palette_at(). To keep >>> the same indices, thus changing the colours, you need to use >>> .set_palette() to replace the entire palette at once. >>> I seem to remember having the same problem while trying to >>> procedurally generate some graphics. >>> >>> - Mel C >>> >> >> >
