Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!hamblin.math.byu.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbfsb!cbnewsb.cb.att.com!sladkey
From: sladkey@cbnewsb.cb.att.com (john.r.sladkey..jr)
Newsgroups: comp.sys.3b1
Subject: Re: problems with graphics under TAM
Message-ID: <1991Feb28.221255.3892@cbfsb.att.com>
Date: 28 Feb 91 22:12:55 GMT
References: <1991Feb18.190101.22034@uncecs.edu>
Sender: news@cbfsb.att.com
Organization: AT&T Bell Laboratories
Lines: 45

In article <1991Feb18.190101.22034@uncecs.edu>
tcamp@uncecs.edu (Ted A. Campbell) writes:

>The problem: I want to be able to poll the keyboard to
>see if a character is available without being locked in a
>wait for a character (where is CP/M when we need it?).
>Normally I accomplish this by taking hold of /dev/tty
>and altering its parameters so that a read() of the keyboard
>(/dev/tty) will return immediately if it does not succeed.

A fix for the approach you are taking is to call
setpgrp() in your TAM initialization routine
which will cause /dev/tty to return the correct window.
However, a slighly different approach will work without
this:  Make ioctls on the window handle (this is really a
file descriptor) instead of /dev/tty.  This is one of
those screwy situations where /dev/tty and and stdin
aren't the same even though they're both ``terminals.''

>(2) Can we address text to specific pixel locations?
>I fear that (under TAM) the answer is no. Everything I read
>and try suggests that text has to be addressed to a character
>cell location, and cannot be addressed to a pixel-specific
>location. But have I missed something? One would think that
>on a bitmapped terminal the placement of text at pixel specific
>locations would be possible. Without this capability, the TAM
>implementation of my software will be seriously retarded.

My recent posting of ZLIB contains some code to address this
problem with TAM.  It drove me crazy for a while and the fix
is horrible.  Get this: to accomplish pixel based text with
TAM I had to write code to read the raw font files (this
was no small feat), then use rastop calls on the individual
bitmaps ``by hand.''  At least the outline of the code is
fleshed out in ZLIB if you want to give it a try.  This has
the side effect of being able to overlay text onto the
screen using various rastop arguments and also allows drawing
to a virtual screen which is then updated to the real screen.

>- Ted Campbell
>tcamp@uncecs.edu


Rick Sladkey
mvjrs@mvgpk.att.com