HDTenEightyP/NetNews huggingface dataset:
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: conformance question
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Fri, 18 Dec 92 05:37:55 GMT

In <1992Dec16.205020.2674@dsd.es.com>
	rthomson@mesa.dsd.es.com (Rich Thomson) writes:
>I'm beginning to think that applications will still have a big
>platform-specific "switch" statement figuring out which visual to use
>in order to find the fastest visual.

In article <1gqjdrINNi40@fido.asd.sgi.com>
	gavin@krypton.asd.sgi.com (Gavin Bell) writes:
>I think most applications will have a very good idea of what
>functionality they require, and will know what visual they need.

You're missing my point; many applications just aren't useful to their
users unless the rendering is fast.  In fact, many new applications
have become possible simply by the advances in rendering speeds of
modern graphics systems.  For those applications, it isn't a matter of
detecting a visual with the given functionality, but it is a matter of
finding the visual with the given performance.  OpenGL guarantees that
a visual will exist which will have all the functionality, but it
doesn't provide any way for an application to determine which visuals
are implemented through hardware, software, or a combination of both.
At least, if it does provide such a mechanism I haven't found it in
the man pages or the spec.  I haven't read them exhaustively yet,
though.

						-- Rich
-- 
		      Don't blame me; I voted Libertarian.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer
From: apm@kikka.hut.fi (Antti Miettinen)
Newsgroups: comp.graphics.opengl
Subject: OpenGL and GL tmesh
Date: 19 Dec 92 17:56:27
Organization: Helsinki University of Technology, Finland
Distribution: inet
NNTP-Posting-Host: kikka.hut.fi

I can't find any mention about a counterpart for GL swaptmesh() in the
OpenGL manual pages that I got from sgi.com. Does this mean that
swaptmesh() is going away and I should avoid it? It seems that you can
draw triangle strips and fans but no longer combinations.

Please say it's not true. Fiddling with trimeshes has been so much
fun. I mean.. the intellectual challenge of drawing some geometry as
one single trimesh and figuring out the correct swaps and.. But
seriously - wouldn't it be pretty easy to provide the counterpart
provided that an OpenGL implementation has to offer strips and fans?
And it would save sending a couple of vertices here and there.
Propably typically not a great saving but if it is easy to provide and
increases compatibility then wouldn't it be a good idea to include it?

First I thought that glEdgeFlag() could be used for the purpose but
the manual page states that it is significant only if polygon mode is
point or line. Hmm.. is the following a contradiction? First the man
page states that "In particular, glEdgeFlag may be called between a
call to glBegin and the corresponding call to glEnd" and in the ERRORS
section "GL_INVALID_OPERATION is generated if glEdgeFlag is called
between a call to glBegin and the corresponding call to glEnd".

Newsgroups: comp.graphics.opengl
From: jsw@microunity.com (Jeff Weinstein)
Subject: Re: conformance question
Distribution: world
Organization: MicroUnity Systems Engineering, Inc.
Date: Tue, 15 Dec 1992 08:06:09 GMT

In article <1992Dec15.074053.1837@dsd.es.com>, rthomson@mesa.dsd.es.com (Rich Thomson) writes:
> Would an OpenGL implementation that did not provide double buffering,
> depth (Z) buffering, stencil buffering nor accumulation buffering be
> conformant with the OpenGL specification?  (In other words, it would
> only provide a "front left" buffer for rendering.)
> 
> If the answer is yes, how is this different from subsetting?

  From the GLX extension spec, version 1.0:

	A conformant GLX extension must provide at least one RGB visual
	with a spencil buffer, a depth buffer, and an accumulation buffer
	with color components of non-zero size.  A conformant extension
	must also provide at least one color index type visual with depth
	and stencil buffers.  Other visuals with fewer associated buffers
	may also be made available.

So the answer to your question is no, at least in the context of GLX.

	--Jeff

