Path: utzoo!attcan!uunet!cbmvax!rutgers!mephisto!uflorida!unf7!tlvx!sysop
From: sysop@tlvx.UUCP (SysOp)
Newsgroups: comp.sys.amiga.tech
Subject: Graphics, clipping, and double-buffering in a window
Keywords: graphics rastport C++
Message-ID: <357@tlvx.UUCP>
Date: 7 Jul 90 20:35:24 GMT
Organization: Temporal Vortex BBS of Jacksonville, Florida
Lines: 53

Recently I bought Lattice C++, and have been playing around with the graphics.
Right now, I'm trying to learn C++ (I'm familiar with C), while making
something at least somewhat interesting.

What I'm trying to do at the moment is make a double-buffered display.
If I draw into a window's rastport, I can go beyondthe edges (it'll clip
for me).  If I create my own bitmap & rastport, it doesn't seem to be
clipping.  I'm sure this is obvious to someone.  :-)  Can I have the OS
clip my separate rastport for me?

How slow are the built-in clipping routines?  I could always have my own
draw function which clips the x & y before calling Draw(), but I'd rather
use the system functions if there's nothing wrong with the performance.

What I've done so far is to use the double-buffering as mentioned in
Robert Peck's Programmer's Guide to the Amiga (great book!), and using
ClipBlit to copy from the spare rp to the window's.  This was the most
successful thing I tried, but I still get a flicker, even though I do
a WaitBOF() before I do the ClipBlit.  Since the window is relatively small,
and there's already flicker (and therefore apparently not enough time to
transfer the contents of that rastport), I assume there's a better way to
do this.  What I'd REALLY like is just to be able to swap just one little
pointer back and forth instead of copying gobs of data (seems inefficient).


While I'm here and posting, my initial reaction is positive to C++, although
I haven't done much with it yet.  The features of C++ can make for some
nice-looking simple programs, though.  For instance, if rp is your rastport *:

Point saveit = *rp;  //save current position
*rp = Point(50,100);  // set current position to x=50, y=100
*rp << "Easy printing!";
*rp = savit;  // restore old pos

I dunno, maybe it isn't something to get TOO excited over, but it seems like
it should make things a bit cleaner, neater.  In what I'd like to do (a simple
game), I think it'll be impressive.  If I do it right, I'll have shapes in
derived classes, and a matrix class, and it should look rather clean.  I also
like the emphasis on using delete if you use new.  Hopefully C++ will help
in deallocating everything.  One problem I can see that isn't solved auto-
matically (not that it needs to be) is not checking the return code from
a function to see if it really did work.  (I really hate running a program,
and it asks for a disk or something, and I'd rather not!  The programmer
really should check these things.  Sure, it's a picky point, but when I
get a guru because of it, it's annoying.  Maybe if the programmer just HAD
to have that disk, he could disable the cancel option... ;-)  Seriously, if
that was the case, the programmer could keep looping, so there's still no
excuse.)  Anyway, you can't have enough good programming practices.  Heh.

Thanks for any help with the graphics.
--
Gary Wolfe, SYSOP of the Temporal Vortex BBS
..uflorida!unf7!tlvx!sysop, ..unf7!tlvx!sysop@bikini.cis.ufl.edu