CompuServe Thread

Jeff, I'm sick of posting this stuff in the "irony" thread. Let's start our own thread for this "public demo" group, even if it does just turn out to be the two of us. You'll note I've already done this. > Yes, exactly, I fiqure the extra calcs on a few points (for aspect > adjustments) would be quicker than the slower pixel writes in Mode-X. Of > course if there are any very complex objects, things could slow down. Well, let's discuss this Mode-X thing a little. I've heard it said that Mode-X is slower than Mode 13h on many occasions. Although there is some truth in this, I think that it's less true than many people think. From my pespective, there are 3 major reasons that Mode-X might be slower than Mode 13h: 1. "Standard" Mode-X is 320×240 while Mode 13h is 320×200. More pixels, more time. Yeah, true (duh!) but in that case, how about 80×50 text mode? You could still do 16 colors, and that would be BLINDING fast! Oh, it's lower resolution? Too bad! Let's forget this one. Besides, if you want, there is a 320×200 X-Mode too (supported in my XUNIT). 2. Mode-X is slower because of the need to set the mask register with OUTS to select which pixel of the 4 you want to write. This one is true, but it's only a big problem if you program it stupidly. I couldn't believe that Michael Abrash, who first wrote the articles in Doctor Dobb's Journal which got everyone started on Mode-X, missed this obvious optimization himself, and freely admits in in a recent PC Techniques. If you program it stupidly by using (for example) the XPutPix routine from my library to draw every pixel, then the frame rate will be DOG-slow. This is because, to fill an entire screen, you do 76800 OUTs per screen, plus all the multiplies and shifts etc. required to figure out which bit needs to be set. Especially because of the slow PC bus, this drags everything down dramatically. The alternative is drawing the screen in vertical stripes, reducing the number of OUTs to 320 per screen. This is pretty manageable, and doesn't slow things down that badly at all. This is the way the XVert routine in XUNIT works, by the way. In addition (as I think you know), you can get speedups out of Mode-X if you have multiple pixels in a row that are the same color, since you can set up to 8 at a time with a single 16-bit OUT (yes, *8* at a time, not 4!). Of course, you have to do so much pre-processing to decide if this can be done, it may not be worth it. It also lets out being able to do texture-mapping or Gouroud shading, so this ability is probably only of minimal usefulness. However, if you think about it, it DOES really speed up a full-screen clear, and you'll notice that my XClrScr and XClrVal routines make use of this. (I don't take credit for these, they come directly from the Abrash articles). For some things, though (like a DOOM-type game for example), clearing the screen between frames isn't necessary, since you re-write every pixel on the screen for every frame anyway, so once again it just depends on what you're doing. 3. You can't do 16-bit writes in Mode-X, only 8-bits, so since just about everyone has a 16-bit card these days, this slows you down by 2X. In Mode 13h, you can put 2 adjacent 8-bit pixel values into AX and OUT them both at once. This one's tougher, but I THINK I have an answer for it. It works on my Cirrus card, but I don't know if it works on all VGA's. Anybody who has any knowledge of this is welcome to rebut me … Actually, you CAN load 2 8-bit pixel values into AL and AH, then OUT them both at once. The only problem is that they will come out 4 pixels apart from each other. This is relatively ugly, BUT … Suppose you build your picture in RAM like the standard 320×200 offscreen buffer. Then you can simply organize the pixels such that you can later transfer them from RAM to screen in 16-bit chunks because they've already been organized 4-pixels apart when they were written to the offpage buffer. "But," I hear the skeptics say, "now you've bought all the problems of Mode 13. Why bother with Mode-X at all if you're not going to do page flipping in Mode-X or 4-pixel at a time page-to-page transfers?" Two reasons: 1:1 aspect ratio, and higher X-Mode resolutions (there are several cool 256-color alternative resolutions, including 376×282 and 400×300). If you're trying to so spherical texture-mapping, you'll find that the 1.2:1 ratio is a giant pain in the butt. > Wu??? Is it an optimized Bresenham's? Or a completely new approach to line > draws? The latter. If you can lay your hands on a copy of Graphics Gems (the first one), it's described on page 101. Or, the Aug/Sept issue of PC Techniques has an article on Wu's algorithm (page 73), though it's an extension of the basic algorithm that also does on-the-fly anti-aliasing. > Right now I want to draw a 3D globe There's a great demo called "Planets" available on the Internet, which features 3 texture-mapped planets bouncing around on the screen and rotating in real-time. This demo also includes the source code (in C of course), and a detailed tutorial which goes into the math he used. I've got a (fairly) good implementation of his algorithm in Pascal, and I've added scaling the bitmap. It uses my XUNIT library (of course) and includes an algorithm which darkens the bitmap as a function of the direction the light hits the globe. If you're interested, I could upload either or both of these. Let me know. I've also got a cheezy cobbled-together "land-mass generator" which attempts to make Earth-type world bitmaps built in. > I had been thinking of this myself as well, the other advantage to triangles > is that they are always triangles no matter how they're rotated in 3 space > (except on edge, where they become lines), as opposed to squares, which > become trapesoids. This means that you can build a triangle engine which > would work in all situations. Just a thought. Maybe it would be worthwhile building a REALLY optimized triangle generator and then just using solids that lend themselves well to this type of engine. It could always be expanded to arbitrary polygons later. Also, while on this subject, FYI, the spherical texture-mapper I discussed before uses a lookup table, not a polygon or triangle engine. This makes it blazing fast, but limits the directions you can rotate the sphere when viewing it. > How's your "water" stuff coming along. I used to be a chem major, so if > you need any reference materials (I have a CRC among other things) let > me know. Thanks for the offer, but I have a buddy who's a major chem fan and has loads of reference material on the subject. I suppose I could upload it the way it is now, since the side-file is just a "trajectory table" which contains the positions of the atoms versus time, much like the tables used in spaceship flybys in many demos. I guess it's a "legal" way to write a demo. It also has the advantage of being able to play back several chemical animation files, including a fairly cool salt crystal in addition to the water molecule. The one problem you might have is … didn't you say you have only a 286? It will run on that, but it only runs at 7 frames per second on a 386/16. It will probably be slower yet on a 286, depending on the speed. However, I guess if you had a choice, you'd have upgraded by now, right? It peps along at 30 frames per second on my 486/66, and at 60fps on a Pentium/VLB. Regards, Fred Trafton