tcamp@uncecs.edu (Ted A. Campbell) (02/19/91)
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
yarvin-norman@cs.yale.edu (Norman Yarvin) (02/19/91)
tcamp@uncecs.edu (Ted A. Campbell) writes: >(1) What happened to /dev/tty under TAM? A call to setpgrp() might fix this. I think setpgrp() sets the terminal associated with your device; this in in some way a 'process group'. > close( 0 ); > close( 1 ); > close( 2 ); Put it here > w_id = open( "/dev/window", O_RDWR ); > dup( w_id ); > dup( w_id ); or here; see which works. >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. Why don't you just dup() your file descriptor, and alter the copy? -- Norman Yarvin yarvin-norman@cs.yale.edu "Obviously crime pays, or there'd be no crime." -- G. Gordon Liddy
mvadh@cbnews.att.com (andrew.d.hay) (02/19/91)
In article <1991Feb18.190101.22034@uncecs.edu> tcamp@uncecs.edu (Ted A. Campbell) writes:
[]
"(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.
this is true. however, you might be able to define your fonts as
icons. tam allows 64 icons in an iconfile array, so you'd need to
find a way to chain iconfiles...
i've devoted some thought to this with the intent of producing a tam
nethack, with a custom font for fixed things like food and traps, and
custom icons for monsters and the player, and bitmaps for the dungeon.
would it be possible to create a large icon array as a struct of
smaller arrays, thus allowing access to all icons with a single
pointer and using no fancy arithmetic?
nothing coded, though.
p.s. if i remember rightly, icons are limited to 16*16.
--
Andrew Hay +------------------------------------------------------+
Ragged Individualist | JAAAAAAANE! |
AT&T-BL Ward Hill MA | HOW DO YOU STOP THIS CRAZY THING? |
a.d.hay@att.com +------------------------------------------------------+sladkey@cbnewsb.cb.att.com (john.r.sladkey..jr) (03/01/91)
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