Descriptive Modding: The PSP Engine

[Baker]

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).

[Baker]

Revision 14: source

Solved stupid time wasting mystery from way earlier. Involved a header file.

[Baker]

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 ...)

[Baker]

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.

[Baker]

Revision 18: source

[Baker]

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 ...

[Baker]

Still at it ...

Revision 21: source

[r00k]

qrackwhore

[ceriux]

does this compile in microsoft visual c++ ee?

[Baker]

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.

viewtopic.php?t=1667

qrackwhore

It ain't easy to do years of code upgrades to an engine.

But I thought this was gonna be faster. No matter!

[Baker]

Revision 22: source

[goldenboy]

Crazy stuff.

Can it run Remake Quake?

[Baker]

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.

[mh]

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: Select all

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: Select all

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: Select all

   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: Select all

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.

[Baker]

Revision 32: source

It's getting closer. A few obstacles remain.