Search
lxdream.org :: lxdream :: r239:e5cd6b2d4586
lxdream 0.9.1
released Jun 29
Download Now
changeset239:e5cd6b2d4586
parent238:6af4cc93b137
child240:9ae4bd697292
authornkeynes
dateFri Dec 15 10:17:30 2006 +0000 (13 years ago)
Add some explanatory comments as to how this stuff is supposed to work
src/pvr2/rendbkg.c
1.1 --- a/src/pvr2/rendbkg.c Fri Dec 15 10:17:08 2006 +0000
1.2 +++ b/src/pvr2/rendbkg.c Fri Dec 15 10:17:30 2006 +0000
1.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 handled
1.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 is
1.15 + * rendered in the normal fashion. Points outside the triangle are rendered
1.16 + * by extrapolating from the gradients established by the triangle, giving
1.17 + * an overall smooth gradient across the background. Points are colour-clamped
1.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 same
1.21 + * point, the third point is used by itself to define the entire buffer (ie
1.22 + * effectively a solid colour).
1.23 + *
1.24 * Note: this would be really simple if GL did unclamped colour interpolation
1.25 * but it doesn't (portably), which makes this roughly 2 orders of magnitude
1.26 * more complicated than it otherwise would be.
.