Opened 7 years ago
Closed 5 years ago
#41 closed defect (wontfix)
Safety colors in preview even if disabelt
|Reported by:||HoraK-FDF||Owned by:||pulkomandy|
the bug can be reproduced by:
set Safety_colors = no in the ini
clicking on an image or palette in save/load window will show the the palette with Safety colors in the toolbar palette but after loading its the real palette without Safety colors.
Would a key/key-combination to toggle Safety_colors = yes/no not a nice feature or does that exist already and i overlooked it?
Is it not possible to use the Safety colors internally if needed (or always) and don't ever alter the palette or is that needed for DOS compatibility and the HX extender because it runs in a 256 color mode and needs to copy the palette to an place in memory? I don't know how it works i never looked at the sources.
Change History (4)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Yes, the constraint is still how the entire screen is always 256 colors - it's hard to fit the 4-color menus, the current 256-color image, plus the previewed 256-color image.
The preview is only a preview, in order to check which file is what (not an image browser), so the priority is that the menus stay usable : you don't want the entire screen to become black when you're previewing an image made of 256 black colors.
comment:3 by , 5 years ago
I think this bug should be marked as invalid.
The feature "set Safety_colors = no" is to avoid grafX2 changing colors of the picture loaded.
There is no reason the preview should be changed.
A good feature would be to warn the user in the loading dialog : "safety colors are disabled, loading this image may turn the UI unusable"
But I really don't see any reason to allow safety colors to be disabled in preview !
comment:4 by , 5 years ago
|Status:||new → closed|
Currently, GrafX2 is running in 256-color mode and the screen palette is the same as the picture palette. This is something we inherited from the DOS version.
This restriction has been removed in the SDL2 branch, where we now use a 32 bit screenmode and do the palette things ourselves. SDL2 is accelerated which makes this reasonable. With SDL1 it could be too slow, especially when combined with the fake hardware zoom (double/triple/quad pixels).
So, the plan is to remove that option completely in the long term.