hud translucent

[revelator]

had a look at the kurok svn sources and first im bit puzzled. heres why.

vid_hardware_draw.cpp does not exist it seems.

theres a draw.c containing

Code: Select all

/*
=============
Draw_Pic
=============
*/
void Draw_Pic (int x, int y, qpic_t *pic)
{
   byte         *dest, *source;
   unsigned short   *pusdest;
   int            v, u;

   if ((x < 0) ||
      (x + pic->width > vid.width) ||
      (y < 0) ||
      (y + pic->height > vid.height))
   {
      Sys_Error ("Draw_Pic: bad coordinates");
   }

   source = pic->data;

   if (r_pixbytes == 1)
   {
      dest = vid.buffer + y * vid.rowbytes + x;

      for (v=0 ; v<pic->height ; v++)
      {
         Q_memcpy (dest, source, pic->width);
         dest += vid.rowbytes;
         source += pic->width;
      }
   }
   else
   {
   // FIXME: pretranslate at load time?
      pusdest = (unsigned short *)vid.buffer + y * (vid.rowbytes >> 1) + x;

      for (v=0 ; v<pic->height ; v++)
      {
         for (u=0 ; u<pic->width ; u++)
         {
            pusdest[u] = d_8to16table[source[u]];
         }

         pusdest += vid.rowbytes >> 1;
         source += pic->width;
      }
   }
}


/*
=============
Draw_TransPic
=============
*/
void Draw_TransPic (int x, int y, qpic_t *pic)
{
   byte   *dest, *source, tbyte;
   unsigned short   *pusdest;
   int            v, u;

   if (x < 0 || (unsigned)(x + pic->width) > vid.width || y < 0 ||
       (unsigned)(y + pic->height) > vid.height)
   {
      Sys_Error ("Draw_TransPic: bad coordinates");
   }
      
   source = pic->data;

   if (r_pixbytes == 1)
   {
      dest = vid.buffer + y * vid.rowbytes + x;

      if (pic->width & 7)
      {   // general
         for (v=0 ; v<pic->height ; v++)
         {
            for (u=0 ; u<pic->width ; u++)
               if ( (tbyte=source[u]) != TRANSPARENT_COLOR)
                  dest[u] = tbyte;
   
            dest += vid.rowbytes;
            source += pic->width;
         }
      }
      else
      {   // unwound
         for (v=0 ; v<pic->height ; v++)
         {
            for (u=0 ; u<pic->width ; u+=8)
            {
               if ( (tbyte=source[u]) != TRANSPARENT_COLOR)
                  dest[u] = tbyte;
               if ( (tbyte=source[u+1]) != TRANSPARENT_COLOR)
                  dest[u+1] = tbyte;
               if ( (tbyte=source[u+2]) != TRANSPARENT_COLOR)
                  dest[u+2] = tbyte;
               if ( (tbyte=source[u+3]) != TRANSPARENT_COLOR)
                  dest[u+3] = tbyte;
               if ( (tbyte=source[u+4]) != TRANSPARENT_COLOR)
                  dest[u+4] = tbyte;
               if ( (tbyte=source[u+5]) != TRANSPARENT_COLOR)
                  dest[u+5] = tbyte;
               if ( (tbyte=source[u+6]) != TRANSPARENT_COLOR)
                  dest[u+6] = tbyte;
               if ( (tbyte=source[u+7]) != TRANSPARENT_COLOR)
                  dest[u+7] = tbyte;
            }
            dest += vid.rowbytes;
            source += pic->width;
         }
      }
   }
   else
   {
   // FIXME: pretranslate at load time?
      pusdest = (unsigned short *)vid.buffer + y * (vid.rowbytes >> 1) + x;

      for (v=0 ; v<pic->height ; v++)
      {
         for (u=0 ; u<pic->width ; u++)
         {
            tbyte = source[u];

            if (tbyte != TRANSPARENT_COLOR)
            {
               pusdest[u] = d_8to16table[tbyte];
            }
         }

         pusdest += vid.rowbytes >> 1;
         source += pic->width;
      }
   }
}

can anyone confirm this ?

the above is from the kurok psp svn trunk.

Draw_AlphaPic does indeed not exist if im correct about this mexi might have just created a file which is not even part of the project hence why Draw_AlphaPic (correctly) isnt found.

[Mexicouger]

It does exist. It is called video_hardware_draw.c, and it is in the psp folder. I hope Baker finds a fix.

[Baker]

It does exist. It is called video_hardware_draw.c, and it is in the psp folder. I hope Baker finds a fix.

1. Remove the static from video_hardware_draw.cpp

2. Add that Sbar_DrawAlphaPic function.

3. In draw.h add ...

Code: Select all

void Draw_AlphaPic (int x, int y, qpic_t *pic, float alpha);

... right under the function prototype for Draw_Pic (...);

4. Delete psp/normal folder. This is the same thing as doing a clean.

5. Compile!

