sysop@tlvx.UUCP (SysOp) (07/08/90)
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
phorgan@cup.portal.com (Patrick John Horgan) (07/15/90)
Gary Wolfe, SYSOP of the Temporal Vortex BBS said: +..uflorida!unf7!tlvx!sysop, ..unf7!tlvx!sysop@bikini.cis.ufl.edu +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. I had an occasion to disassemble some of the graphics code awhile back, (the first RKM's were wrong about how to do blitting of lines so I checked to see how C= did it). I was pleased to recognize the Cohen-Sutherland Outcode algorithm used as the clipping algorithm. You can't do much better than that in a general clipping algorithm. It's amazing how they can do all that clipping constantly against damage-lists and still maintain such good performance. Way to got C=:) Patrick Horgan phorgan@cup.portal.com
forgeas@swinjm.UUCP (Jean-Michel Forgeas) (07/15/90)
In article <357@tlvx.UUCP> sysop@tlvx.UUCP (SysOp) writes: >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). Yes, because Intuition attach a layer with every window's RastPort. See Window->RPort->Layer >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? Yes you can. The graphics routines look at the RastPort->Layer, if it is NULL, they do not clip, if not NULL they get all information from the Layer like the clip rectangle, if it is partially obscured or not... >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. Clipping routines are fast, but they are designed for complex situations. In some case perhaps you can do faster clipping if you really need speed. >...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... Extracted from autodocs: "ClipBlit() performs the same function as BltBitMap(), except that it takes into account the Layers and ClipRects of the layer library..." So if you have your own clipping, use BltBitMap() instead of ClipBlit(). Autodocs tell that BltBitMap() is not optimised. If you have flicker and your BitMap is used exclusively by your program you could access directly the blitter to copy the array. >Gary Wolfe, SYSOP of the Temporal Vortex BBS -- \___/ Jean-Michel Forgeas \-/ cbmvax!cbmbsw!cbmsup!cbmfra!swinjm!forgeas | The Software Winery -^- And, where is the universe ?