ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/01/91)
I have an MS-DOS application that does animation using the multiple graphics pages of EGA/VGA cards. The program draws a picture to an invisible page, then makes that page visible, then draws the next picture to an invisible page, etc. The result is crisp animation. So how can this be done in Windows 3.0? Petzold's book says that Windows doesn't really support animation, but is there a method of doing acceptable one frame at a time animation? Which (if any) of the following schemes are viable: 1. For each frame, open a metafile, do all the graphics primitives, close the metafile and display it. Will this be fast enough for a moderately complex frame? 2. Hand craft graphics primitives (line, ellipse, etc) that draw into a bitmap (i.e. set bits in a bitmap). For each frame, get a blank bitmap, draw into it with the hand crafted primitives, then bitblt it to the screen. This seems rather painful! 3. Wait for the "multimedia extensions" in a subsequent version of Windows. Anyway, I'm looking forward to your opinions and suggestions. Eric Bergman-Terrell P.S. I have Borland C++ for Windows, and will probably get Turbo Pascal for Windows when it comes out...
bcw@rti.rti.org (Bruce Wright) (03/01/91)
In article <1991Feb28.230407.8337@isis.cs.du.edu>, ebergman@isis.cs.du.edu (Eric Bergman-Terrell) writes: > > I have an MS-DOS application that does animation using the multiple graphics > pages of EGA/VGA cards. The program draws a picture to an invisible page, > then makes that page visible, then draws the next picture to an invisible > page, etc. > > The result is crisp animation. > > So how can this be done in Windows 3.0? Petzold's book says that Windows > doesn't really support animation, but is there a method of doing acceptable > one frame at a time animation? > > Which (if any) of the following schemes are viable: > > 1. For each frame, open a metafile, do all the graphics primitives, > close the metafile and display it. Will this be fast enough for > a moderately complex frame? > > 2. Hand craft graphics primitives (line, ellipse, etc) that draw > into a bitmap (i.e. set bits in a bitmap). For each frame, get a > blank bitmap, draw into it with the hand crafted primitives, then > bitblt it to the screen. This seems rather painful! > > 3. Wait for the "multimedia extensions" in a subsequent version of > Windows. Metafiles are relatively slow - I wouldn't particularly recommend them for animation. If you don't want to wait for the "multimedia extensions" (assuming that they include additional support for animation, which sounds reasonable but not necessary), you will have to go with option #2. But it's not quite as bad as the way you make it sound. It's not that inefficient to use the Windows primitives (MoveTo, LineTo, Ellipse) and send the output to a bitmap rather than to the screen. So you don't have to hand craft the graphics primitives in order to get the functionality - Windows already has quite enough to do a lot of graphics manipulation without writing new routines. There are some limitations; the standard Windows routines can't draw an ellipse on an angle or draw Bezier or spline curves, for example. You _can_ simulate these objects with some pain and loss of efficiency by using standard Windows routines, but for some graphics applications you may need to code the real thing which, as you say, would be fairly painful (why didn't Microsoft put in a couple of these primitives???). The main problem with the approach is not that it's painful -- it's no more painful than drawing the same frame on the screen -- but with its efficiency. If you are careful to use efficient primitives it's OK, but some primitives are more expensive than others. Wide lines, for example, are much less efficient in proportion to thin lines than the ratio of their widths would at first blush indicate. Ellipses are not particularly efficient either. Non-rectangular clipping regions are horrible. But none of this is any _worse_ because it's going to a bitmap rather than to the screen. You may find it useful to write a few of your own functions if you have some special-purpose manipulations that you can do more efficiently than the general-purpose Windows routines, but you'll probably only have to do it for efficiency reasons and not because Windows doesn't have the functions required. If you can create some "objects" as bitmaps, and then bitblt the objects to the new frame bitmap or to the screen, this may be more efficient than drawing the "objects" from scratch every time; it sort of depends on what effect you are trying to achieve. Fortunately BitBlt is pretty efficient (though the same thing can't be said for StretchBlt). You can arrange to draw on a bitmap by doing a CreateCompatibleBitmap to get a bitmap compatible with the screen, a CreateCompatibleDC to create a Memory Device Context for drawing, and doing a SelectObject to select the bitmap into the Memory Device Context. When you are through, you delete the Memory Device Context with DeleteDC, and you are left with a bitmap that you can blt with to your heart's content. Petzold's book gives complete details on how to put these functions together, and is somewhat more lucid about how they fit together than the Windows SDK manuals are (so what else is new?). He doesn't go into details on how to do animation with them, mostly because this isn't very sophisticated animation. But you can certainly do a limited animation with these routines without enormous difficulties. Bruce C. Wright
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/04/91)
Thanks for the very useful information. I had no idea that one could specify that a bitmap (rather than the screen) serve as the implicit destination of Windows graphics primitives. I'll definitely give it a try. The animation I'm interested in is rather rudimentary, so it'll probably work fine. Terrell