revision 239:e5cd6b2d4586
summary |
tree |
shortlog |
changelog |
graph |
changeset |
raw | bz2 | zip | gz changeset | 239:e5cd6b2d4586 |
parent | 238:6af4cc93b137 |
child | 240:9ae4bd697292 |
author | nkeynes |
date | Fri Dec 15 10:17:30 2006 +0000 (17 years ago) |
Add some explanatory comments as to how this stuff is supposed to work
1.1 --- a/src/pvr2/rendbkg.c Fri Dec 15 10:17:08 2006 +00001.2 +++ b/src/pvr2/rendbkg.c Fri Dec 15 10:17:30 2006 +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.
.