Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA16056 (5.65c/IDA-1.4.4 for ); Mon, 21 Oct 1991 22:08:50 -0500 Received: by watserv1.uwaterloo.ca id ; Mon, 21 Oct 91 23:04:44 -0400 Date: Mon, 21 Oct 91 23:04:44 -0400 From: Dave Stampe-Psy+Eng Message-Id: <9110220304.AA01211@watserv1.uwaterloo.ca> To: glove-list@karazm.math.uh.edu Lance replied to a lot of my postings, so instead of a lot of little postings, I'll try to handle them in one loner one: From: Lance Norskog >Dave Stamp says: > >> I think I see the problem here. The difference is between the IBM and Amiga >> designs. Any real graphics work on the IBM PC requires multiple I/O space >> accesses with inportb() and ouportb() type routines. Since most of the >> available C compilers do not replace these with inline code, this results >> in much slower operation than with assembly code. Also, many of the good >> instructions on the 80x86 (such as LOOP or REP STOSB) are not used by >> compilers. Again, assembly code is the only solution. >Nope! The IBM PC bus was designed to be cheap, and support text. >It was not designed with NTSC video bandwidth in mind, while the >Amiga was. The hardware is at fault, not the software. I was referring to programming style as dictated _by_ the hardware, not the hardware per se. >The PC VR software is going to have use scan-line techniques, or >paint in real RAM and copy that into the VGA frame buffer. Multiple >touches of the same pixel would be the kiss of death. Exactly what I plan to do: use scan-line algorithms. They have a big advantage over other methods in that they write each pixel once and degrade gracefully with increasing numbers of polys. The amount of optimization possible is pretty awesome. Also, since you're drawing each poly once, Gourand shading and texture mapping become less expensive. Copying a buffer to the VGA card wastes more time than it saves unless you're doing really wierd things that require multiple accesses to each pixel. In this case, it's not warranted. >Actually, the 8514/A clone cards are appearing mass-market for $500 >from Western Digital etc. These things include a raft of 2D graphics >commands which you just poke at it and go away. There are a couple of problems with the 8514/A cards. First, using new hardware violates the cheapness constraint on the system: less people can get involved. Second, as you pointed out, flexibility is less: video modes can't be chosen easily. Third, when you consider the time used up stuffing the command FIFO versus the draw time, the performance advantage for a scan-line renderer is pretty low, as you're just drawing horizontal line segments. Of course, if you're doing wireframe... 300 polys in 100 mS... or was it my database size of 10,000 polys?> >I think you're off by an order or two of magnitude. >But I have no hard numbers. No, that's the beauty of the algorithm I'm working on! I should get AT LEAST 200 polys per rendering cycle, and if I use 320x200x16 mode, it takes about 50 mS-- plenty of time for the poly database processing. I'm off by AT MOST a factor of 2. >You should also consider that background walls and floors can be done >by pre-rendering them onto pixmaps, then resampling the pixmaps >onto the screen first. Then, start drawing your wire-frames or >filled polygons. Yes, it is a possibility, IF you're using textures. But this requires "touching" each pixel twice... Perhaps these areas could be copied out of a buffer by the scan-line renderer where no polys cover. >Again, check out BSP in the Computer Graphics book, and >the ASP in Graphics Interface '90. These are the front-runners >for repetitive polygonal database update methods. I have checked out these methods and, IMHO, they are not as useful as they appear. They are best used to depth-sort polys for schemes that draw ALL the polys over and over again. They can help with object- level rejection in the "front end" of the renderer, but no further. The keyword is "repetitive" and we can't afford that on this machine. I suspect even the Amiga starts getting into problems, as drawing a poly takes significant CPU intervention to keep the hardware fed with all those horizontal line commands that the Amiga's hardware supports. Plus, as soon as you go to Gourand shading or texture mapping, it all has to be done by the CPU anyway. < a comment on the proposed glove interface > >A tip: it will be much easier to get this stuff working right if >you encode the whole process, both hi-res-mode-init and the >polling loop, into a finite state machine. Your TSR can then >just do a case statement to decide what to do. It's a little >tougher to code than by hand, but it's the only way to fly >in an interrupt-driven environment. This isn't TSR code though: nor is it a device driver. This is to be linked into a C program. There really IS only one path through interrupts, with early termination if the glove isn't ready yet. I don't understand _why_ a state machine should be tougher-- it's just an implementation decision after all. Thanks for the feedback. Can you please include at least the gist of the original message? I had trouble figuring out which one you were replying to. Ahh, the perils of asynchrony (B_{). -------------------------------------------------------------------------- | My life is Hardware, | | | my destiny is Software, | Dave Stampe | | my CPU is Wetware... | | | Anybody got a SDB I can borrow? | dstamp@watserv1.uwaterloo.ca | __________________________________________________________________________