At the moment, I'm trying to think of why all of this would be necessary. Without doing all of the above, I experienced all the issues you did with it not compiling. After doing the above including the draw.h modification and deleting the output folder, it does compile. Which is the important thing. It isn't clear to me why the whole damn thing needs to recompile for this, I'd think just the sbar.c and video_hardware_draw.cpp would need to be recompiled even after modifying draw.h but it still doesn't compile even then without cleaning the project.

Whatever. As long as it works.

[Mexicouger]

Now how do I draw the picture? I drew it like this, and it failed. Nothing showed up.

Code: Select all

if (cl_bomb.value == 2)
   {
   bomb= Draw_CachePic ("gfx/bomb.lmp");
   Sbar_DrawAlphaPic (370, 50, bomb, 0.5);
   }

How should I do this because I am confused. Thanks for the help so far Guys

[Mexicouger]

Can someone please finish this ordeal? When I use it, It doesn't draw the image at all. I really would love alpha transparency.

[Baker]

Kurok's Draw_AlphaPic was not what it appeared and will not work.

I have fixed it. Here is a ProQuake 4.67 PSP with a transparent sbar.

cl_sbar = status bar alpha; I defaulted it to 0.6 for you.

Take the Draw_AlphaPic from my source in video_hardware_draw.cpp and you'll be set.

http://quakeone.com/proquake/interims/p ... sp_all.rar

I haven't tested this build against Kurok, it might run Kurok just fine or it might not. It will run standard Quake for sure. It does not have the Half-Life map support yet, something small was wrong with it and I removed it.

For fun you can load it up and press the left trigger a few times

[Mexicouger]

Great work Baker

I copied the Draw_AlphaPic code, And I have to reset it's coordinates. It is still cool. One problem with it though, is that the pink color(159,91,83) turns out a transparent white. I wonder why...

and can you list the new features in Proquake psp over regular Kurok? Pros/cons.

[Baker]

My goals are different than the other PSP engines. It is more that it is the same code base running on a few different platforms with feature consistency.

ProQuake PSP runs the same mods as Windows, plays the same maps as Windows, has the same commands, same cvars, same bug fixes. With mp3 support on Windows as well and the PSP mp3, a mod would offer the same experience and could debugged on Windows and avoiding all the PSP hassles. ProQuake runs Half-Life maps on Windows and OS X and has for about 2 years.

It can connect to Quake servers and play and is in almost every way the same engine as the Windows, OS X and Flash versions. Since it can connect to standard reliable server engines, such mods written for it can be hosted on actual server. With the Universal Server project, mods don't need to fight for server space ... they can co-exist on a single server.

So you don't really even need to do testing on the PSP, as long as it runs in the Windows version with -mem 18 it would run on the PSP so you can have a multiplatform mod; the difficulty of testing and modding directly on the PSP is a pain and this alleviates most of that. Someone without a PSP could play it, someone with OS X could play it.

[There is a neglected Linux ProQuake build too.]

[Jukki]

Great work Baker

I copied the Draw_AlphaPic code, And I have to reset it's coordinates. It is still cool. One problem with it though, is that the pink color(159,91,83) turns out a transparent white. I wonder why....

same thing. Is there a fix for this. (othere wise jukki thanks ALOT)

[Baker]

same thing. Is there a fix for this. (othere wise jukki thanks ALOT)

I might take a look at it tonight.

I'm trying to wrap up integrating the rest of the PSP engine into ProQuake's baseline code.

And I'm faced with the reality that PSP engines need more menus to speed up user interaction.

I'm not exactly sure what I will be working on tonight, but I hope it is productive.

[revelator]

not sure but i remembered something.

the pink color might be picked up as an alpha layer not sure though.

a checkerboard texture with pink/white are sometimes handled like that so might be an explanation why it turns up as transparent white
but in regards to psp rendering im not so sure.

[Mexicouger]

Can't wait for Proquake Psp Baker! I Love the engine so far

Finish HLBSP

[Baker]

I've made a lot of progress on the engine.

[Jukki]

I've made a lot of progress on the engine.

nice to hear. whats your eta for stable version? I stopped working on kurokquake ngine just beacuse of this




ontopic. Does anyone have fix for pinky turning whitey?

[Baker]

I've made a lot of progress on the engine.

nice to hear. whats your eta for stable version? I stopped working on kurokquake ngine just beacuse of this

ontopic. Does anyone have fix for pinky turning whitey?

A couple of days. Usually I release various beta stage versions, but I have this one running so well and have killed so many bugs that I am just going to focus on making the release super high quality.

The main thing that means at this point:

If the PSP engine hates a map or mod, it just "dies" usually. I want to know why it certain maps make it die; it should ideally produce an error. I also want to be able to emulate the PSP limits reliably in the Windows ProQuake build to make testing easier. Debugging on a PSP is slow and tedious.

That being said, this engine is probably the most stable and reliable PSP engine because a lot of error checking has been added it to it. It can run Quake and Kurok just fine.

More info as I wrap up stuff in preparation for a release.