On Tuesday 12 September 2006 22:32, Timothy Miller wrote: > > So YUYV isn't the format. It's an encoding that we could accept. > For all we care, it could be YYUV. Or UVUV, where Y comes later. In > the latter case, you send |X|/4 UVUV 32-bit words. That's |X|/2 > encodings of U and V together, and they apply to pairs of scanlines. > Later, when you send the Y's (one for each pixel), the GPU knows > where to go to fetch the U and V values sent earlier. > > One way to handle this is to use the texture unit. You're going to > fill a rectangle with pixels. First, you upload all of the U and V > values to a texture. When you're doing that, the GPU is implicitly > storing UVuv words as pairs of words, XXUV and XXuv. What you create > is a 1/4 scale (1/2 x 1/2) image that has U values stored in G and V > values stored in B.
<more detail removed> Timothy, did you read my post from Saturday? I proposed something very similar, but using the VGA nanocontroller to do the YUV->RGB conversion. It's there anyway, already contains all the addressing logic, and there's a remarkable conceptual similarity between converting VGA text surfaces into RGB and converting YUV surfaces into RGB. It was a rather long post and there were no replies, but I still think it's an interesting idea and I would like some opinions from you all... Lourens
pgpC3L2yeVXnP.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
