On 1/28/07, Dennis Schridde <[EMAIL PROTECTED]> wrote:

Am Sonntag, 28. Januar 2007 schrieb The Watermelon:

Idea is good.

Some notes:
- Please create patches which just comment out something. Remove it or
don't
remove it. We can allways revert using SVN and in the patch we see what
you
changed, too, so I see really no point to add huge amounts of commented
out
code.
- Why did you remove the GPL header?
- I am not sure whether changing those x,y,z parts to Vector3 is good.
You'd
have to change u,v to Vector2i, too. And if you don't change them, but
leave
them as is, you have the chance to directly pass them to GL, without
having
to fear that one or the other might include some additional fields which
would mess up the memory structure or alignment. Is there any benefit in
this
change? I mean, can we pass the pos part directly to GL in some place, is
the
code easier to read with this? Otherwise I vote for PIEVERTEX staying
independend from Vector3...

I failed to fix patch to piedraw.c in this one,I reverted back to a wrong
rev of piedraw.c when making those changes,and it removed the GPL header and
added some removed functions...


Vector3 is always easier to read than some non-standardized names like
'x,y,z' 'sx,sy,sz' and some weird 'd3dx,d3dy,d3dz',it also saves you a bunch
of Vector_Set functions in draw functions.Passing vector2 or vector3 struct
directly to glVertex2fv or glVertex3fv as glFloat[2]/glFloat[3] pointer is
generally faster than passing and copying individual values for x,y,z to
glVertex2f/glVertex3f.

Example:(block of function pie_Polygon)
sx,sy,sz version:

*   fVector p1, p2, p3, v1, v2, n;
  float l;*

*   fVector_Set(&p1, pVrts[0].sx, pVrts[0].sy, pVrts[0].sz);
  fVector_Set(&p2, pVrts[1].sx, pVrts[1].sy, pVrts[1].sz);
  fVector_Set(&p3, pVrts[2].sx, pVrts[2].sy, pVrts[2].sz);
  fVector_Sub(&v1, &p3, &p1);
  fVector_Sub(&v2, &p2, &p1);
  fVector_CP(&n, &v1, &v2);
  l = 1.0;*

*   glNormal3f(n.x*l, n.y*l, n.z*l);
 }
}
for (i = 0; i < numVerts; i++) {
 glColor4ub(pVrts[i].light.byte.r, pVrts[i].light.byte.g,
pVrts[i].light.byte.b, pVrts[i].light.byte.a);
 glTexCoord2f(pVrts[i].tu, pVrts[i].tv+texture_offset);
 glVertex3f(pVrts[i].sx, pVrts[i].sy, pVrts[i].sz);
}*

vector3 version:

*   Vector3f v1, v2, n;
  float l;**
  Vector3f_Sub(&v1, &pVrt[2].pos, &pVrt[0].pos);
  Vector3f_Sub(&v2, &pVrt[1].pos, &pVrt[0].pos);
  Vector3f_CP(&n, &v1, &v2);
  l = 1.0;*

*   glNormal3f(n.x*l, n.y*l, n.z*l);  }
}
for (i = 0; i < numVerts; i++) {
 glColor4ub(pVrts[i].light.byte.r, pVrts[i].light.byte.g,
pVrts[i].light.byte.b, pVrts[i].light.byte.a);
 glTexCoord2f(pVrts[i].tu, pVrts[i].tv+texture_offset);
 glVertex3fv(&pVrts[i].pos);
}*
Texture coords u,v is not very suitable for Vector2i,cos it always appends
texture_offset to the 'v' when passing to gl functions.

I will fix these problems and resend the patch...
_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev

Reply via email to