JANKOWSJ@UNION.BITNET (03/17/87)
Dear G.E.M. Hackers,
Is there any-hacker in this universe that can assist me in
finding information about working with the G.E.M. functions
vro_cpyfm(handle,copy_logic,xy_array,psource_mfdb,pdest_mfdb);
vrt_cpyfm(handle,writing_mode,xy_array,psource_mfdb,pdest,col);
These two functions are used primarily to copy memory from
screen device to ram-memory of visa-versa. However, I would
like to be able to copy from memory to memory or visa-versa.
Can this be accomplished with these functions or am I living in
a fantasy.
If there is some documentation on these functions that are
a little more in-depth than Digital's "GEM PROGRAMMERS GUIDE
VOL. II" of "PROGRAMMER'S GUIDE TO GEM" please drop me a few
bytes.
Sincerely,
C.R.T.
JANKOWSJ@UNION.BITNETpete@gpu.utcs.toronto.edu (03/18/87)
Hi everybody,
Just thought I'd clear up the vro_copyform problem.
vro_cpyform copies a rectangular bitmap from one location to another
based on bit boundaries. (vro_cpyfm is similar, so I will stick with
vro_cpyform). The function looks like this:
vro_cpyform(handle,wr_mode,pxyarray,psrcMFDB,pdesMFDB);
"handle" is the VDIHANDLE previously obtained when opening the
application under GEM. (see graf_handle in documentation).
"wr_mode" is the writing mode under which the transfer will be
performed. example direct transfer of bits, or source bits xor'd into
destination bits.
"psrcMFDB" and "pdesMFDB" are pointers to "memory form definition
blocks". These are data structures that describe the memory areas being
transferd to or from (more later...).
"pxyarray" is a standard GEM input array which describes the
offsets and sizes of the rectangles within each memory area described by
the MFDB's that will be transfered.
An MFDB is a 10 word parameter block consisting of:
(2 words) memory address of block in question. Please note that if this
0, GEM will fill it in with the address of the current logical
screen.
(1 word ) block width in points.
(1 word ) block hieght in points.
(1 word ) block width in points/16 (words).
(1 word ) raster format flag. 1 indicates that the block is in a standard
format suitable for transfering between, say color and b&w, or
even to IBM PC GEM. 0 indicates that the block is device specific
(0 is usually used).
(1 word ) number of planes of color. (1 for mono).
(3 words) reserved, make them 0.
While I have never had to do memory to memory raster copies, I often
do memory to screen and the inverse, with no problem. Unless GEM is much more
brain damaged than anyone imagined, there should be no problem with memory to
memory.
Pete Santangeli
pete@utgpu
-----
^
\__ new address!!leavens@atari.UUCP (Alex Leavens) (03/18/87)
in article <8703170112.AA00614@ucbvax.Berkeley.EDU>, JANKOWSJ@UNION.BITNET says: > Is there any-hacker in this universe that can assist me in > finding information about working with the G.E.M. functions > > vro_cpyfm(handle,copy_logic,xy_array,psource_mfdb,pdest_mfdb); > vrt_cpyfm(handle,writing_mode,xy_array,psource_mfdb,pdest,col); > > These two functions are used primarily to copy memory from > screen device to ram-memory of visa-versa. However, I would > like to be able to copy from memory to memory or visa-versa. > Can this be accomplished with these functions or am I living in > a fantasy. Although I've never actually tried using these functions for memory to memory move, I don't see any reason why they shouldn't work. Several caveats are probably in order, however: 1) You'll probably want to use the monochrome raster copy. 2) Make _sure_ that your source and destination blocks the same size. 3) Make sure the pixel width of your raster is an even multiple of a word size (ie, 16). 4) You probably want to make sure that your source and destination rectangles don't overlap. Good luck!
pete@gpu.utcs.toronto.edu (03/20/87)
In article <672@atari.UUCP> leavens@atari.UUCP (Alex Leavens) writes: >in article <8703170112.AA00614@ucbvax.Berkeley.EDU>, JANKOWSJ@UNION.BITNET says: >> Is there any-hacker in this universe that can assist me in >> finding information about working with the G.E.M. functions > > 2) Make _sure_ that your source and destination blocks the > same size. Although I have yet to try it, According to Abacus, when given differing sizes of blocks, the system uses the size of the source block. > > 3) Make sure the pixel width of your raster is an even multiple > of a word size (ie, 16). This is only necesairy when speed is at a premium. The routines can handle bit-boundaries. This brings up an interesting point of interface theory. I have noticed that many GEM programs snap windows to 16bit boundaries. I fully understand the rational for this, but I don't think I agree with it. Though doing this increases speed, it very much reduces the quality of the user interface. Snapping takes away the feelinng that what you do is what you get. I would rather have the machine do EXACTLY what i want, and decide when running a program whether I want 16 bit boundaries. This is sort of a time- interface tradeoff. One of many in a windowing system! > > 4) You probably want to make sure that your source and destination > rectangles don't overlap. I can see no real reason for this. The routines are "smart" and can transfer over each other. > >Good luck! Yup! Pete Santangeli pete@utgpu
john@viper.UUCP (03/21/87)
In article <1987Mar18.014408.23167@gpu.utcs.toronto.edu> pete@gpu.utcs.UUCP (Peter Santangeli) writes: > >[well written description of vro_cpyform...] > >...(vro_cpyfm is similar, so I will stick with vro_cpyform).... Mind telling us what the differences are (if any)? > "pxyarray" is a standard GEM input array which describes the >offsets and sizes of the rectangles within each memory area described by >the MFDB's that will be transfered. You give enough details for all the -other- parameters that someone could use the function without needing further documention. How about describing pxyarray so other people will know enough to use it?? (Why tell people just enough to -almost- be able to use it?) --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
pete@utcsscb.UUCP (03/24/87)
In article <709@viper.UUCP> john@viper.UUCP (John Stanley) writes: >In article <1987Mar18.014408.23167@gpu.utcs.toronto.edu> >pete@gpu.utcs.UUCP (Peter Santangeli) writes: > > > >[well written description of vro_cpyform...] (Blush!) > > >...(vro_cpyfm is similar, so I will stick with vro_cpyform).... > >Mind telling us what the differences are (if any)? Sorry. vro_cpyfm is known of in the Abacus books as "copy raster, transparent" whereby vro_cpyform is "copy raster, opaque" vro_cpyfm takes one extra paramete r and is used for color systems. The parameter is the color index of the raster to be copied to. I have never used this, being a "mono person" for the most part. I believe it lets you move only one color plane of an image. > > "pxyarray" is a standard GEM input array which describes the > >offsets and sizes of the rectangles within each memory area described by > >the MFDB's that will be transfered. > >You give enough details for all the -other- parameters that someone could >use the function without needing further documention. How about describing >pxyarray so other people will know enough to use it?? The pxyarray is an integer array containing diagonally opposite corners of the source and destination rasters (blocks) as follows: xs1 ys1 xs2 ys2 xd1 yd1 xd2 yd2 (got that? :-) >(Why tell people just enough to -almost- be able to use it?) I (mistakenly) assumed that all that was needed was clarificationof the use of the calls. How can ANYONE do developpement on the system without AT LEAST the Abacus books? It is beyond me. > >--- >John Stanley (john@viper.UUCP) >Software Consultant - DynaSoft Systems >UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john Pete Santangeli pete@utgpu