search

Searge-DP / grafx2

Automatically exported from code.google.com/p/grafx2
0 stars 0 forks source link

Menu colours are saved in reverse order #433

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Saving an image reverses the order of the menu colours, rulers don't appear on 
black background.

Grafx2 v2.3.1771
Windows

Original issue reported on code.google.com by Ravey1...@gmail.com on 12 Apr 2011 at 7:10

GoogleCodeExporter commented 8 years ago 
Do you mean that you have an image that you load, you reorder the colors at the 
end of palette, save, and next time you reload your reorder is "forgotten" and 
you need to do it again ?
I'm going to guess that you are loading and saving C64 files. These are 
16-color file formats, so any manual tweaking of colors 240-255 is not 
preserved when you save and reload : All palette entries after 15 are 
blackened, and menu colors are written at the end in entries 252-255, always in 
the same default order - which makes color 255 black like color 0, I never 
noticed.
If this is your situation, you'll want to set option "Clear palette = off" and 
"Safety colors = off", to keep your palette changes in colors 16+ when you load 
a file while in Grafx2. Still a problem of losing your customized palette when 
you quit... If you spend some time pixelling C64 pictures, I'd recommend saving 
your custom palette and load it when needed.
Maybe we should provide a facility for this, allow saving 'current palette' as 
the default for any time grafx2 loads a C64 file.
See attached file C64.pal: a custom palette for C64 images. Grid colors are 
224-239 (Set option "Grid XOR color = 224"), while the normal XOR colors (brush 
grab etc) are in 240-255, slighty lighter.

Original comment by yrizoud on 12 Apr 2011 at 10:47

Attachments:

GoogleCodeExporter commented 8 years ago 
I just ran the program and saved NO_NAME.GIF as-is. Even with the default 
palette, the colours are reversed afterwards. The same image viewed in v2.2 has 
the correct palette.

Check the attached images, two skins loaded in both versions (same 
configuration).

Original comment by Ravey1...@gmail.com on 13 Apr 2011 at 10:42

Attachments:

GoogleCodeExporter commented 8 years ago 
Argh sorry, indeed it was a quite old change that was introduced to fix many 
cases of people loading low-colour images (like all blacks except 2 or 3 
colors, etc), making it an impossible mission for the GUI to select readable 
colors.
This behavior is caused by the setting "Safety colors" in options: If it's ON, 
right after loading an image that uses less than 252 colors, Grafx2 will add 
the colors from the current skin in 4 unused slots. I always disable this 
setting, since I know I can always type P (Palette) then Backspace if I ever 
need to do it manually, for example if I accidentally turn the image entirely 
black.
I've just made 2 changes that should help:
1) The colors are now added in reverse order, so in very many cases the XOR of 
black will be white
2) It will not try to add colors if the palette already has them somewhere : 
This way if you manually reorder some colors according to your taste and save, 
Grafx2 will not change the palette on next loading.

Original comment by yrizoud on 13 Apr 2011 at 9:52

GoogleCodeExporter commented 8 years ago 
You can try the following version that should fix the problem:
http://code.google.com/p/grafx2/downloads/detail?name=grafx2-2.3.1775-win32.zip
(You can simply overwrite bin\grafx2.exe)

Note that if you are editing skins, you'll probably want to set Safety colors 
off: the palette of skins serve as the default palette when starting the 
program, in this case you won't want the colors from the skin you're using to 
have an effect on the skin you're editing.

Original comment by yrizoud on 13 Apr 2011 at 10:10

GoogleCodeExporter commented 8 years ago 
Thanks, was a bit of a nitpick, works better now though. :-)

Original comment by Ravey1...@gmail.com on 13 Apr 2011 at 10:30