jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (02/16/89)
I've been using the GEMFAST AES/VDI defs to hack up a color version of UW. Most stuff seems to behave pretty well, with the exception of the vrt_cpyfm function. According to the PROGEM docs, vro_cpyfm and vrt_cpyfm take as their alu (mode) arg a short valued 0..15, ie one of the values listed as "Raster op codes" in LINEA.H, or "Bitblt rules" in GEMFAST.H. However, after much debugging and head-scratching, it seems that what vrt_cpyfm really wants there is 1..4, ie one of the values listed as "graphics drawing modes". Has anybody used this stuff in the documented fashion? Is the doc wrong? Is the GEMFAST stuff wrong? Is GEM confused? Am I confused? Any information appreciated.
soohoo@cory.Berkeley.EDU (Ken "nmn" Soohoo) (02/17/89)
In regards to the VDI question about vrt_cpyfm(), I'm just going to open my developer's tome here and copy the definition out: vrt_cpyfm(handle, wr_mode, pxy, psrcMFDB, pdesMFDB, color_index) Here's the sizes of these things: handle, and wr_mode are WORDs (i.e. 2 bytes), wr_mode is the same as follows: 1 - replace, 2 - transparent, 3 - XOR, 4 - Rev Transparent color_index is an array of two WORDs for foreground and background color. pxy is an array of corner points, eight of them. psrcMFDB and pdesMFDB are pointers to structures. hope this helps! --Kenneth Soohoo (soohoo@cory.Berkeley.Edu) Atari 400/800/600xl/800xl/1200/130xe/65xe/xe game/7800, 1040ST/MEGA hacker "It could be worse, you could get hit by a truck..." My opinions are my OWN, _not_ necessarily Atari's.