www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/05/26/12:18:48

From: Thomas Knudsen <tk AT geb DOT gfy DOT ku DOT dk>
Newsgroups: comp.os.msdos.djgpp
Subject: GRX20: Changing Pallette
Date: Mon, 26 May 1997 13:12:51 +0200
Organization: News Server at UNI-C, Danish Computing Centre for Research and Education.
Lines: 41
Message-ID: <Pine.SGI.3.95.970526123815.18735A-100000@geb.gfy.ku.dk>
NNTP-Posting-Host: geb.gfy.ku.dk
Mime-Version: 1.0
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

When using GRX20 in 256 color mode to display a pseudo-colored bitmap
image, I start by loading a pallette like this:

  for(i=0; i<256; i++) GrSetColor(i, r[i], g[i], b[i]);

then I display the image on the screen. However, if I later try to change
the pallette (to enable some interactive contrast stretching), nothing
happens.

I do know, that this is the documented (and, in other situations, quite
useful) behaviour of GRX20 - but for my application I need to circumvent
this feature. From time to time, I have tried different combinations of
GrAllocCell/GrFreeColor/GrSetColor, without any success.  Also, I have
been looking into the GRX20 source, to locate the point, where the locking
takes place, but when approaching the lower layers of the GRX20 source
code, things become somewhat intangible! If someone have a solution,
please post! 

One, somewhat awkward, solution, I could think of would be to write the
pallette values directly to the VGA registers. Earlier, I have done this
for 320x200x256 plain VGA, using Turbo C. Any pointers to how I can do
this in djgpp?  Also:  would it work, even in SVGA modes (I use
800x600x256)? I am not too fluent in neither SVGA programming, nor
assembly language, so any attempt of an explanation would probably bring
me further (or, perhaps, add to my confusion! :-) 

Of course, in the long term, converting everything to allegro would solve
the problem - I just do not happen to have time for that right now
(unfortunately! - allegro seems to be a quite decent piece of work,
and API-wise not *too* different from GRX)

thanks in advance!
Thomas


--
Thomas Knudsen                         | www:  http://www.gfy.ku.dk/~tk/
National Survey and Cadastre - Denmark | e-mail:            tk AT gfy DOT ku DOT dk
Geodetic office, Rentemestervej 8      | Direct Phone:   +45 35 87 52 64
DK-2400 Copenhagen NV, Denmark         | FAX:            +45 35 87 50 52

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019