-- 
Jeff Weinstein - X Protocol Police
MicroUnity Systems Engineering, Inc.
jsw@microunity.com
Any opinions expressed above are mine.
Newsgroups: comp.graphics.opengl
From: woo@basia.csd.sgi.com (Mason Woo)
Subject: Re: GL question
Reply-To: woo@basia.csd.sgi.com (Mason Woo)
Organization: Silicon Graphics Inc.
Date: Thu, 17 Dec 1992 06:54:59 GMT

In article <1gioc6INNck8@fido.asd.sgi.com>, akin@tuolumne.asd.sgi.com
(Allen Akin) writes:
|> You can create the display lists in any way you like.  OpenGL provides some
|> utility routines to convert window-system fonts into display lists, but
since
|> X11 provides only raster fonts, on X11 you'll only get rasters.  (On Windows
|> NT you also get polygonal fonts.)  Since you need Hershy fonts, I'd
recommend
|> getting one of the public-domain versions of the glyphs and building display
|> lists from them.  Then you can draw vector fonts with the string-drawing
|> routines mentioned in step 2 above.  This is fairly easy to do, and gives
|> you the freedom to modify the font in whatever way you'd like.
|> 
|> [Mason, is there anything like this in the OpenGL books?  Might be a good
|> example.]

Yes, Tom Davis wrote a raster font and a stroke font example for
the OpenGL Programming Guide, which will be published by Addison-Wesley
in the spring of 1993 (you have just read a blatant plug).  I'll show
you two subroutines of a code example from the book.  This example
assumes an array rasters[] defines the bitmaps for the character glyphs.
The printString("string") routine uses the ASCII values for `s', `t', `r', 
`i', `n', and `g' to index into a set of contiguous display lists.

#define FONTOFFSET 1000

void makeRasterFont(void)
{
    long i;
    glPixelStorei(GL_UNPACK_ROW_LENGTH, 0);
    glPixelStorei(GL_UNPACK_SKIP_PIXELS, 0);
    glPixelStorei(GL_UNPACK_SKIP_ROWS, 0);
    glPixelStorei(GL_UNPACK_LSB_FIRST, GL_FALSE);
    glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
    for (i = 32; i < 127; i++) {
        glNewList(i+FONTOFFSET, GL_COMPILE);
        glBitmap(8, 13, 0.0, 2.0, 10.0, 0.0, rasters[i-32]);
        glEndList();
    }
}

void printString(char *s)
{
    long oldlistbase;
    glPushAttrib (GL_LIST_BIT);
    glListBase(FONTOFFSET);
    glCallLists(strlen(s), GL_UNSIGNED_BYTE, (unsigned char *)s);
    glPopAttrib ();
}

Mason Woo, "The OpenGL Right Reverend" 	(415) 390-3314 
Graphics Technology Licensing (Product Marketing)
Silicon Graphics, Inc.	Internet: woo@SGI.COM 	
Personal opinion:  "I worship Arturs Irbe"
Newsgroups: comp.graphics.opengl
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: conformance question
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Tue, 15 Dec 92 20:45:00 GMT

In article <1992Dec15.080609.26325@microunity.com>
	jsw@microunity.com (Jeff Weinstein) writes:
>  From the GLX extension spec, version 1.0:
>
>	A conformant GLX extension must provide at least one RGB visual
>	with a spencil buffer, a depth buffer, and an accumulation buffer
>	with color components of non-zero size.  A conformant extension
>	must also provide at least one color index type visual with depth
>	and stencil buffers.  Other visuals with fewer associated buffers
>	may also be made available.
>
>So the answer to your question is no, at least in the context of GLX.

How does this mesh with the following:

    ``All color buffers must have the same number of bitplanes,
    although an implementation or context may choose not to provide
    right buffers, back buffers, or auxiliary buffers at all.
    Further, an implementation or context may not provide depth,
    stencil, or accumulation buffers.''
    (OpenGL specification V1.0, pg. 88)

Further, it seems that the presence of double buffering, depth
buffering, stencil buffering and accumulation buffering isn't strictly
required of all OpenGL implementations since the glGet() function is
used to query the presence of these.

I'm still curious how this is different from subsetting.  A (valid)
complaint from 3rd party vendors with PHIGS is that they can't depend
on a certain feature (Z buffering, or double buffering say) being
present in all implementations.  At first glance, it would appear that
the edict of "no subsetting" would require these features to be
present in all conformant OpenGL implementations.  However, closer
examination of the specification (and hinted to by the man pages)
indicates that many of the problems caused by subsetting in PHIGS may
be present in OpenGL as well, since the specification says that they
are optional.

						-- Rich
-- 
		      Don't blame me; I voted Libertarian
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer
Newsgroups: comp.graphics.opengl
From: mark@westford.ccur.com (Mark Thompson)
Subject: Re: Realistic 3D Studio usage
Organization: Radiant Image Productions, Merrimack NH.
Date: Tue, 15 Dec 1992 18:10:42 GMT

In article <Bz6nGA.L29@mtholyoke.edu> mkofahl@MtHolyoke.edu (Cat-in-the-Hat) writes:
>
>Macintosh seems to be the leader for animation packages so far...here's
>what I know (somewhat limited, but producing some impressive stuff!):

