This is the mail archive of the xconq7@sourceware.cygnus.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: snapshot 7.1.90


You think we are approaching a stable release, and then
Marcus Schrattenholzer <1schratt@informatik.uni-hamburg.de> writes:

> With the latest snapshot 7.1.90 we noticed the following:
> 
> * Building does not work straight away under Solaris.
 
> After fixing this, still the X11 paths are not set.
> 
> The trouble with imake:

Is by any chance your version of openwin X11R5-ish?

> Under Linux, configure was okay, just when compiling there was minor
> trouble,

Which Linux do you have?  Did configure find X11?  
It didn't for me (RedHat 4.1, X in /usr/X11R6).

> related to cconq only:
>   gcc -O2 -o cconq -g -DUNIX -I. -I./../kernel cconq.o cdraw.o ccmd.o
> ../kernel/libconq.a ../kernel/libconqlow.a -lcurses -ltermlib
> 
>   /usr/i486-linux/bin/ld: cannot open -ltermlib: No such file or
> directory

Does your system have ncurses?

Does "xmkmf; make Makefiles" work for Linux?

> * The much mentioned problems with the world view pixmap are still the
> same.

If you mean the pixmap in the panner, we have a problem; a design
problem, implementation looks easy.  Stan nuked the `color' terrain
property; therefore we don't know what to put into the pixmap.  Here
is what Stan wrote:

} Color and image are not orthogonal, but were being treated as if they
} were, which led to some bizarre situations where the terrain would change
} appearance radically at different magnifications, or would look different
} in the panner vs on the main map.  Sorry about breaking the panner pixmap!
} To fix, we need to use the same algorithm for drawing into the panner as
} is used on the map.  This will have other advantages as well.

The fact that terrains look different in the panner and on the main
map never troubled me ;-)  

I tried to look into this, but I really don't know what to do.  For
large maps, it comes down to 1 hex -> 1 pixel, so we need a solid
color for terrains.  Maybe the problem was that some colors matched
poorly with the terrain pixmaps.  One could compute the arithmetic
average of terrain pixmap colors and paint that in the panner, but I
don't think it would be any better that what we had.

If enough people ask him, Stan could reconsider? ;-)
Well, maybe not a `color' terrain property, that was misplaced.
But what about putting a "solid" 1x1 "image" in an image family?

-- 
        Massimo Campostrini, 
Istituto Nazionale di Fisica Nucleare, Sezione di Pisa.
WWW home page: http://www.difi.unipi.it/~campo/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]