[npp 0.5.4] text color issue

**nppangband** · February 27, 2012, 17:31

I do have several regular players that use a mac, but this is the first report of an issue of this nature.

Under options ('='), there is an option to edit colors. Have the actual colors been altered? Or is it just using the wrong ones for output?

**ghengiz** · February 27, 2012, 18:23

Originally posted by nppangband

I do have several regular players that use a mac, but this is the first report of an issue of this nature.

Under options ('='), there is an option to edit colors. Have the actual colors been altered? Or is it just using the wrong ones for output?

Just the output. I dumped the colors to a file, and the entry for "white" is 0xFF 0xFF oxFF, as expected.
BTW, I cannot use the cursor keys to change the colors. They work fine in the other menus and in the map screen.
I also tried to change the terminal colorscheme, and different terminals as well, but to no avail...
I attach a savefile, just in case some useful info is stored in it.

edit: in the edit colors screen, the should-be white is displayed in orange.
what test would you like I do now?
The previous version (0.5.3) and any other variant I tried don't behave so : puzzled:
I attach two png images, one is how I see the map, the other is the edit color menu

edit2:
I tried and open the savefile on npp 0.5.3, but it doesn't work, due to too many new terrain feature

The executable is too big to attached. If you are a mac user on lion 64 bit who wishes to volunteer and try it, please contact me via pm, I'll send it via email

Attached Files

501.Franco.zip (4.6 KB, 293 views)

**nppangband** · February 27, 2012, 21:04

It looks like all of the shades are scrambled. I wonder if shades.pref is even being loaded. The second row of colors should be white, the thrid lrow should be shades of slate, the 4th orange, and the 5th red, etc.....

In your NPPAngband directory, the in the *npp/lib/pref folder, there is a file called pref.prf. If you don't mind, please try inserting this line into that tile somewhere. It probably doesn't matter where, but ideally at the very bottom:

# load the shades
%:shades.prf

In 0.5.4, I deleted several pref files related to the Amiga and RISC OS operating systems, since those ports are no longer supported. All I can think of is somehow your mac is loading the shades through one of those pref files.

In that colors menu, isn't there an option to reset the colors? That should re-load shades.prf as well.

The reason 0.5.3 can't load the savefile is that I added a single terrain in 0.5.4. If you merely wanted to open the file in 0.5.3 and see if the colors work, in the NPP*/lib/edit file, you need to take the terrain.txt and limits.txt file from the 0.5.4 folder and load them into 0.5.3 folder (same place, NPP*/lib/edit).

**ghengiz** · February 27, 2012, 21:45

Originally posted by nppangband

In your NPPAngband directory, the in the *npp/lib/pref folder, there is a file called pref.prf. If you don't mind, please try inserting this line into that tile somewhere. It probably doesn't matter where, but ideally at the very bottom:

# load the shades
%:shades.prf

No, it doesn't work...Neither does manually loading shades.prf (copied to ~/.angband/NPPAngband) both from the main option menu, nor from the interact with colors sub-menu.
The latter case doesn't even give a message, as opposed to loading from the option menu, that at least says that the pref file has been loaded...

Originally posted by nppangband

In 0.5.4, I deleted several pref files related to the Amiga and RISC OS operating systems, since those ports are no longer supported. All I can think of is somehow your mac is loading the shades through one of those pref files.

In that colors menu, isn't there an option to reset the colors? That should re-load shades.prf as well.

Perhaps that's the reason...
no, the only options present are

load a user pref file
dump colors
modify colors

Originally posted by nppangband

The reason 0.5.3 can't load the savefile is that I added a single terrain in 0.5.4. If you merely wanted to open the file in 0.5.3 and see if the colors work, in the NPP*/lib/edit file, you need to take the terrain.txt and limits.txt file from the 0.5.4 folder and load them into 0.5.3 folder (same place, NPP*/lib/edit).

Finally something that works!

the save file from 0.5.4 loaded in 0.5.3 gives the right colors.

edit:
is there a way to check which files are loaded at startup?

**nppangband** · February 28, 2012, 02:46

I must admit, I am baffled by this one.

The option to re-set the visuals is in another option.

The commands are:

'=' followed by:
'v' (Interact with visuals)
'r' reset the visuals

I am curious how the colors look after that.

Also, what is the RVG values?