I really despise platform wars but I must say that of all the platforms
out there, the Mac has to be just about the worst for 3D animation. By
far and away, the most cost effective and powerful setups would run on
either an Amiga or a PC clone. When you include the software cost, the
SGI boxes are just not a very good value. My personal preference is
LightWave on the Amiga which has some truly tremendous capabilities.
You will be seeing some really awe inspiring stuff produced with this
package very shortly. It will completely redefine how you view "3D on
home computers". (And "Babylon 5" is only the tip of the iceberg).
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~%
%      `       '        Mark Thompson                 CONCURRENT COMPUTER  %
% --==* RADIANT *==--   mark@westford.ccur.com        Principal Graphics   %
%      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   %
%     Productions       (508)392-2480 (603)424-1829   & General Nuisance   %
%                                                                          %
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newsgroups: comp.graphics
From: "danny hawrysio" <danny.hawrysio@canrem.com>
Subject: ati ultra plus
Reply-To: "danny hawrysio" <danny.hawrysio@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 19 Dec 92 20:29:11 EST


-> One problem that I've heard of with the Ultra Plus (and I have not
-> verified this with ATI since I'm perfectly happy with my new
-> SpeedStar 24X) is that the second MB of memory clashes with system
-> memory if you have more than 8MB installed. Apparently, they set the
-> addressing of the second MB at the beginning of the 9th MB...
->
-> Anyone have a definitive word on this? Did I hear right or wrong?

 The old memory problem had started around 12 megs, and according to ATI
the newest of their drivers can now work with any amount of memeory in
the system.
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.graphics
From: data1@netcom.com (Adam Shiffman)
Subject: Re: POV Ray Trace
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 14 Dec 1992 23:48:15 GMT

Hi,

There are a number of utilities available for POV-Ray, some are available
via anonymous ftp, some as I know, haven't yet circulated very much.  There 
are two BBS's in the U.S. that are great sources for raytracing utilities, 
You Can Call Me Ray at 708-358-5611, or 708-358-8721 - there's also The 
Graphics Alternative, all the way out here on the West Coast.  TGA has util-  
ities for POV-Ray, Vivid and a few others as well.  Take your pick.  Both
BBS's are quite busy, so don't be discouraged by a busy signal.  If you stop
by TGA, just remember to leave me a message reminding me that I sent you this
message. :-)

  
//-\ c| /-\ /\ / 
-- 
\-/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\
  Adam Shiffman
  internet: data1@netcom.com
  bbs: The Graphics Alternative (510)524-2780
\-/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\/-\
 

Newsgroups: comp.graphics
From: dave@oldcolo.oldcolo.com (Dave Hughes)
Subject: NAPLPS Conversions
Organization: Old Colorado City Communications (oldcolo.com - login "newuser")
Date: Mon, 14 Dec 1992 04:38:04 GMT

Michael Dillon, in responding to Ken said
 
>converting bitmap formats such as GIF, JPEG, TIFF, etc... to NAPLPS
>is not a very good idea although it *IS* possible. NAPLPS is an
>object oriented graphics format like Postscript, metafiles, Corel
>Draw, etc... It does allow for bitmaps but if they are any
>significant size you lose the compactness advantage of NAPLPS. I
>have only used icon bitmaps (I wrote an MSDOS QBASIC program to
>convert Windows icons.) in NAPLPS pictures.
 
 
One new development on the NAPLPS front, according to my contacts in 
Canada who sit on the CCITT and Canadian Standards Association 
committees (and NAPLPS is a - some say *the* - only totally 'joint' 
ANSI-CSA standard), is that the CCITT committee which has purview
over the graphics standards that included NAPLPS, has incorporated 
JPEG into the standard. And that CSA will soon meet to ratify it 
there. So as soon as the laggard US ANSI counterpart committee 
catches up, JPEG, will be included formally within teh Naplps 
standard.
 
In practical terms, that means a JPEG image, perhaps reduced to a 3 
or 5k size and small frame on the screen, can be properly included 
inside a NAPLPS frame or sequence.
 
Anticipating this, Microstar of Canada, has a give-away demo disk 
that has a demo, and tutorial on Naplps, with and without Jpeg for 
any MSDOS VGA or Supervga system.
 
I have added this to the /pub/naplps anonymous ftp files on 
oldcolo.com. Its a self-unarcing file named mstar.exe. 500+k
 
While its fine, if you have the option of starting with a metafile 
format, to convert to Naplps. But I think good programs are really 
needed that can convert bitmaps too - and we should not have to live 
with the limits of Videoshow, or any other conversion program which 
either doesn't do it exactly right, or is simply a kludge to get 
close. We need a bitmap --> naplps modern conversion program. 
 
Dave Hughes
dave@oldcolo.com
 


Newsgroups: comp.graphics,comp.graphics.animation
From: abraxis@iastate.edu (Zomfir Ali)
Subject: Re: Realistic 3D Studio usage
Organization: Iowa State University, Ames IA
Date: Tue, 15 Dec 1992 23:40:55 GMT

In <Bz8JDw.LDJ@mtholyoke.edu> mkofahl@MtHolyoke.edu (Cat-in-the-Hat) writes:
>People, people...the original poster wanted a home system. Now, if Indigos
>and Crimsons are Home Systems to you people, GREAT, I'm JEALOUS... But I
>assumed that by that he meant a hobby system.
>-Meko
>mkofahl@mhc.mtholyoke.edu
>(I welcome corrections, I'm intensely interested in this field, and 
> don't know nearly as much yet as I'd like...as I'm sure some will
> already attest...*sigh*)

If you're looking for a system that can do _real_ graphics work, it has
been my experience that you must leave the general purpose PC's Mac's and
Amiga Game Machines behind.  For about the same price as a healthy new 486
or alot less than a new Mac, look into used SGI systems.  At the high end,
my roomate just spent $9k for a 210/GTXB. That means around 100,000 
gourand shaded polygons per SECOND. Compared to 3DStudio 2.0, 50 to 100 poly/s
Of course, 9k is alot, but I'm looking into used 4D/20TG's for around $3k. 
That includes 24bit at 1280x1024, 19" monitor, and half gig HD, 
rendering around 12,000 poly/sec.
Let's see how a $3000 Mac compares.  Get Real, Get an SGI.
Abraxis
From: mike-b@hpfcso.FC.HP.COM (Michael Bishop)
Date: Sat, 19 Dec 1992 00:08:58 GMT
Subject: ATI Ultra Plus
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.graphics

Does anyone know if the ATI Graphics Ultra Plus (with 2MB of DRAM)
supports 1280x1024 resolution with 256 colors?  I'm considering trading
in my Diamond Stealth 24X for the ATI card and I'm looking for opinions
about ATI products.

Thanx.

Michael Bishop
Hewlett-Packard Company
Internet: mike-b@fc.hp.com
CompuServe: 71552,1341
From: spl@ivem.ucsd.edu (Steve Lamont)
Newsgroups: comp.graphics
Subject: Re: GOOD JPG VIEWER
Date: 19 Dec 92 15:20:14 GMT
Organization: University of Calif., San Diego/Microscopy and Imaging Resource
NNTP-Posting-Host: ivem.ucsd.edu

In article <1992Dec19.010139.29378@a.cs.okstate.edu> saeed@a.cs.okstate.edu (SAEED FAISEL) writes:
>In article <1gt4vkINNijv@network.ucsd.edu> spl@szechuan.ucsd.edu (Steve Lamont) writes:
>>In article <6937.48.uupcb@outlan.ersys.edmonton.ab.ca> darren.madu@outlan.ersys.edmonton.ab.ca (Darren Madu)  writes:
>>>Does anyone have any good jpg viewer.
>>
>>Yes.
>
>OK. So how about sharing with us ?

See item 7 of the Frequently Asked Questions file either here or on
news.answers.

							spl
-- 
Steve Lamont, SciViGuy -- (619) 534-7968 -- spl@szechuan.ucsd.edu
UCSD Microscopy and Imaging Resource/UCSD Med School/La Jolla, CA 92093-0608
Where is the summer, the unimaginable
Zero summer?                 - T.S. Eliot, "Little Gidding"
From: rjb12@unix.brighton.ac.uk (Titch)
Newsgroups: comp.graphics
Subject: Bezier/B-spline C sources
Date: 17 Dec 92 10:26:31 GMT
Organization: University of Brighton, UK

Does anyone know if there are C sources for Bezier curve or B-Spline curve
generation available out there?


Cheers,

Rich.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rich Browning (rjb12@bton.unix)   * The Intel Plentium: Ethernet controller  
Department of Computer Science    * or fiendish knitting pattern?          
University of Brighton            * What!? It's a PROCESSOR???            
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.graphics
From: syscrc@pickle.gsu.edu (Randy Carpenter)
Subject: Re: SDSC Image Tools V2.1 Release
Keywords: image file format, graphics, pixel utilities, image processing
Organization: Georgia State University
Date: Wed, 16 Dec 1992 22:16:41 GMT

Why are the SDSC binaries so enormous?  Stripped even!

-- 
===========================================================================
Randy Carpenter                    rcarpent@gsu.edu          % Got a light?
Georgia State University           (404) 651-2648            No match.
Wells Computer Center                                        %
Newsgroups: comp.graphics
From: kaustell@viikki.Helsinki.FI (KIM OLAVI KAUSTELL (MATEK))
Subject: Visualizing connections
Organization: University of Helsinki, Fac.Agric.For.
Distribution: bionet.general
Date: Tue, 15 Dec 1992 10:11:31 GMT

Hello all !

I'm dealing with accident prevention and analysis research. I'd want to 
visualize the different actions taken before the actual accident happened. 
What I'm looking for is a graphics prog, that draws the grouped actions 
leading to the accident as boxes (circles...) and connects them with lines. 
The thickness of these lines should describe the frequency of the sequence 
of corresponding two actions preceeding the accident.

I know this wasn't too explicit a description, but any help, hints and 
suggestions are welcome.

                        -= Kim Kaustell =-
-----------------------------------------------------------------------------
HELSINKI UNIVERSITY                     Tel.      +358+0+70851
Dept. Agric. Engineering                Fax.      +358+0+7085491
And Household Technology                Internet : Kim.Kaustell@Helsinki.Fi
Helsinki, Finland                       EARN     : KAUSTELL@FINUH
-----------------------------------------------------------------------------
Newsgroups: comp.graphics,comp.graphics.animation
From: chrisw@fciad2.bsd.uchicago.edu (chris williams)
Subject: Re: Realistic 3D Studio usage
Organization: FCIA Univ. of Chicago
Date: Sun, 13 Dec 1992 22:04:40 GMT

In article <1gg6u8INNdgb@agate.berkeley.edu> aron@taos.ced.berkeley.edu (aron bonar) writes:
>In article <PHUTTER.59.724272116@cardinal.sc107.wesleyan.edu>, PHUTTER@cardinal.sc107.wesleyan.edu (Macbeth) writes:
>|> In article <Bz6nGA.L29@mtholyoke.edu> mkofahl@MtHolyoke.edu (Cat-in-the-Hat) writes:
>|> 
>|> >Macintosh seems to be the leader for animation packages so far...here's
>|> >what I know (somewhat limited, but producing some impressive stuff!):
>|> 
>|> You are kidding, right?
>|> 
>|> 
>|> Come on! For $20K you can get a Silicon Graphics Iris Indigo with full 3D 
>|> animation software and 24-bit accelerated graphics, as well as CD-quality 
>|> sound and real-time rendering and animation. Included on these systems is 
>|> the capability to capture/edit digital video from a multitude of sources and 
>|> even paste them back to either digital or analog media (optical disks / 
>|> video tapes). Of course, you also get the Silicon Graphics MIPS chip 
>|> performance and the ability to upgrade to a 64-bit R4000. For $20,000 you 
>|> can most definitely get a very nice setup ......... however, PLEASE do not 
>|> make it a Macintosh.
>
>
>That's right...How can anyone way that Macs are the best animation machines when
>there are Crimsons and Indigos around. 

   This person probably wasn't kidding, just going to a school run by
Mac bigots. I have kept my eye on the Mac market for quite a while, but
I haven't seen any 3D programs that I could consider using, a situation
excerbated by the inability of Mac folks to admit any weaknesses in
their machine. 

   Forget SGI for a moment and consider that one can buy a 486-33 DX2
with 16 megs of RAM and a 550 meg hard disk, a 24-bit video card and
a 14" monitor for well less than $4000.00 US. Tack on 3D Studio and
you have the ability to generate 24-bit animations at true broadcast
quality. Of course the frames will have to be single-framed out to tape
but that is the same no matter what platform you choose.

   Yes, the PC bus is antiquated. Yes, the basic hardware is ill-suited
to video. But the shear size of the clone market has produced the best
deal in processing power for the price. I have the hardware described
and am, as I type this (on another computer) rendering a Christmas
scene, 32-bit 756 by 486 images at ~7 minutes *each*. With snow.

   One very inexpensive computer, no fancy parallel processing.

   The other way to go is to get an Amiga, and take advantage of the
world's least expensive animation _software_. You will pay more for
the MIPS, but you could get a number of different packages for very
little money and explore several different types of animation.

   But a *Mac*? Really?

                                Chris Williams
                                chrisw@fciad2.bsd.uchicago.edu

A professional animator, actually making a living at this stuff.

Xref: sparky comp.graphics:13071 comp.graphics.animation:1383 comp.graphics.research:403
From: chess@McRCIM.McGill.EDU
Newsgroups: comp.graphics
Subject: CIRCUITS graphics package
Date: 14 Dec 92 15:54:42 GMT
Organization: McGill Research Centre for  Intelligent Machines
Originator: chess@kadumu.mcrcim.mcgill.edu


Anyone aware of a graphics package that can read an analog
circuit in some specified input format and produce a circuit
schematic on a window. 

Any info/pointers is appreciated.

k.s
-- 
___________________________________________________________________________
|	K.Sandrasegaran(Sandy)		|  Tel : (514) 398-7159 /398-5857 |
|	McGill Research Center for -    |  Fax : (514) 398-4470           |
|	  Intelligent Machines (McRCIM) |  email: chess@mcrcim.mcgill.edu |
Newsgroups: comp.graphics