Inside3D!
     

Descriptive Modding: The PSP Engine
Goto page Previous  1, 2, 3, 4, 5  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming
View previous topic :: View next topic  
Author Message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Jan 13, 2010 6:28 am    Post subject: Reply with quote

r00k wrote:
Oh sweet! PSPQrack! Razz

R_simpleitems style 24bit hires sprites, remake of original quake models.


Do it! Very Happy 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 Very Happy ]

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
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Jan 13, 2010 4:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Jan 13, 2010 5:11 pm    Post subject: Reply with quote

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
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Jan 13, 2010 8:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Jan 13, 2010 9:51 pm    Post subject: Reply with quote

Revision 18: source
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Jan 13, 2010 11:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Thu Jan 14, 2010 1:49 am    Post subject: Reply with quote

Still at it ...

Revision 21: source
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
r00k



Joined: 13 Nov 2004
Posts: 483

PostPosted: Thu Jan 14, 2010 4:38 am    Post subject: Reply with quote

qrackwhore Wink
Back to top
View user's profile Send private message
ceriux



Joined: 06 Sep 2008
Posts: 969
Location: Florida, USA

PostPosted: Thu Jan 14, 2010 6:50 am    Post subject: Reply with quote

does this compile in microsoft visual c++ ee?
_________________
QuakeDB - Quake ModDB Group
Back to top
View user's profile Send private message Yahoo Messenger
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Thu Jan 14, 2010 12:48 pm    Post subject: Reply with quote

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 Wink


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

But I thought this was gonna be faster. No matter!
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Thu Jan 14, 2010 3:20 pm    Post subject: Reply with quote

Revision 22: source
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
goldenboy



Joined: 05 Sep 2008
Posts: 310
Location: Kiel

PostPosted: Thu Jan 14, 2010 5:56 pm    Post subject: Reply with quote

Crazy stuff.

Can it run Remake Quake?
_________________
ReMakeQuake
The Realm of Blog Magic
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Thu Jan 14, 2010 6:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 910

PostPosted: Thu Jan 14, 2010 7:15 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Sat Jan 16, 2010 3:22 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 2 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group