addresses an issue caused the the inclusion of new updateRGB2PaletteLUT() call when changing palette entries on paletted modes
the underlying issue was caused by the fact that the VDP was not maintaining its own palette on these screen modes, and instead relying on the underlying LUT being essentially incorrect. the LUT not being updated meant that an attempt to translate an incorrect RGB888 colour (as requested by the agon-vdp code) would translate to the new signal colour (in the vdp-gl code)
this revision updates the agon-vdp side palette for all screen modes, thus meaning the updated LUT will operate correctly
this does introduce a new oddity related to duplicate palette entries, which the VDP previously didn’t appear to suffer from. selecting “colour 14” when it has been redefined to be a duplicate of “colour 1” will end up resulting in pixels of “colour 1” now being drawn into the framebuffer. this is “correct”/expected behaviour for fab-gl, but might be unexpected for Agon users. it is however an edge-case that most users should not encounter, and is best addressed at this time through documentation
addresses an issue caused the the inclusion of new
updateRGB2PaletteLUT()call when changing palette entries on paletted modesthe underlying issue was caused by the fact that the VDP was not maintaining its own palette on these screen modes, and instead relying on the underlying LUT being essentially incorrect. the LUT not being updated meant that an attempt to translate an incorrect RGB888 colour (as requested by the agon-vdp code) would translate to the new signal colour (in the vdp-gl code)
this revision updates the agon-vdp side palette for all screen modes, thus meaning the updated LUT will operate correctly
this does introduce a new oddity related to duplicate palette entries, which the VDP previously didn’t appear to suffer from. selecting “colour 14” when it has been redefined to be a duplicate of “colour 1” will end up resulting in pixels of “colour 1” now being drawn into the framebuffer. this is “correct”/expected behaviour for fab-gl, but might be unexpected for Agon users. it is however an edge-case that most users should not encounter, and is best addressed at this time through documentation