From: rod.willmot@synapse.isis.org (Rod Willmot) 
Newsgroups: comp.lang.c
Subject: Curious bug...
Date: 24 Jul 92 19:16:00 GMT
Distribution: world
Organization: SYNAPSE BBS - GATINEAU, QUEBEC - 819-561-4321
Reply-To: rod.willmot@synapse.isis.org (Rod Willmot) 

TO: pegasus@csd4.csd.uwm.edu 

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.

rod.willmot@synapse.isis.org    (Rod Willmot)
---
 . DeLuxe. 1.20 #2423 . 
           
Newsgroups: comp.lang.c