View previous topic :: View next topic |
Author |
Message |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Jan 13, 2010 6:28 am Post subject: |
|
|
r00k wrote: | Oh sweet! PSPQrack!
R_simpleitems style 24bit hires sprites, remake of original quake models. |
Do it! I think you'd be impressed by Quake and Kurok on the PSP. You're the one always writing new non-Quakey graphical effects ... if you think of Quake as an engine and not as Shamblers there are quite a few possibilities ... [I have a collection I have been accumulating ... one of those vague things I'm not allowed to say because of someone else, hehe ]
Meanwhile ...
Revision 7: source
Revision 8: source [Only partially complete]
I think I'm going to have to concede the night. I have more to do and this isn't done. About 65% done (90% on integration; 20% on Kurok borrowing). _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Jan 13, 2010 4:44 pm Post subject: |
|
|
Revision 14: source
Solved stupid time wasting mystery from way earlier. Involved a header file. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Jan 13, 2010 5:11 pm Post subject: |
|
|
Alright ... things are back on schedule again.
Revision 15: source
Since things are going smoothly again, I think it's time to put some of the weird things (floats instead of double, alternate math functions, treatment of qboolean values in the cpp files) I've noticed in the PSP Quake source -- which I'm thinking are not necessary --- to the test in Revision 16.
My understanding is that the early PSP Quake used floats instead of double due to the compiler acting up on double. In Quake there are few doubles being used, mostly for the clock. And in the cpp I'm seeing "qtrue" and "qfalse" instead of true and false and regardless of the value of these, false is going to be zero.
We'll see. Maybe I'm overlooking something ...
(I guess technically the cos/tan/atan/etc functions in C return doubles and vec3_t is a set of floats and these functions would avoid a data conversion ...) _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Jan 13, 2010 8:44 pm Post subject: |
|
|
Revision 17: source
Compiles and runs just fine with the removal of the float specific math functions.
Except I lost about 10 frames per second. 70fps +/- down to 57 fps. This is a 20% drop!
I'm going to leave it as-is for now and likely I'm going to see if converting the double returning functions in Windows version of ProQuake into the float versions (sqrt --> sqrtf, tan --> tanf) results in any kind of fps gain [not likely to be of the same gain].
And possibly make it standard in ProQuake after testing. I mean, vectors are stored as floats anyway so I don't see any gain from type conversion from double to float. Any differences in precision from float to double in a math function that is converted back to float is going to be microscopic. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Jan 13, 2010 9:51 pm Post subject: |
|
|
Revision 18: source _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Jan 13, 2010 11:03 pm Post subject: |
|
|
Revision 19: source
Had no idea how much work there is in adding ip:port connection ability to standard Quake is (sounds super easy). Well, now I do ... _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Thu Jan 14, 2010 1:49 am Post subject: |
|
|
Still at it ...
Revision 21: source _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Thu Jan 14, 2010 4:38 am Post subject: |
|
|
qrackwhore  |
|
Back to top |
|
 |
ceriux

Joined: 06 Sep 2008 Posts: 969 Location: Florida, USA
|
Posted: Thu Jan 14, 2010 6:50 am Post subject: |
|
|
does this compile in microsoft visual c++ ee? _________________ QuakeDB - Quake ModDB Group |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Thu Jan 14, 2010 12:48 pm Post subject: |
|
|
ceriux wrote: | does this compile in
microsoft visual c++ ee? |
No. You have to use Cygwin, see the instructions in this thread. Team XLink did a killer job making the PSP compile process simple.
http://forums.inside3d.com/viewtopic.php?t=1667
r00k wrote: | qrackwhore  |
It ain't easy to do years of code upgrades to an engine.
But I thought this was gonna be faster. No matter! _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Thu Jan 14, 2010 3:20 pm Post subject: |
|
|
Revision 22: source _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Thu Jan 14, 2010 5:56 pm Post subject: |
|
|
Crazy stuff.
Can it run Remake Quake? _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Thu Jan 14, 2010 6:02 pm Post subject: |
|
|
goldenboy wrote: | Crazy stuff.
Can it run Remake Quake? |
It should (*) ... memory requirements can be an issue.
When I hit the point that I have all the appropriate underlying support, I'm going to post screenshots of alpha support (Back2forwards if memory will permit to load, something else if not) and of the Travail start map (skybox support).
Other than memory, it should have all the functionality of ProQuake 4. The PSP Slim has 64 MB memory and not all of that can be used for Quake, but if Quake Remake can run with only 40MB to 50MB it should be an automatic for the Slim.
PSP 1001 - PSP "Phat" - 32 MB (I'm using this; I want the lowest tier one obviously]
PSP 2000 - PSP "Slim" - 64 MB
PSP 3000 - 64 MB ... not sure if it has been "hacked".
But I'm still working on ... but when done this and Flash ProQuake and Windows and Direct3D 8.1 and OS X will have a singular codebase, so any future changes to ProQuake will be easy to maintain and available on all platforms.
Speaking of revisions:
Revision 23: source (doesn't compile, a halfway checkpoint for a large feature set transfer)
(*) Should = memory is a big issue, but non-gigantic maps like deathmatch maps if it doesn't require a crapton of models and other things killing memory = yes. Kurok has some great down sampling code to preserve memory usage from textures which will help some. I suppose it also great matters the size of the .wav files you are precaching to a client as well. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
mh

Joined: 12 Jan 2008 Posts: 910
|
Posted: Thu Jan 14, 2010 7:15 pm Post subject: |
|
|
If memory pressure is a concern you can get a very significant saving on your vertexes by storing a pointer to the original xyz from the loadmodel->vertexes lump, then using that instead of v[3] for your glVertex3fv call when rendering. I squeezed warpc.bsp down to well under 30MB using this method (Q1 is incredibly wasteful with vertexes).
Your glpoly_t struct would look something like this:
Code: | typedef struct glvert_s
{
float *v;
float st1[2];
float st2[2];
} glvert_t;
typedef struct glpoly_s
{
struct glpoly_s *next;
struct glpoly_s *chain;
int numverts;
int flags; // for SURF_UNDERWATER
glvert_t verts[4]; // variable sized (xyz s1t1 s2t2)
} glpoly_t; |
Your BuildSurfaceDisplayList looks like this:
Code: | void BuildSurfaceDisplayList (msurface_t *fa)
{
int i, lindex, lnumverts;
medge_t *pedges, *r_pedge;
int vertpage;
float s, t;
glpoly_t *poly;
// reconstruct the polygon
pedges = currentmodel->edges;
lnumverts = fa->numedges;
vertpage = 0;
// draw texture
poly = Hunk_Alloc (sizeof(glpoly_t) + (lnumverts-4) * sizeof(glvert_t));
poly->next = fa->polys;
poly->flags = fa->flags;
fa->polys = poly;
poly->numverts = lnumverts;
for (i=0 ; i<lnumverts ; i++)
{
lindex = currentmodel->surfedges[fa->firstedge + i];
if (lindex > 0)
{
r_pedge = &pedges[lindex];
poly->verts[i].v = r_pcurrentvertbase[r_pedge->v[0]].position;
}
else
{
r_pedge = &pedges[-lindex];
poly->verts[i].v = r_pcurrentvertbase[r_pedge->v[1]].position;
}
s = DotProduct (poly->verts[i].v, fa->texinfo->vecs[0]) + fa->texinfo->vecs[0][3];
s /= fa->texinfo->texture->width;
t = DotProduct (poly->verts[i].v, fa->texinfo->vecs[1]) + fa->texinfo->vecs[1][3];
t /= fa->texinfo->texture->height;
poly->verts[i].st1[0] = s;
poly->verts[i].st1[1] = t;
// lightmap texture coordinates
s = DotProduct (poly->verts[i].v, fa->texinfo->vecs[0]) + fa->texinfo->vecs[0][3];
s -= fa->texturemins[0];
s += fa->light_s*16;
s += 8;
s /= BLOCK_WIDTH*16; //fa->texinfo->texture->width;
t = DotProduct (poly->verts[i].v, fa->texinfo->vecs[1]) + fa->texinfo->vecs[1][3];
t -= fa->texturemins[1];
t += fa->light_t*16;
t += 8;
t /= BLOCK_HEIGHT*16; //fa->texinfo->texture->height;
poly->verts[i].st2[0] = s;
poly->verts[i].st2[1] = t;
}
poly->numverts = lnumverts;
} |
Here's the relevant part of SubdividePolygon:
Code: | poly = Hunk_Alloc (sizeof(glpoly_t) + (numverts-4) * sizeof(glvert_t));
poly->next = warpface->polys;
warpface->polys = poly;
poly->numverts = numverts;
for (i=0 ; i<numverts ; i++, verts+= 3)
{
poly->verts[i].v = (float *) Hunk_Alloc (sizeof (float) * 3);
VectorCopy (verts, poly->verts[i].v);
s = DotProduct (verts, warpface->texinfo->vecs[0]);
t = DotProduct (verts, warpface->texinfo->vecs[1]);
poly->verts[i].st1[0] = s;
poly->verts[i].st1[1] = t;
} |
And here's a sample poly drawing function:
Code: | void DrawGLPoly (glpoly_t *p)
{
int i;
glvert_t *v;
glBegin (GL_POLYGON);
v = p->verts;
for (i=0 ; i<p->numverts ; i++, v++)
{
glTexCoord2fv (v->st1);
glVertex3fv (v->v);
}
glEnd ();
} |
There's more savings to be made on alias models (check my extending alias models limits tutorial, shaves off about 1-2 MB per ID1 map), and if you were masochistic you could also save a lot on surf texcoords by checking for duplicates and only storing unique coords, then also grabbing a pointer there. Load times become prohibitively slow.
GLQuake is also incredibly wasteful on textures: it doesn't actually need to store the texels with the tx struct, so drop that. You'll need to use (byte *) (mt + 1) for your load texture data, as well as modify R_InitSky to take mt instead of tx. _________________ DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Sat Jan 16, 2010 3:22 am Post subject: |
|
|
Revision 32: source
It's getting closer. A few obstacles remain. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
|