qf/newtree
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/newtree synced 2024-11-22 04:01:17 +00:00
Code Issues Projects Releases Packages Wiki Activity
newtree/source/gl_sky_clip.c

773 lines
19 KiB
C
Raw Normal View History

split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
/*
gl_sky_clip.c
sky polygons
Copyright (C) 1996-1997 Id Software, Inc.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to:
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
$Id$
*/
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
#include audit
2000-12-30 02:16:36 +00:00
#ifdef HAVE_STRING_H
Whitespace.
2001-01-26 06:10:50 +00:00
# include <string.h>
#include audit
2000-12-30 02:16:36 +00:00
#endif
#ifdef HAVE_STRINGS_H
Whitespace.
2001-01-26 06:10:50 +00:00
# include <strings.h>
#include audit
2000-12-30 02:16:36 +00:00
#endif
get MSVC back up and running again.
2001-01-11 08:43:11 +00:00
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
#include <stdarg.h>
try to insert the cube vertexen into the correct spot in the face poly vertex list.
2000-11-16 20:05:15 +00:00
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
#include "console.h"
#include "glquake.h"
use Sys_Error instead of abort
2000-11-16 23:00:35 +00:00
#include "sys.h"
cd_linux.c: fix silly #include booboo (Thanks, Scottie Shore) gl_sky_clip.c: bring in brighness the right way
2001-01-08 03:16:25 +00:00
#include "view.h"
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
extern qboolean skyloaded;
extern vec5_t skyvec[6][4];
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
/* cube face to sky texture offset conversion */
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
static const int skytex_offs[] = { 3, 0, 4, 1, 2, 5 };
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
/* clockwise loop through the cube faces adjoining the current face */
static const int face_loop[6][5] = {
{1, 2, 4, 5, 1},
{0, 5, 3, 2, 0},
{0, 1, 3, 4, 0},
{1, 5, 4, 2, 1},
{0, 2, 3, 5, 0},
{0, 4, 3, 1, 0},
};
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
fix up some comments (taking a break tonight, I guess:)
2000-11-21 07:49:58 +00:00
/* convert axis and face distance into face */
framed cube faces work now! :) clockwise polygon rules are very convenient (ccw would be just as good, it's the rule that counts:)
2000-11-18 06:44:08 +00:00
static const int faces_table[3][6] = {
{-1, 0, 0, -1, 3, 3},
{-1, 4, 4, -1, 1, 1},
{-1, 2, 2, -1, 5, 5},
};
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
this SHOULD take care of case 5.3. Find out when I get home :/
2000-12-01 19:57:33 +00:00
/* convert face magic bit mask to index into visit array */
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
static const int faces_bit_magic[] = { 2, 1, -1, 0, 3, -1, 4, -1 };
fix up some comments (taking a break tonight, I guess:)
2000-11-21 07:49:58 +00:00
/* axis the cube face cuts (also index into vec3_t and n % 3 for 0 <= n < 6) */
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
static const int face_axis[] = { 0, 1, 2, 0, 1, 2 };
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
/* offset on the axis the cube face cuts */
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
static const vec_t face_offset[] = { 1024, 1024, 1024, -1024, -1024, -1024 };
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
/* cube face */
struct face_def {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int tex; // texture to bind to
glpoly_t poly; // describe the polygon of this face
float verts[32][VERTEXSIZE];
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
};
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
struct visit_def {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int face; // face being visited
int leave; // vertex departed through
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
};
/* our cube */
struct box_def {
/* keep track of which cube faces we visit and in what order */
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
struct visit_def visited_faces[9];
int face_visits[6];
int face_count;
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
/* the cube faces */
struct face_def face[6];
};
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
/*
determine_face
return the face of the cube which v hits first
0 +x
1 +y
2 +z
3 -x
4 -y
5 -z
Also scales v so it touches that face.
*/
static int
determine_face (vec3_t v)
{
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
float a[3];
float m;
int i = 0;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
m = a[0] = fabs (v[0]);
a[1] = fabs (v[1]);
a[2] = fabs (v[2]);
if (a[1] > m) {
m = a[1];
i = 1;
}
if (a[2] > m) {
m = a[2];
i = 2;
}
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
if (!m) {
use Sys_Error instead of abort
2000-11-16 23:00:35 +00:00
Sys_Error ("%s speared by sky poly edge\n", name->string);
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
}
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
if (v[i] < 0)
i += 3;
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
VectorScale (v, 1024 / m, v);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
return i;
}
/*
find_intersect (for want of a better name)
finds the point of intersection of the plane formed by the eye and the two
points on the cube and the edge of the cube defined by the two faces.
Currently, this will break if the two points are not on adjoining cube
faces (ie either on opposing faces or the same face).
The equation for the point of intersection of a line and a plane is:
(x - p).n
y = x - _________ v
v.n
where n is the normal to the plane, p is a point on the plane, x is a
point on the line, and v is the direction vector of the line. n is found
by (x1 - e) cross (x2 - e) and p is taken to be e (e = eye coords) for
simplicity. However, because e is at 0,0,0, this simplifies to n = x1
cross x2 and p = 0,0,0, so the equation above simplifies to:
x.n
y = x - ___ v
v.n
*/
poly edge crossing FOUR (ouch, that was unexpected) cube faces partially taken care of. I have to fill in the incomplete faces (hmm, that will be interesting) and figure out why one corner in one of my test cases is sometimes set and sometimes not. Hmm, might be confused buy the enter/leave info from that edge.
2000-11-20 05:41:11 +00:00
static int
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
find_intersect (int face1, vec3_t x1, int face2, vec3_t x2, vec3_t y)
{
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
vec3_t n; // normal to the plane formed by the
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
// eye and the two points on the cube.
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
vec3_t x = { 0, 0, 0 }; // point on cube edge of adjoining
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
// faces. always on an axis plane.
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
vec3_t v = { 0, 0, 0 }; // direction vector of cube edge.
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
// always +ve
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
vec_t x_n, v_n; // x.n and v.n
int axis;
vec3_t t;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
replace face related % and / with table lookups. gives almost 50% speedup in set_vertex (but it's not called that often) and 1/15 speedup in R_DrawSkyBoxPoly
2001-01-04 06:24:18 +00:00
x[face_axis[face1]] = face_offset[face1];
x[face_axis[face2]] = face_offset[face2];
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
replace face related % and / with table lookups. gives almost 50% speedup in set_vertex (but it's not called that often) and 1/15 speedup in R_DrawSkyBoxPoly
2001-01-04 06:24:18 +00:00
axis = 3 - ((face_axis[face1]) + (face_axis[face2]));
poly edge crossing FOUR (ouch, that was unexpected) cube faces partially taken care of. I have to fill in the incomplete faces (hmm, that will be interesting) and figure out why one corner in one of my test cases is sometimes set and sometimes not. Hmm, might be confused buy the enter/leave info from that edge.
2000-11-20 05:41:11 +00:00
v[axis] = 1;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
CrossProduct (x1, x2, n);
x_n = DotProduct (x, n);
v_n = DotProduct (v, n);
VectorScale (v, x_n / v_n, t);
VectorSubtract (x, t, y);
poly edge crossing FOUR (ouch, that was unexpected) cube faces partially taken care of. I have to fill in the incomplete faces (hmm, that will be interesting) and figure out why one corner in one of my test cases is sometimes set and sometimes not. Hmm, might be confused buy the enter/leave info from that edge.
2000-11-20 05:41:11 +00:00
return axis;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
}
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
/*
find_cube_vertex
get the coords of the vertex common to the three specified faces of the
cube. NOTE: this WILL break if the three faces do not share a common
vertex. ie works = ((face1 % 3 != face2 % 3)
&& (face2 % 3 != face3 % 3)
&& (face1 % 3 != face3 % 3))
*/
static void
find_cube_vertex (int face1, int face2, int face3, vec3_t v)
{
replace face related % and / with table lookups. gives almost 50% speedup in set_vertex (but it's not called that often) and 1/15 speedup in R_DrawSkyBoxPoly
2001-01-04 06:24:18 +00:00
v[face_axis[face1]] = face_offset[face1];
v[face_axis[face2]] = face_offset[face2];
v[face_axis[face3]] = face_offset[face3];
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
}
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
/*
set_vertex
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
add the vertex to the polygon describing the face of the cube. Offsets
the vertex relative to r_refdef.vieworg so the cube is always centered
on the player and also calculates the texture coordinates of the vertex
(wish I could find a cleaner way of calculating s and t).
*/
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
static void
try to insert the cube vertexen into the correct spot in the face poly vertex list.
2000-11-16 20:05:15 +00:00
set_vertex (struct box_def *box, int face, int ind, vec3_t v)
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
{
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
VectorCopy (v, box->face[face].poly.verts[ind]);
VectorAdd (v, r_refdef.vieworg, box->face[face].poly.verts[ind]);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
switch (face) {
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
case 0:
box->face[face].poly.verts[ind][3] = (1024 - v[1]) / 2048;
box->face[face].poly.verts[ind][4] = (1024 - v[2]) / 2048;
break;
case 1:
box->face[face].poly.verts[ind][3] = (1024 + v[0]) / 2048;
box->face[face].poly.verts[ind][4] = (1024 - v[2]) / 2048;
break;
case 2:
box->face[face].poly.verts[ind][3] = (1024 + v[0]) / 2048;
box->face[face].poly.verts[ind][4] = (1024 + v[1]) / 2048;
break;
case 3:
box->face[face].poly.verts[ind][3] = (1024 + v[1]) / 2048;
box->face[face].poly.verts[ind][4] = (1024 - v[2]) / 2048;
break;
case 4:
box->face[face].poly.verts[ind][3] = (1024 - v[0]) / 2048;
box->face[face].poly.verts[ind][4] = (1024 - v[2]) / 2048;
break;
case 5:
box->face[face].poly.verts[ind][3] = (1024 + v[0]) / 2048;
box->face[face].poly.verts[ind][4] = (1024 - v[1]) / 2048;
break;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
}
}
try to insert the cube vertexen into the correct spot in the face poly vertex list.
2000-11-16 20:05:15 +00:00
/*
add_vertex
fix up some comments (taking a break tonight, I guess:)
2000-11-21 07:49:58 +00:00
append a vertex to the poly vertex list.
try to insert the cube vertexen into the correct spot in the face poly vertex list.
2000-11-16 20:05:15 +00:00
*/
static void
add_vertex (struct box_def *box, int face, vec3_t v)
{
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
set_vertex (box, face, box->face[face].poly.numverts++, v);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
}
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
/*
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
insert_cube_vertices
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
insert the given cube vertices into the vertex list of the poly in the
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
correct location.
*/
static void
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
insert_cube_vertices (struct box_def *box, struct visit_def visit, int count,
...)
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
{
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int i;
vec3_t **v;
va_list args;
int face = visit.face;
int ind = visit.leave + 1;
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
Fix for borland famous alloca-bug.
2001-01-12 13:31:43 +00:00
#ifdef __BORLANDC__
// This is fix for borland alloca "feature" which fails to restore stack
// correcly if calling function doesn't have any references to local variables.
char dummy[5];
dummy[0]=0;
#endif
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
va_start (args, count);
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
v = (vec3_t **) alloca (count * sizeof (vec3_t *));
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
for (i = 0; i < count; i++) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
v[i] = va_arg (args, vec3_t *);
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
}
va_end (args);
if (ind == box->face[face].poly.numverts) {
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
// the vertex the sky poly left this cube fase through is very
// conveniently the last vertex of the face poly. this means we
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
// can just append the vetexen
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
for (i = 0; i < count; i++)
add_vertex (box, face, *v[i]);
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
} else {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
// we have to insert the cube vertices into the face poly
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
// vertex list
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
glpoly_t *p = &box->face[face].poly;
int c = p->numverts - ind;
const int vert_size = sizeof (p->verts[0]);
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
memmove (p->verts[ind + count], p->verts[ind], c * vert_size);
p->numverts += count;
for (i = 0; i < count; i++)
set_vertex (box, face, ind + i, *v[i]);
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
}
}
/*
cross_cube_edge
add the vertex formed by the poly edge crossing the cube edge to the
polygon for the two faces on that edge. Actually, the two faces define
the edge :). The poly edge is going from face 1 to face 2 (for
enter/leave purposes).
*/
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
static void
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
cross_cube_edge (struct box_def *box, int face1, vec3_t v1, int face2,
vec3_t v2)
{
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
vec3_t l;
int axis;
int face = -1;
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
poly edge crossing FOUR (ouch, that was unexpected) cube faces partially taken care of. I have to fill in the incomplete faces (hmm, that will be interesting) and figure out why one corner in one of my test cases is sometimes set and sometimes not. Hmm, might be confused buy the enter/leave info from that edge.
2000-11-20 05:41:11 +00:00
axis = find_intersect (face1, v1, face2, v2, l);
if (l[axis] > 1024)
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
face = axis;
poly edge crossing FOUR (ouch, that was unexpected) cube faces partially taken care of. I have to fill in the incomplete faces (hmm, that will be interesting) and figure out why one corner in one of my test cases is sometimes set and sometimes not. Hmm, might be confused buy the enter/leave info from that edge.
2000-11-20 05:41:11 +00:00
else if (l[axis] < -1024)
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
face = axis + 3;
fix a stupid bug
2000-12-02 08:31:18 +00:00
if (face >= 0) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
vec3_t x;
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
VectorAdd (v1, v2, x);
VectorScale (x, 0.5, x);
cross_cube_edge (box, face1, v1, face, x);
cross_cube_edge (box, face, x, face2, v2);
} else {
struct visit_def *visit = box->visited_faces;
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
visit[box->face_count - 1].leave = box->face[face1].poly.numverts;
visit[box->face_count].face = face2;
box->face_count++;
box->face_visits[face2]++;
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
add_vertex (box, face1, l);
add_vertex (box, face2, l);
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
}
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
}
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
/*
process_corners
egad, veddy complicated :)
*/
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
static void
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
process_corners (struct box_def *box)
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
{
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
struct visit_def *visit = box->visited_faces;
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int max_visit = 0;
int i;
int center = -1;
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
if (visit[box->face_count - 1].face == visit[0].face) {
box->face_count--;
}
for (i = 0; i < 6; i++) {
if (max_visit < box->face_visits[i]) {
max_visit = box->face_visits[i];
center = i;
}
}
switch (box->face_count) {
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
case 1:
case 2:
case 8:
// no corners
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
return;
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
case 3:
// one corner, no edges
{
vec3_t v;
find_cube_vertex (visit[0].face, visit[1].face, visit[2].face,
v);
insert_cube_vertices (box, visit[0], 1, v);
insert_cube_vertices (box, visit[1], 1, v);
insert_cube_vertices (box, visit[2], 1, v);
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
}
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
break;
case 4:
if (max_visit > 1)
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
return;
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
if (abs (visit[2].face - visit[0].face) == 3
&& abs (visit[3].face - visit[1].face) == 3) {
// 4 vertices
int sum, diff;
vec3_t v[4];
sum =
visit[0].face + visit[1].face + visit[2].face +
visit[3].face;
diff = visit[1].face - visit[0].face;
sum %= 3;
diff = (diff + 6) % 6;
center = faces_table[sum][diff];
for (i = 0; i < 4; i++) {
find_cube_vertex (visit[i].face, visit[(i + 1) & 3].face,
center, v[i]);
add_vertex (box, center, v[i]);
}
for (i = 0; i < 4; i++)
insert_cube_vertices (box, visit[i], 2, v[i],
v[(i - 1) & 3]);
} else {
// 2 vertices
int l_f, t_f, r_f, b_f;
vec3_t v_l, v_r;
if (abs (visit[2].face - visit[0].face) == 3) {
l_f = 0;
t_f = 1;
r_f = 2;
b_f = 3;
} else if (abs (visit[3].face - visit[1].face) == 3) {
l_f = 1;
t_f = 2;
r_f = 3;
b_f = 0;
} else {
return;
}
find_cube_vertex (visit[l_f].face, visit[t_f].face,
visit[b_f].face, v_l);
find_cube_vertex (visit[r_f].face, visit[t_f].face,
visit[b_f].face, v_r);
insert_cube_vertices (box, visit[t_f], 2, v_r, v_l);
insert_cube_vertices (box, visit[b_f], 2, v_l, v_r);
insert_cube_vertices (box, visit[l_f], 1, v_l);
insert_cube_vertices (box, visit[r_f], 1, v_r);
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
}
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
break;
case 5:
if (max_visit > 1) {
// one vertex
vec3_t v;
for (i = 0; i < 4; i++) {
// don't need to check the 5th visit
if (visit[(i + 2) % 5].face == visit[(i + 4) % 5].face)
break;
}
find_cube_vertex (visit[i].face, visit[(i + 1) % 5].face,
visit[(i + 2) % 5].face, v);
insert_cube_vertices (box, visit[i], 1, v);
insert_cube_vertices (box, visit[(i + 1) % 5], 1, v);
insert_cube_vertices (box, visit[(i + 4) % 5], 1, v);
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
} else {
// 3 vertices
unsigned int sel =
(((abs (visit[2].face - visit[0].face) == 3) << 2) |
((abs (visit[3].face - visit[1].face) == 3) << 1)
| ((abs (visit[4].face - visit[2].face) == 3) << 0));
vec3_t v[3];
center = faces_bit_magic[sel];
// printf ("%02o %d %d %d %d %d %d\n", sel, center,
// visit[0].face,
// visit[1].face, visit[2].face, visit[3].face,
// visit[4].face);
for (i = 0; i < 3; i++)
find_cube_vertex (visit[center].face,
visit[(center + 1 + i) % 5].face,
visit[(center + 2 + i) % 5].face, v[i]);
insert_cube_vertices (box, visit[center], 3, v[0], v[1], v[2]);
insert_cube_vertices (box, visit[(center + 1) % 5], 1, v[0]);
insert_cube_vertices (box, visit[(center + 2) % 5], 2, v[1],
v[0]);
insert_cube_vertices (box, visit[(center + 3) % 5], 2, v[2],
v[1]);
insert_cube_vertices (box, visit[(center + 4) % 5], 1, v[2]);
}
break;
case 6:
if (max_visit > 2)
return;
for (i = 0; i < 5; i++) {
// don't need to check the last point
if (visit[(i + 3) % 6].face == visit[(i + 5) % 6].face
|| visit[(i + 2) % 6].face == visit[(i + 5) % 6].face)
the case of 5 faces visited with one cube vertex enclosed is now handled.
2000-12-01 05:24:53 +00:00
break;
}
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
if (visit[(i + 3) % 6].face == visit[(i + 5) % 6].face) {
// adjacant vertices
vec3_t v[2];
the cases of 6 faces with two vertexen (both adjoining and opposing) and 7 faces with 1 vertex are implemented, but I have no way of testing them :(ie, I haven't found anywhere to test them, there just don't seem to be any sky polys of the right shape)
2000-12-01 07:30:29 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
find_cube_vertex (visit[i].face, visit[(i + 1) % 6].face,
visit[(i + 2) % 6].face, v[0]);
find_cube_vertex (visit[(i + 1) % 6].face,
visit[(i + 2) % 6].face,
visit[(i + 3) % 6].face, v[1]);
the cases of 6 faces with two vertexen (both adjoining and opposing) and 7 faces with 1 vertex are implemented, but I have no way of testing them :(ie, I haven't found anywhere to test them, there just don't seem to be any sky polys of the right shape)
2000-12-01 07:30:29 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
insert_cube_vertices (box, visit[(i + 5) % 6], 2, v[2], v[1]);
the cases of 6 faces with two vertexen (both adjoining and opposing) and 7 faces with 1 vertex are implemented, but I have no way of testing them :(ie, I haven't found anywhere to test them, there just don't seem to be any sky polys of the right shape)
2000-12-01 07:30:29 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
insert_cube_vertices (box, visit[i], 1, v[0]);
insert_cube_vertices (box, visit[(i + 1) % 6], 2, v[1], v[0]);
insert_cube_vertices (box, visit[(i + 2) % 6], 1, v[1]);
} else {
// opposing vertices
vec3_t v[2];
the cases of 6 faces with two vertexen (both adjoining and opposing) and 7 faces with 1 vertex are implemented, but I have no way of testing them :(ie, I haven't found anywhere to test them, there just don't seem to be any sky polys of the right shape)
2000-12-01 07:30:29 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
find_cube_vertex (visit[i].face, visit[(i + 1) % 6].face,
visit[(i + 2) % 6].face, v[0]);
find_cube_vertex (visit[(i + 3) % 6].face,
visit[(i + 4) % 6].face,
visit[(i + 5) % 6].face, v[1]);
the cases of 6 faces with two vertexen (both adjoining and opposing) and 7 faces with 1 vertex are implemented, but I have no way of testing them :(ie, I haven't found anywhere to test them, there just don't seem to be any sky polys of the right shape)
2000-12-01 07:30:29 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
insert_cube_vertices (box, visit[i], 1, v[0]);
insert_cube_vertices (box, visit[(i + 1) % 6], 1, v[0]);
the cases of 6 faces with two vertexen (both adjoining and opposing) and 7 faces with 1 vertex are implemented, but I have no way of testing them :(ie, I haven't found anywhere to test them, there just don't seem to be any sky polys of the right shape)
2000-12-01 07:30:29 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
insert_cube_vertices (box, visit[(i + 3) % 6], 1, v[1]);
insert_cube_vertices (box, visit[(i + 4) % 6], 1, v[1]);
the cases of 6 faces with two vertexen (both adjoining and opposing) and 7 faces with 1 vertex are implemented, but I have no way of testing them :(ie, I haven't found anywhere to test them, there just don't seem to be any sky polys of the right shape)
2000-12-01 07:30:29 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
insert_cube_vertices (box, visit[(i + 2) % 6], 1, v[1]);
insert_cube_vertices (box, visit[(i + 5) % 6], 1, v[0]);
}
break;
case 7:
for (i = 0; i < 6; i++) {
// don't need to check the last point
if (visit[(i + 2) % 6].face == visit[(i + 4) % 6].face
&& visit[(i + 4) % 6].face == visit[(i + 6) % 6].face)
break;
}
{
vec3_t v;
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
find_cube_vertex (visit[i].face, visit[(i + 1) % 6].face,
visit[(i + 2) % 6].face, v);
the cases of 6 faces with two vertexen (both adjoining and opposing) and 7 faces with 1 vertex are implemented, but I have no way of testing them :(ie, I haven't found anywhere to test them, there just don't seem to be any sky polys of the right shape)
2000-12-01 07:30:29 +00:00
Okay, the big whitespace reformat. There is some silliness (case statements, variable declarations), but all in all it's not bad.
2000-12-08 06:51:37 +00:00
insert_cube_vertices (box, visit[i], 1, v);
insert_cube_vertices (box, visit[(i + 1) % 7], 1, v);
insert_cube_vertices (box, visit[(i + 6) % 7], 1, v);
}
break;
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
}
}
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
/*
render_box
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
draws all faces of the cube with 3 or more vertices.
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
*/
poly edge crossing FOUR (ouch, that was unexpected) cube faces partially taken care of. I have to fill in the incomplete faces (hmm, that will be interesting) and figure out why one corner in one of my test cases is sometimes set and sometimes not. Hmm, might be confused buy the enter/leave info from that edge.
2000-11-20 05:41:11 +00:00
static void
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
render_box (struct box_def *box)
poly edge crossing FOUR (ouch, that was unexpected) cube faces partially taken care of. I have to fill in the incomplete faces (hmm, that will be interesting) and figure out why one corner in one of my test cases is sometimes set and sometimes not. Hmm, might be confused buy the enter/leave info from that edge.
2000-11-20 05:41:11 +00:00
{
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int i, j;
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
for (i = 0; i < 6; i++) {
if (box->face[i].poly.numverts <= 2)
continue;
glBindTexture (GL_TEXTURE_2D, box->face[i].tex);
glBegin (GL_POLYGON);
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
for (j = 0; j < box->face[i].poly.numverts; j++) {
glTexCoord2fv (box->face[i].poly.verts[j] + 3);
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
glVertex3fv (box->face[i].poly.verts[j]);
}
glEnd ();
poly edge crossing FOUR (ouch, that was unexpected) cube faces partially taken care of. I have to fill in the incomplete faces (hmm, that will be interesting) and figure out why one corner in one of my test cases is sometimes set and sometimes not. Hmm, might be confused buy the enter/leave info from that edge.
2000-11-20 05:41:11 +00:00
}
}
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
void
R_DrawSkyBoxPoly (glpoly_t *poly)
{
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int i;
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
struct box_def box;
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
/* projected vertex and face of the previous sky poly vertex */
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
vec3_t last_v;
int prev_face;
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
/* projected vertex and face of the current sky poly vertex */
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
vec3_t v;
int face;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
memset (&box, 0, sizeof (box));
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
for (i = 0; i < 6; i++) {
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
box.face[i].tex = SKY_TEX + skytex_offs[i];
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
}
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
if (poly->numverts >= 32) {
use Sys_Error instead of abort
2000-11-16 23:00:35 +00:00
Sys_Error ("too many verts!");
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
}
cleanup and document current code. Also catch a couple of possible bugs in the process
2000-11-15 18:43:19 +00:00
VectorSubtract (poly->verts[poly->numverts - 1], r_refdef.vieworg, last_v);
prev_face = determine_face (last_v);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
box.visited_faces[0].face = prev_face;
box.face_count = 1;
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
for (i = 0; i < poly->numverts; i++) {
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
VectorSubtract (poly->verts[i], r_refdef.vieworg, v);
face = determine_face (v);
if (face != prev_face) {
replace face related % and / with table lookups. gives almost 50% speedup in set_vertex (but it's not called that often) and 1/15 speedup in R_DrawSkyBoxPoly
2001-01-04 06:24:18 +00:00
if ((face_axis[face]) == (face_axis[prev_face])) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int x_face;
vec3_t x;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
VectorAdd (v, last_v, x);
VectorScale (x, 0.5, x);
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
x_face = determine_face (x);
cross_cube_edge (&box, prev_face, last_v, x_face, x);
cross_cube_edge (&box, x_face, x, face, v);
} else {
cross_cube_edge (&box, prev_face, last_v, face, v);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
}
}
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
add_vertex (&box, face, v);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
VectorCopy (v, last_v);
prev_face = face;
}
another bites the dust, dn dn dn :) I think I only have one more clipping case to take care of, and it's really a bug in an earlier case.
2000-11-19 01:18:54 +00:00
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
process_corners (&box);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
a major(?) algo change in cubee vertex handling. When a polygon goes around a cube vertex, that vertex is no longer added immediatly, instead delaying it's addition to the poly vertex list until all the sky poly points have been handled (this has a side benefit of completely eliminating those two almost identical functions: enter_face() and leave_face() :). After the sky poly vertexen have been processed, the faces the edges of the poly have visted are analysed for all 14 possible cases to determine how many and which cube vertexen are to be added to the face polys. So far, 9/14 cases are handled properly and 1 seems to be mysteriously handled in what seems to be a correct fashion part of the time (bloody heisenbugs). The remaining cases are: 5 visited faces with 1 vertex and 3 vertexen (the heisenbug); 6 faces and 2 vertexen (2 variants: neighboring vertexen and opposing vertexen); and 7 faces with 1 vertex.
2000-12-01 04:57:35 +00:00
render_box (&box);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
}
void
R_DrawSkyDomePoly (glpoly_t *poly)
{
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int i;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
glBegin (GL_POLYGON);
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
for (i = 0; i < poly->numverts; i++) {
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
glVertex3fv (poly->verts[i]);
}
glEnd ();
}
void
R_DrawSkyChain (msurface_t *sky_chain)
{
msurface_t *sc = sky_chain;
skys are no longer brighted with brightness (they saturate way too fast)
2001-01-07 12:19:27 +00:00
float l = 1 / (256 * brightness->value);
glColor3f (lighthalf_v[0] * l, lighthalf_v[1] * l, lighthalf_v[2] * l);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
if (skyloaded) {
finally. every condition I've been able to produce in start.bsp (quad jump to the top of the map) works well. Depth issues have been taken care of as well (sort of: same problems as non-clipped skybox, but you don't get sky IN the map any more)
2000-12-02 05:32:50 +00:00
glDepthRange (gldepthmax, gldepthmax);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
while (sc) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
glpoly_t *p = sc->polys;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
while (p) {
R_DrawSkyBoxPoly (p);
p = p->next;
}
sc = sc->texturechain;
}
finally. every condition I've been able to produce in start.bsp (quad jump to the top of the map) works well. Depth issues have been taken care of as well (sort of: same problems as non-clipped skybox, but you don't get sky IN the map any more)
2000-12-02 05:32:50 +00:00
glDepthRange (gldepthmin, gldepthmax);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
} else {
oh, just a 4 x speedup for q1dm17 wih gl_sky_clip 1 and gl_sky_divide 1 :)
2001-01-27 06:16:40 +00:00
glDisable (GL_BLEND);
glDisable (GL_TEXTURE_2D);
glColor3f (0, 0, 0);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
while (sc) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
glpoly_t *p = sc->polys;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
while (p) {
R_DrawSkyDomePoly (p);
p = p->next;
}
sc = sc->texturechain;
}
oh, just a 4 x speedup for q1dm17 wih gl_sky_clip 1 and gl_sky_divide 1 :)
2001-01-27 06:16:40 +00:00
glEnable (GL_TEXTURE_2D);
glEnable (GL_BLEND);
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
}
put my sky alpha trick into a safe place. currently disabled because while it works, it's not the right place.
2000-12-25 03:38:48 +00:00
#if 0
// seems to work, but this is the wrong place to do it.
glColor4f (1,1,1,0);
sc = sky_chain;
while (sc) {
glpoly_t *p = sc->polys;
while (p) {
int i;
glBegin (GL_POLYGON);
for (i = 0; i < p->numverts; i++) {
glVertex3fv (p->verts[i]);
}
glEnd ();
p = p->next;
}
sc = sc->texturechain;
}
#endif
finally found the black water bug!!! forgot to set the color back to the lighting color
2000-12-09 05:37:25 +00:00
glColor3ubv (lighthalf_v);
finally. every condition I've been able to produce in start.bsp (quad jump to the top of the map) works well. Depth issues have been taken care of as well (sort of: same problems as non-clipped skybox, but you don't get sky IN the map any more)
2000-12-02 05:32:50 +00:00
#if 0
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
glDisable (GL_TEXTURE_2D);
add the center points of the sky polys to the debug info.
2000-11-17 07:19:47 +00:00
sc = sky_chain;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
glColor3f (1, 1, 1);
add the center points of the sky polys to the debug info.
2000-11-17 07:19:47 +00:00
while (sc) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
glpoly_t *p = sc->polys;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
while (p) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int i;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
glBegin (GL_LINE_LOOP);
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
for (i = 0; i < p->numverts; i++) {
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
glVertex3fv (p->verts[i]);
}
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
glEnd ();
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
p = p->next;
}
add the center points of the sky polys to the debug info.
2000-11-17 07:19:47 +00:00
sc = sc->texturechain;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
}
add the center points of the sky polys to the debug info.
2000-11-17 07:19:47 +00:00
sc = sky_chain;
glColor3f (0, 1, 0);
glBegin (GL_POINTS);
while (sc) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
glpoly_t *p = sc->polys;
add the center points of the sky polys to the debug info.
2000-11-17 07:19:47 +00:00
while (p) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int i;
vec3_t x, c = { 0, 0, 0 };
for (i = 0; i < p->numverts; i++) {
add the center points of the sky polys to the debug info.
2000-11-17 07:19:47 +00:00
VectorSubtract (p->verts[i], r_refdef.vieworg, x);
VectorAdd (x, c, c);
}
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
VectorScale (c, 1.0 / p->numverts, c);
add the center points of the sky polys to the debug info.
2000-11-17 07:19:47 +00:00
VectorAdd (c, r_refdef.vieworg, c);
glVertex3fv (c);
p = p->next;
}
sc = sc->texturechain;
}
glEnd ();
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
if (skyloaded) {
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
int i, j;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
glColor3f (1, 0, 0);
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
for (i = 0; i < 6; i++) {
vec3_t v;
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
glBegin (GL_LINE_LOOP);
pass though indent, correct a comment and change vertexen to vertices
2000-12-02 06:09:18 +00:00
for (j = 0; j < 4; j++) {
memcpy (v, &skyvec[i][j][2], sizeof (v));
split gl_sky.c into gl_sky.c and gl_sky_clip.c (should have done this in the first place, but I didn't realise how much code would go into sky clipping).
2000-11-15 17:20:54 +00:00
VectorAdd (v, r_refdef.vieworg, v);
glVertex3fv (v);
}
glEnd ();
}
}
glColor3ubv (lighthalf_v);
glEnable (GL_TEXTURE_2D);
#endif
}
Reference in a new issue Copy permalink