NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/lang/c/11607

Internet Message Format | 1992-07-25 | 4.0 KB

Path: sparky!uunet!cs.utexas.edu!torn!cunews!revcan!micor!uuisis!synapse!rod.willmot
From: [e-mail] (Rod Willmot)
Newsgroups: comp.lang.c
Subject: Curious bug...
Message-ID: <[e-mail]>
Date: 24 Jul 92 19:16:00 GMT
Distribution: world
Organization: SYNAPSE BBS - GATINEAU, QUEBEC - 819-561-4321
Reply-To: [e-mail] (Rod Willmot)
Lines: 69

TO: [e-mail]

To David R Hucke on the subject of his Curious bug:

DR>What happens is this:  When I run the program in the QC Environment it
DR>works fine.  The characters are correct, and the colors are not correct.
DR>When I run the program from DOS (outside of the QC Environment) the
DR>characters are correct but the colors are not correct.

First, some tips:  (1) when doing this kind of thing, make sure
your data is always unsigned.  (2) Remember to open files in binary
mode, not just in "r".  (3) Since you start with shorts you should
continue with shorts, instead of switching to ints (just to avoid
flames from the boring).  (3) Throw out the IDE... (Seriously, your
productivity will soar, especially with a programmer's editor like
Multi-Edit.)  (4) Use a file viewer that can work in hex mode, like
LIST.COM, to see what's *really* in the data file you're trying to
read in.  This can tell you whether the x byte really comes first
in each byte pair, as you think it does.

Actually that last point makes me wonder about your lines,
DR>  fscanf(file,"%c%c",&x,&y);
DR>  menu[j][i] = (short)((y<<8)+x);
The structure of video memory is such that the colour byte comes
first, followed by the high byte.   The question is whether TheDraw
writes it out that way.  If TheDraw treats the screen as an array
of bytes, it probably does; if it treats it as an array of ints, it
may not.  For example, suppose you construct an int buffer with the
value 0xF00F in each int; this is 0xF0, 0x0F in alternating byte
pairs.  If you write this to disk as a byte buffer, the order of
bytes is preserved, but if you write it to disk as an int buffer,
the order of ints is REVERSED.  (This is not true of all systems,
but it's something to watch out for.)

Personally I find it highly inefficient to fscanf a file like this.
You'll have better performance (and tighter control over the
results) if you read the whole file into a dynamically-allocated
buffer, in one shot; then throw it onscreen and free the buffer.
Examine your data file and see if the byte pairs are
attribute/character, or character/attribute.  If the former, which
models video memory, you may find it easier to treat the screen as
an array of bytes (4000 bytes instead of 2000 shorts).  Just
declare the buffer as a byte array, then copy its contents to video
memory as sequential pairs of bytes.  However, if the data is in
character/attribute order, this means it's been written to disk as
shorts and so you can read it in as shorts as well -- unreversing
it so to speak.  In this case, you treat the screen as an array of
shorts and you declare your buffer as an array of shorts, then read
in your file and copy it over as shorts.  (I'll say it again:  if
the byte order is reversed in the data file, you can unreverse it
simply by reading it in as shorts, i.e. into a short buffer.  If
it's not reversed, read it into a byte buffer.)

Have I confused you even more?  I'll be happy to help, since I use
QC 2.5 too.  One final point I'd like to make:  the best approach
to making menus is NOT to store them in a data file, since that way
you're frozen to one set of colours.  This gets important if you
want other people to use your programs and maybe configure their
own colours.  It doesn't take long to write your own little
functions to store a window area, clear it, draw a box there, and so
on; then you can write a menu system that performs those chores on
the data in a menu structure.  Performance ends up being better
than if you were reading it from disk, and you have more
flexibility.

[e-mail]    (Rod Willmot)
---
 . DeLuxe. 1.20 #2423 .