For example, color 1 (white, left most column, second from the top) should read 255, 255, 255. The color below that (#2, slate) should be 128, 128, 128. The one below that (#3, orange) should read 256, 128,0.

Please let me know if that isn't how they read. If they aren't that color. You can also try modifying one of those colors to the correct values and seeing if they are correct after you exit the menu and play the game.

**ghengiz** · February 28, 2012, 10:41

Originally posted by nppangband

I must admit, I am baffled by this one.

The option to re-set the visuals is in another option.

The commands are:

'=' followed by:
'v' (Interact with visuals)
'r' reset the visuals

I am curious how the colors look after that.

Also, what is the RVG values?

For example, color 1 (white, left most column, second from the top) should read 255, 255, 255. The color below that (#2, slate) should be 128, 128, 128. The one below that (#3, orange) should read 256, 128,0.

Please let me know if that isn't how they read. If they aren't that color. You can also try modifying one of those colors to the correct values and seeing if they are correct after you exit the menu and play the game.

I did reset the visuals, but nothing changed. Neither did after a screen refresh with ctrl-R while in town, nor after exiting (saving the game) and re-running the binary.
Well, as I noted in a previous post, I cannot edit the colors while in game, because the mouse and the cursor keys are not functioning at all in that menu, while the latter are fine elsewhere (the mouse doesn't, but I don't mind). So I dumped the colors in a file, after I did reset the visual as you suggested, and the values are the correct ones, as they were before.
Curiouser and curiouser...
Where is documented how the pref files work? I'd like to try and load just the minimum required, and see what happens...

edit:
I did a make clean & rebuild, and there were just a warning:

cmd4.c: In function ‘do_cmd_options_aux’:
cmd4.c:657: warning: cast from pointer to integer of different size

such line reads:
int page = (int)vpage;
where vpage is declared as void*

I did a quick test editing the cast to (int)*vpage and (int&)vpage, but the compiler didn't like it...
Neither changing the cast to (int*)vpage or (int)&vpage did the trick.
oh, and after every change I did reset the visual and loaded the shades.prf, but the colors are still wrong.

**nppangband** · February 28, 2012, 16:14

With regard to the compiler warning, that line of code is at the top level of the menu, when you first hit '=', and if it wasn't working you wouldn't have been bale to get to the colors or visuals menu in the first place. So we can eliminate that as a problem.

The colors menu is kind of a special one, because the colors are arranged in an 8x8 column, and the regular ui menu can only handle up to 2 different columns (like in the knowledge screens). However code used to handle navigation and input in the color menu (located in cmd4.c) is similar to to code used in many places throughout the game. Is that the only place where the game is unresponsive? And, if I understand the situation, you can use the direction keys in other parts of the game, and you can't use the mouse at all?

The strangest part is that your pref file dump shows the correct color numbers, which would indicate that the colors are set properly, however the wrong color is being displayed on your monitor.

quick pref file info:

All the code for loading and saving pref files are handled in a file called pref.c. Essentially when the game starts up, it loads a file called prefs.prf (all pref files are located in *NPP/lib/pref). This file in turn loads various pref files depending on which system you are playing on, and also whether you are using graphics or ASCII.

Inside the pref file, the command to load another pref file starts with a '%', and it has a custon syntax it uses to create if statements to determine what to load and what files not to load, but they are simple english statements & easy to understand.

In the bottom of pref.prf, it then loads pref-mac.prf. I am at work and can't grep it, but somewhere it loads font.prf or graf.prf, depening on whether you are using graphics or ascii, which then in turn loads the pref files for the fonts/graphics for the various systems, as well as shades.prf.

Something just occurred to me while typing this out. The people that compile NPP for the mac, they actually use main-mac.c and makefiles from FAAngband rather than the one from NPP. I probably need to ask Nick what he uses, and replace my in-mac.c and makefiles with his.

**ghengiz** · February 28, 2012, 17:31

Originally posted by nppangband

With regard to the compiler warning, that line of code is at the top level of the menu, when you first hit '=', and if it wasn't working you wouldn't have been bale to get to the colors or visuals menu in the first place. So we can eliminate that as a problem.

The colors menu is kind of a special one, because the colors are arranged in an 8x8 column, and the regular ui menu can only handle up to 2 different columns (like in the knowledge screens). However code used to handle navigation and input in the color menu (located in cmd4.c) is similar to to code used in many places throughout the game. Is that the only place where the game is unresponsive? And, if I understand the situation, you can use the direction keys in other parts of the game, and you can't use the mouse at all?

exactly

Originally posted by nppangband

The strangest part is that your pref file dump shows the correct color numbers, which would indicate that the colors are set properly, however the wrong color is being displayed on your monitor.

quick pref file info:
<snip>

Something just occurred to me while typing this out. The people that compile NPP for the mac, they actually use main-mac.c and makefiles from FAAngband rather than the one from NPP. I probably need to ask Nick what he uses, and replace my in-mac.c and makefiles with his.

Probably it's not needed: yes, I'm compiling on a mac, but I prefer using the gcu port, not the carbon one. Call me weird

I just tried to compile the latter, and with just a few edits in src/externs.h and src/main-crb.c, it works well: mouse, colors and all...

Let's go back to the curses port. Thanks to your explanation I modified pref.prf in such a way to read directly the *gcu.prf files, with % callings at the end of the file, to be sure the definitions within are not overwritten by the if's above. It doesn't work yet

If you'd like me to try something else to fix this strange behaviour, just let me know...I'm out of ideas...
Well, at least the native port is fine, so I suppose I can just use that for now.
Thanks anyway

**nppangband** · February 28, 2012, 18:56

Originally posted by ghengiz

exactly

Probably it's not needed: yes, I'm compiling on a mac, but I prefer using the gcu port, not the carbon one. Call me weird

I just tried to compile the latter, and with just a few edits in src/externs.h and src/main-crb.c, it works well: mouse, colors and all...

Let's go back to the curses port. Thanks to your explanation I modified pref.prf in such a way to read directly the *gcu.prf files, with % callings at the end of the file, to be sure the definitions within are not overwritten by the if's above. It doesn't work yet

If you'd like me to try something else to fix this strange behaviour, just let me know...I'm out of ideas...
Well, at least the native port is fine, so I suppose I can just use that for now.
Thanks anyway

That's completely different, and now it makes sense! GCU doesn't use the color system that all the other ports do. I have a linux desktop so I can actually help with this one. The GCU port has its own color scheme (there is a section in main-gcu.c that defines the colors), and ignores shades.prf. That's why none of the changes we were trying were working. The colors are from 0-216. Red, green, and blue colors are all on a scale of 1-6 (or is it 0-5?). Then they are blended into a single number from 0-216 (6*6*6). In 0.5.4 I thought I was fixing them, but I may have completely messed them up.

For now, just use the main-gcu.c from NPP 0.5.3, and the base 16 colors will work correctly. Some of the shades may be completely wrong, however. It was on my to-do list (in the next 4-5 days) to confirm the colors in the gcu port. I thought they may need some minor tweaks. I had no idea I had messed them up that badly.

**ghengiz** · February 28, 2012, 19:19

Originally posted by nppangband

For now, just use the main-gcu.c from NPP 0.5.3, and the base 16 colors will work correctly. Some of the shades may be completely wrong, however. It was on my to-do list (in the next 4-5 days) to confirm the colors in the gcu port. I thought they may need some minor tweaks. I had no idea I had messed them up that badly.

wohoo! now the main colors are correct, thanks!
The mouse doesn't work yet, but who cares, it's soooo far away anyway

The cursor keys still don't respond in the modify color menu, but that's not a top priority thing for playing

BTW, you are right, the shades look wrong, but the biggest issue has been ironed out

Attached Files

**nppangband** · February 28, 2012, 20:39

Good news! Thank you for being willing to help me solve the problem. I will work out colors 17 and above soon, but at least it looks somewhat normal.

I don't think the gcu port (or the gtk port) has mouse support. The sdl port does, but you can only have one window in that one.

**nppangband** · February 29, 2012, 01:57

I modified the colors & uploaded to github, based on the values at this site:

http://upload.wikimedia.org/wikipedia/commons/9/95/Xterm_color_chart.png

I am in the middle of re-installing my linux desktop, and I haven't compiled NPP on it yet. The colors now at github are untested, but they should be close. I will get the gcu port going this weekend and finish the colors.

**ghengiz** · February 29, 2012, 09:43

Originally posted by nppangband

I modified the colors & uploaded to github, based on the values at this site:

http://upload.wikimedia.org/wikipedia/commons/9/95/Xterm_color_chart.png

I am in the middle of re-installing my linux desktop, and I haven't compiled NPP on it yet. The colors now at github are untested, but they should be close. I will get the gcu port going this weekend and finish the colors.

Here is a test. Not bad...

Attached Files

**nppangband** · February 29, 2012, 14:28

Thanks again for posting that. It turned out better than I expected. One or two of them look a little off, but at least they are all in the ballpark and the screen isn't an eyesore any more.

[npp 0.5.4] text color issue

[npp 0.5.4] text color issue

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment