Path: utzoo!utgpu!water!watmath!clyde!mcdchg!chinet!att-ih!pacbell!ames!ncar!noao!ut-sally!mothra!bryan From: bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) Newsgroups: comp.sys.amiga.tech Subject: Re: Fixing flicker, & future frame rate issues Message-ID: <11226@ut-sally.UUCP> Date: 13 Apr 88 03:17:06 GMT References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8557@agate.BERKELEY.EDU> <11196@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <11204@ut-sally.UUCP> <8651@agate.BERKELEY.EDU> Sender: news@ut-sally.UUCP Reply-To: bryan@mothra.cs.utexas.edu Organization: Spam Detection & Removal Squad, Austin, TX Spam-Content: High But Declining Path: utzoo!utgpu!water!watmath!clyde!mcdchg!chinet!att-ih!pacbell!ames!ncar!noao!ut-sally!mothra!bryan From: bryan@mothra.cs.utexas.edu (Bryan Bayerdorffer) Newsgroups: comp.sys.amiga.tech Subject: Re: Fixing flicker, & future frame rate issues Message-ID: <11226@ut-sally.UUCP> Date: 13 Apr 88 03:17:06 GMT References: <11157@ut-sally.UUCP> <8528@agate.BERKELEY.EDU> <11182@ut-sally.UUCP> <8557@agate.BERKELEY.EDU> <11196@ut-sally.UUCP> <8577@agate.BERKELEY.EDU> <11204@ut-sally.UUCP> <8651@agate.BERKELEY.EDU> Sender: news@ut-sally.UUCP Reply-To: bryan@mothra.cs.utexas.edu Organization: Spam Detection & Removal Squad, Austin, TX In article <8651@agate.BERKELEY.EDU> doug@eris.UUCP (Doug Merritt) writes: =-Ah. Ok, so Flicker Fixer *is* doing it wrong (presumably because of the =-extra expense of doing it right). Good, we've resolved one point. =- Yes, and this was the one and only point of my original article. Now, who's going to build one that does it right, and who's going to buy my fF when it come out? By the way, 'flickerFixer' is really the way MicroWay spells it, lest you all think that I can't type. Hence my abbreviation, 'fF'. =-> [...] convince anyone that DMAing a screen's worth of data every 1/60th sec is =->in any way the same as changing an offset at random intervals. [...] =->And lest you try to say that such an update is a frame, too: no, it is not, =->because you don't HAVE to update the whole picture, only the parts that have =->changed. =- =-I guess if you DMA *portions* of the RAM to the display at arbitrarily =-small intervals rather than at a fixed display rate, then the word "frame" =-becomes inappropriate...hmmm...interesting idea. *That* was what I was =-missing in my previous analysis. I like it! =- No, read that again, and recall that all of memory is ALSO a display device, just with a limited part visible at anytime, and the coordinates of that 'ViewPort' (now where did he get that word?) given by a pair of base registers. That means no DMA at all, ONLY writing to memory. Like it even better now? =->=-> Yes, yes, NOTHING is truly continuous on an arbitrarily small scale. =->=- [...] problem with phrasing "points to be drawn", because to me that means =->=-pixels. Maybe not to you? =-> And *I* don't want to use that phrase at all! That's the whole point! =- =-Maybe it's just a question of terminology? I tend to think of grains in =-film as being more or less the same as pixels. It would seem that you =-consider that inappropriate. No problem. =-But what kind of mechanism do you have in mind? Would it be something =-similar to, say, outputting an (x,y) coordinate specified as two =-floats (along with perhaps a dot-size), and the "film-grain-equivalent" =-(or many of them for a macroscopic dot) near the center of that =-coordinate is what is addressed? If so, ok...again a nice idea. =-I can throw away the terminology "pixel == film grain" for that purpose. =- Yes, it's a question of terminology, but it's not arbitrary. There are good reasons why the two terms mean different things: While it is true that both define a lower bound on resolution (though pixels are more uniform), the important difference is that when you draw something on a display that has pixels, you have to color EACH ONE individually. Someone mentioned vector displays in another article. I didn't want to get that specific, but it illustrates the point. When you draw a line on a vector display, all you specify are the endpoints. Does the display have grains? Yes. Does it have pixels? NO. I explained the mechanism I have in mind. Once again: everything is specified as a triangular area, a set of three coordinate pairs. If you want a line, make two of the points the same. If you want a point, make all three the same. The grain size may be determined by the arithmetic precision of the coordinates, or by the physical medium. But there are no pixels. ______________________________________________________________________________ /_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/_____/ |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____| _No dark sarcasm in the classroom|_____|_____|_____|_____|_____|_____|_____|___ |____Teachers leave the kids alone__|_____|_____|bryan@mothra.cs.utexas.edu___| ___|_____|_____|_____|___{ihnp4,seismo,...}!ut-sally!mothra.cs.utexas.edu!bryan |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|