Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!rosenkra
From: rosenkra@convex.com (William Rosencranz)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: passing to PRG (was: Re: requirements to use VDI)
Message-ID: <1991Jun25.215933.22514@convex.com>
Date: 25 Jun 91 21:59:33 GMT
Sender: usenet@convex.com (news access account)
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Lines: 75
Nntp-Posting-Host: convex1.convex.com


i started this discussion by asking about using VDI calls in an otherwise
ordinary .ttp program. i have gotten lots of (good) feedback. but perhaps
i should specify exactly what i want to do...

these days i write exclusively .ttp programs, i.e. those which would normally
be executed from a CLI (currently i still use gulam). i want a few of these
programs (like the recently posted mgif - it did appear, did it not; i have
been away for a few days and things expire quickly here) to do a certain
amount of graphics, like lines, dots, and polygon fills. i have been using
line A for lines/points since it is so simple to do so. however, now i need
to do fills of irregular polygonal areas. this is possible with line A, but
the hassle of writing a front end to $A006 or whatever (one scan line at
a time fill) leads me to see if i can use the much simpler v_fillarea
(or whatever it is called). this is the ONLY vdi routine i want to call
at present.

it sounds like i can do basically

	graf_handle (or whatever)
	v_opvwrk (or whatever it is)
	v_fillarea

which is still nice and simple. i realize that it may cause problems if GDOS
is installed. since i do not have it, that doesn't bother me :-). i also want
to minimize the amount of overhead, though i suspect linking in vdibind
will add more than a little overhead.

i still want the program to feel like a curses-like application (no mouse)
and want command line args. i also realize that i can hand blit directly
to Physbase or my screen memory whatever the heck i want, but i don't need
the expense (in time) of writing routines to flip bits (which, admittedly,
aren't THAT hard).

is there a better solution? what will break if i do the above (so far it
looks like GDOS)? what are the restrictions? i have no interest in making
this a GEM program at this time. as it is now, it should port fairly easily
to X (maybe not so easily), Sunview (just draw a rasterfile in memory), etc.
making it GEM will ruin this attribute (which, religiously, i consider far
more important than having a mouse just to point+click rather than key a
1-2 char command code which, for me, is faster anyway). in fact, to further
fuel the ensuing amiga/atari flame war or skirmish, one of the things i
most like about the ST is it is SO easy to port unix software. and there
are many good csh/sh/etc clones available. i don't care about number of
colors since the SM124 is about the nicest monitor i have ever seen (often
overlooked in flame wars). my eyes thank atari for this one!

this brings up another question: are "flicker" screens possible on things
like monochrome Suns? how fast can u change full-screen raster images from
memory to the frame buffer (/dev/fb, i presume, for mono)? the equivalent
of:

	do {
		Setscreen (scrn1, scrn1, -1);		Vsync ();
		Setscreen (scrn2, scrn2, -1);		Vsync ();
		Setscreen (scrn3, scrn3, -1);		Vsync ();

	} while (!char_pressed_or_equivalent_interrupt);

which runs at at least 10-20 Hz on the ST (guess). since i no longer have
a sun, this may be more academic than practical. when i had a sun 3/50
i 1) operated it like a big vt100 (no squinting to make out those 6x8 fonts
or whatever when u have chars 1/4" high and u'd be suprised just how
productive ^Z and ~^Z and fg can be :-), 2) prefered mono to color (save my
poor eyes!). in fact since the 3/50 under SunOS 4.0 was such a dog when
trying to run sunview with only 4 MB (and slow page/swap SCSI disk), i had
little choice anyway. only the brief excursion to the land of windows for
a few thousand games of backgammon (gammontool) :-).

-bill
rosenkra@convex.com

--
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp.      |ARPA: rosenkra%c1yankee@convex.com