On 9 Jul 2009 at 10:59, Demian Ferreiro wrote:

> Hi.
> 
> I'm doing a little terminal-based game project and I was considering using
> pdcurses to make it cross-plataform (initially it used borland's conio.h in
> windows, but I've moved to linux now...). Note: the project is linked to
> pdcurses in windows, but uses ncurses in linux.
> 
> In Linux, however, I recently discovered that it was quite easy to get a 256
> configurable-color terminal, instead of the 8 color, non configurable-color
> terminal that most linux distributions are shipped with:
> $ export TERM="xterm-256color"
> 
> So I wanted to know if there is any way I could get 256 colors in the
> windows terminal or some way to emulate it. I've tested the win32 and the
> SDL ports of pdcurses with a little test program that informs about the
> color capabilities and prints the different colors and in both cases the
> output is the same: 16 colors and can_change_color() == TRUE.
> 
> I think this is reasonable with the win32 port, but I see no reason why the
> SDL port should have this values. Anyone knows if the win32 console API
> provides a way to get more than 16 simultaneous colors? And if that is the
> case, might it be possible to change the win32 pdcurses library, or the SDL
> one, in order to use that? (I have no problem to help with the code, I just
> want to know from a pdcurses developer, or someone who is familiar with the
> code, if this would be possible or not..).

I'm not certain this is the right answer, but I recall that DOS only 
supported 16 colors, divided into two shades each of 8 colors.  I 
suspect that the current Windows console API is limited to supporting 
DOS color compatibility.

If you open a console window and type "help color" or "color /?" 
you'll see the DOS/Windows color scheme.  The "color" command is the 
DOS/Windows command line command for manipulating console window 
color.

I seem to recall that more colors were possible under DOS with the 
appropriate graphics cards, but 16 colors was the base VGA color 
capability that the OS supported - with other schemes being device 
dependent.

However, this is all a dim memory for me.  Someone else can probably 
give a better answer.

> 
> Well, this tourned to be a pretty long mail, sorry for that, and for my bad
> english as well =P

Your English is excellent!  I wish I spoke any second language as 
well as you speak (or at least write) English.

-- 
Alan Meyer
AM Systems, Inc.
Randallstown, MD USA
vrme...@comcast.net


Reply via email to