On Sat, 2005-04-02 at 12:51 +0200, Luca Olivetti wrote: > Luca Olivetti wrote: > > >> Ville's patch also fixes some colours in some pages with the osd > >> teletext plugin, your doesn't (i.e. it seems it can manage more > >> colours on larger areas at once). Pity for the problem after using the > >> yaepg plugin. Yep, that's expected. Before the patch, colors weren't being "freed" in OSD_Close, but were left reserved even though nothing in the OSD was using them any more. That obviously resulted in the whole whopping limit of 16 colors reaching the top sooner than supposed. > > I'm lost now. I'm testing your patch and the femon plugin shows > > correctly with the elchi skin if it's the first one shown, afterwards > > the yaepg plugin doesn't work (all black). Viceversa, if I use the yaepg > > plugin first after a restart it's the one working fine but the femon > > plugin show its texts black with the elchi skin. > > But then, it's the same even without your patch, so it's not making > things worse. Since you're tinkering with the palette stuff, here's something I noticed while looking at Martin's patch: cDxr3PaletteManager::GetIndex() is supposed to return the index of a given color in the current palette. If the given color is not found, it returns 0, which doesn't make sense to me. It should probably return -1 or something that isn't a valid index. The return value of GetIndex() is used in cSPUEncoder::Cmd(), the OSD_SetPalette case in the big switch statement. Now, what should be done there if an invalid index is returned (ie. the color is not found in the current palette) is beyond me. Blindly using the returned 0 which is either the first color in the palette or a nonexistent color seems clearly wrong and will almost certainly cause some "effects"... ideas and especially patches welcome :)
