Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!decwrl!mcnc!ecsgate!ecsvax!tcamp
From: tcamp@uncecs.edu (Ted A. Campbell)
Newsgroups: comp.sys.3b1
Subject: problems with graphics under TAM
Message-ID: <1991Feb18.190101.22034@uncecs.edu>
Date: 18 Feb 91 19:01:01 GMT
Organization: UNC Educational Computing Service
Lines: 55



I am working on the implemntation of a graphics standard for
the Unix PC. This promises to offer some rather powerful
graphics capabilities that should be transparent between TAM
and MGR (i.e., compilable for each). I'm having good luck
in general, but at this point I'm having two specific problems
with the TAM implementation:

(1) What happened to /dev/tty under TAM?

I'm using the following sequence to initilize TAM:

   close( 0 );
   close( 1 );
   close( 2 );
   w_id = open( "/dev/window", O_RDWR );
   dup( w_id );
   dup( w_id );

   winit();
   
   w = wcreate( 2, 2, 18, 65, BORDCANCEL );

(note: w and w_id are integers)

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.
The catch: when I initialize the system as indicated above,
/dev/tty catches not the keyboard input to the new window
(which I want), but rather thekeyboard input to the underlying
(old) window. So in other words, I have to actuate the
underlying window to enter stuff to the window for my applica-
tion. What happened to /dev/tty? Any way around this?

(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.

I'll appreciate any help. Thanks again for your help on my
earlier inquiry concerning wrastop() routines, which are 
working fine (if slowly).

- Ted Campbell
tcamp@uncecs.edu