wjc@hoswjc.ATT.COM (Bill Carpenter) (10/16/89)
Now that I've had a chance to putter around with Brian Botton's video
ram access board for the UNIXpc, I realize that it would be nice to
have a user space bitblt routine.
The ioctl(WIOCRASTOP) has some drawbacks:
(1) it still requires system call overhead to do the raster operation
(2) it needs a window file descriptor, even if it's not involved in
the raster operation
(3) it apparently does sanity checks on the address, so even though
blasting into video ram addresses is legit once you have the
hardware mod, the ioctl() won't do it for you
So, who has some nice, post-able, fairly general bitblt routine?
Given that, I'd be able to post a UNIXpc version of the infamous
"crabs" program.
--
Bill Carpenter att!ho5cad!wjc or attmail!billhjespers@attcan.UUCP (Hans Jespersen) (10/17/89)
From article <WJC.89Oct16104701@hoswjc.hoswjc.ATT.COM>, by wjc@hoswjc.ATT.COM (Bill Carpenter): > ... > So, who has some nice, post-able, fairly general bitblt routine? > Given that, I'd be able to post a UNIXpc version of the infamous > "crabs" program. I'm currently working on a dmd library to enable me to compile and run programs written for the 5620/630/730 DMD environment. The bitblt(3R) routine is just one of many necessary graphics routines (ie. box(3R), circle(3L), ellipse(3L), etc.) as well as all the font, and mouse manipulation routines. I started hoping that I could simply map all the bitblt() parameters over to the coresponding wrastop() parameters but the structure of Bitmap is all backwards. Even provided the 630 bitplanes are 16 bit Words the bits are a mirror image of the bitplanes on the 3b1. Therefore my bitblt() has to check the source and destination bitplanes and if they are in display memory the Words have to be flipped, otherwise you will get unrecognizable results. Even with the bits flipped, the results can be disappointing since the 630 has a nice 1:1 aspect ratio and the 3b1 has a horribly scewed 7:3 (approx) ratio. Getting bitblt() ported is a nice first step and will allow a lot of 630 demo stuff to run ( should be enough for "crabs" ) but in order to use some of the REALLY neat stuff that the labs are putting out for DMD terminals it would be advantageous to have the complete DMD environment. Then the next step would be to get 'layers' up, perhaps through the use of the existing window drivers. -- Hans Jespersen UUCP: uunet!attcan!hjespers AT&T Canada Inc. Toronto, Ontario PS. The ultimate would be to get "gebaca" running on the 3b1. This has got to be one of the all time best arcade style games I've ever played but alas, it only runs on DMD terminals.
dean@image.soe.clarkson.edu (Dean Swan) (10/19/89)
Along the lines of RAM access, I need to plot waveforms and such in a window.
I wrote a line drawing routine that calls WRASTOP, but it is painfully slow.
I suspect that it is because WRASTOP issues a refresh to the window, before
doing a blit evertime it is called. I've thought about reimplementing it to
build a bitmap in user memory of the line and then just doing a single WRASTOP
call to copy it to the window, but that seems like an awful lot of work just
to draw a line. Can anyone help?
-Dean Swan
dean@sun.soe.clarkson.edu
P.S. This is on a 7300. Also, pleas e-mail any posted replys. I don't
always get to check the news often enough and sometimes miss it.
Thanx in advance...... :-)hjespers@attcan.UUCP (Hans Jespersen) (10/20/89)
dean@image.soe.clarkson.edu (Dean Swan): > Along the lines of RAM access, I need to plot waveforms and such in a window. > I wrote a line drawing routine that calls WRASTOP, but it is painfully slow. > I suspect that it is because WRASTOP issues a refresh to the window, before > doing a blit evertime it is called. I've thought about reimplementing it to > build a bitmap in user memory of the line and then just doing a single WRASTOP > call to copy it to the window, but that seems like an awful lot of work just > to draw a line. Can anyone help? WRASTOP will accept destination bitmaps (dstbase) other than the screen. You define an array like this: unsigned short Bitmap[WIDTH * HEIGHT / 16]; and then use WRASTOP like this: /* repeat until Bitmap is what you want on the screen */ for(;;){ wrastop( w, srcbase, srcwidth, Bitmap, WIDTH/8, srcx, srcy, dstx, dsty, width, height, srcop, dstop, pattern); } /* Wack Bitmap onto screen */ wrastop( w, Bitmap, WIDTH/8, 0, 0, 0, 0, 0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, SRCSRC, DSTSRC, 0); BUT, if all you are doing is building a line it would be even better to just fiddle with the bits in Bitmap[] directly. (ie. Bitmap[offset] |= 0x0001) and then print the Bitmap on the screen. -- Hans Jespersen UUCP: uunet!attcan!hjespers AT&T Canada Inc. Toronto, Ontario "Yabba Dabba Doo" -- F. Flintstone
mjm@atti07.ATT.COM (Michael Matthews x7776) (10/21/89)
In article <1989Oct19.161204.3420@sun.soe.clarkson.edu>, dean@image.soe.clarkson.edu (Dean Swan) writes: > Along the lines of RAM access, I need to plot waveforms and such in a window. > I wrote a line drawing routine that calls WRASTOP, but it is painfully slow. > I suspect that it is because WRASTOP issues a refresh to the window, before > doing a blit evertime it is called. I've thought about reimplementing it to > build a bitmap in user memory of the line and then just doing a single WRASTOP > call to copy it to the window, but that seems like an awful lot of work just > to draw a line. Can anyone help? > The wrastop() call takes as much overhead regardless of the surface screen size updated. Why would it be more work to optimize? You already have the solution: A 'short' array in memory can be setup identical to the screen. Paint the screen in memory and when finished do one wrastop() much like a curses refresh(). It will be incalcuably faster. Mike Matthews ATT International