search

yash-p-amd / grafx2

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

Ugly GUI when loading an 2 color image #215

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?

loading an 1bit image.

What is the expected output? What do you see instead?

expectet is an seeable GUI in this color mode. But i see an mainly black 
GUI where the buttons must be guessed.

What version of GrafX2 are you using? On what operating system?

GrafX2 2.1wip on OpSys-Win98SE

Original issue reported on code.google.com by HoraK-...@web.de on 10 Sep 2009 at 2:22

Attachments:

GoogleCodeExporter commented 8 years ago 
Grafx2 works by using colors from your palette to color the gui. If you don't 
have
them or if you have close colors it uses them instead. It can really muck me up 
when
I'm not expecting it. Perhaps having a default 4 colors implanted into any 
image that
has less than 251 colors? So that gui will stay consistent at least on the lower
color count images, I don't think it's been a problem for me with high color 
counts.

Original comment by thedaemo...@gmail.com on 10 Sep 2009 at 6:24

GoogleCodeExporter commented 8 years ago 
After loading such image, press 'P' (user-settable: 'Open palette') then 
Backspace
(hard-coded) and Grafx2 will add the missing colors to your current palette in 
unused
slots, starting at the end.

Another trick specific to image formats with less than 256 colors: In 
"settings", set
"Clear Pal:NO" : When you'll load such image, the unset palette entries (ex: 2 
to
255) will keep their original colors, so Grafx2 will generally have enough 
colors for
the menus.

Original comment by yrizoud on 10 Sep 2009 at 6:33

GoogleCodeExporter commented 8 years ago 
Hi,

but what is when i must save it back to an 1bit image then i must delete the 
colors 
and i'm back to black :P or? On reentering the load menu the GUI turns back to 
normal but the picture in the background stays the same like shown on the 
attachment 
so at this point he adds the needed colors to the palette, could it not be this 
way 
also outside the menu?

... greetings HoraK-FDF

Original comment by HoraK-...@web.de on 14 Sep 2009 at 12:36

Attachments:

GoogleCodeExporter commented 8 years ago 
For now Grafx2 will always save the full palette anyway. Even if its all black.

Original comment by pulkoma...@gmail.com on 14 Sep 2009 at 1:13

GoogleCodeExporter commented 8 years ago 
so saving an 1bit image/binary image isnt possible with grafx2. Here are some 
links 
witch show some imageformats and what bitdepths they can have maybe someday you 
want 
to add 1bit, 2bit and 4bit support than it could be some help.
http://www.rastermaster.com/RasterMaster%20Java%20manual/WebHelp/apfileformat.ht
m
http://www.eprintdriver.com/help/v5.0/ScreenCapture-Application/DLLAUX/18Summary
.htm

Original comment by HoraK-...@web.de on 15 Sep 2009 at 8:59

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
not only using 2 colours - when i use the zx-spectrum palette, the gui colours 
are
weird as well...

Original comment by nitrofur...@gmail.com on 27 Jan 2010 at 1:20

GoogleCodeExporter commented 8 years ago 
Todo: At end of preview in fileselector, call the same code as in
Set_nice_menu_colors(), to force usable GUI colors. The preview only needs to be
recognizable, not a problem is the palette is not 100% faithful.

Original comment by yrizoud on 2 Feb 2010 at 2:30

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago

Original comment by pulkoma...@gmail.com on 9 Aug 2010 at 9:48

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 1:39

GoogleCodeExporter commented 8 years ago 
In fileselectors: Since r1592 and r1593, the vast majority of cases are fixed : 
the only remaining problem is when previewing an image that uses more than 251 
colors (in the actual 200x160 preview area), and all these are too similar.
About reading images in general: After much hesitations I'm going to follow 
thedaemonofid's suggestion, with a small variant:

The old "Safety colors" setting has the effect that whenever you reduce to 
"less than 4" colors, Grafx2 re-inserts 4 nice GUI colors in unused slots of 
the palette (starting the search from the end) . This setting is ON by default, 
and I think it's unlikely that a user sets it to OFF on purpose.

The change would be that when this setting is ON, in addition to its current 
effect, loading an image that uses 252 colors at most would perform the same 
task.

A power-user who really needs 256 specific colors in his palette can still 
disable this setting.

Original comment by yrizoud on 30 Aug 2010 at 2:37

GoogleCodeExporter commented 8 years ago 
When a palette only has 2 colors; all skins look the best if the 2 dark colors 
of the skin are remapped to the darker palette color and the two brighter 
skincolors remap to the brighter palette color.

(and plz investigate the (corrupted interface colors) problem associated with 
intermediate interface-remapping or lack thereof, when running scripts and 
using the colorscycling menu)

Original comment by annas...@hotmail.com on 31 Aug 2010 at 2:38

GoogleCodeExporter commented 8 years ago 
DawnBringer, Can you elaborate on the two problems you refer ? First time I 
hear of them.

Original comment by yrizoud on 1 Sep 2010 at 9:52

GoogleCodeExporter commented 8 years ago 
#1. Just a suggestion. If you want things to look good in 2 colors see if you 
can force that behaviour.

#2. Basically it seems like the interface-remapping system has changed 
recently: When something changes the palette in Grafx2 appears to wait with the 
interface-remapping until all actions have ended (or do remap comepletely 
incorrect). This means that if you are using colorcycling or running a 
palette-altering script that is still active; you can get horrible 
inteface-color color corruption (Making it impossible to read messageboxes in 
the script f.ex.). (Eh, this is the same problem I've mentioned several times 
in e-mails. I've sent you screengrabs etc. Didn't you see that?)

Original comment by annas...@hotmail.com on 1 Sep 2010 at 12:58

Attachments:

GoogleCodeExporter commented 8 years ago 
Very difficult for us to understand how many different issues you're 
describing, when you give so many variants in the same sentence :(
In your #2, there's something you already reported in a mail: "if a script 
makes big changes in palette, any messagebox() or inputbox() after that will 
show bad colors".
OK, it's a bug, and it has existed forever. Now you start talking of color 
cycling, and I don't see how relevant is that. Is it a second problem ? Can you 
reproduce that color-cycling-specific issue without reproducing the 
setcolor()+messagebox() issue ?

Original comment by yrizoud on 1 Sep 2010 at 4:13

GoogleCodeExporter commented 8 years ago 
#1: Just a suggstion for remapping in 2 color mode: Dark colors dark. Bright 
colors bright. Just that.

#2:
Nope it's a new bug/change. Look at the grabs from rev1528 and the recent 
rev1598. (However I noticed another, most likely related bug, in 1528...the 
colors weren't remapped at all there...it got all black).

When using colorcycling (dragging the slider)it changes the palette without 
remapping the interface, right? Seems like the same problems as with setcolor().

Original comment by annas...@hotmail.com on 1 Sep 2010 at 5:12

Attachments:

GoogleCodeExporter commented 8 years ago 
Original issue is fixed here.
As the comments are too messy, please open more issues if there are other 
problems with the palette.

Original comment by pulkoma...@gmail.com on 18 Feb 2011 at 1:17