filename | src/pvr2/rendbkg.c |
changeset | 239:e5cd6b2d4586 |
prev | 223:f6c28fa9076b |
next | 331:a6048d3a9a79 |
author | nkeynes |
date | Thu Jan 25 10:16:32 2007 +0000 (17 years ago) |
permissions | -rw-r--r-- |
last change | Move PVR2 dma handling (0x10000000-0x13FFFFFF) into pvr2mem.c, minor register cleanups in asic.c |
file | annotate | diff | log | raw |
1.1 --- a/src/pvr2/rendbkg.c Tue Sep 12 12:16:36 2006 +00001.2 +++ b/src/pvr2/rendbkg.c Thu Jan 25 10:16:32 2007 +00001.3 @@ -1,11 +1,22 @@1.4 /**1.5 - * $Id: rendbkg.c,v 1.3 2006-09-12 12:16:36 nkeynes Exp $1.6 + * $Id: rendbkg.c,v 1.4 2006-12-15 10:17:30 nkeynes Exp $1.7 *1.8 * PVR2 background renderer.1.9 *1.10 * Yes, it uses the same basic data structure. Yes, it needs to be handled1.11 * completely differently.1.12 *1.13 + * PVR2 backgrounds are defined as a set of three fully specified vertexes,1.14 + * stored in compiled-vertex format. The vertexes form a triangle which is1.15 + * rendered in the normal fashion. Points outside the triangle are rendered1.16 + * by extrapolating from the gradients established by the triangle, giving1.17 + * an overall smooth gradient across the background. Points are colour-clamped1.18 + * prior to output to the buffer.1.19 + *1.20 + * As a special case, if all three points lie on the same line (or are the same1.21 + * point, the third point is used by itself to define the entire buffer (ie1.22 + * effectively a solid colour).1.23 + *1.24 * Note: this would be really simple if GL did unclamped colour interpolation1.25 * but it doesn't (portably), which makes this roughly 2 orders of magnitude1.26 * more complicated than it otherwise would be.
.