Draw_string with alpha

[frag.machine]

Okay, this may look silly to more experienced OpenGL coders, so my apologies for asking silly questions . Anyway, I wasted a good amount of time trying to figure this out alone but got no luck. I am trying to modify the Draw_String () to accept an alpha value, but so far this is simply ignored and the string is drawn solid like regular Draw_String. Here's my code:

Code: Select all

extern      gltexture_t *char_texture;
void MyDrawString (int x, int y, char *str, float f)
{
   if (y <= -8)
      return;         // totally off screen

   if (f > 0.0f)
   {
      GL_Bind (char_texture);
      glBegin (GL_QUADS);
      if (f < 1.0f)
      {
         glEnable (GL_BLEND);
         glColor4f (1,1,1,f);
         glDisable (GL_ALPHA_TEST);
         glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
      }

      while (*str)
      {
         if (*str != 32) //don't waste verts on spaces
            Draw_CharacterQuad (x, y, *str);
         str++;
         x += 8;
      }

      if (f < 1.0f)
      {
         glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
         glEnable (GL_ALPHA_TEST);
         glDisable (GL_BLEND);
         glColor4f (1,1,1,1);
      }

      glEnd ();
   }
}

What am I doing wrong here ?

[Sajt]

Is the blendmode set properly?

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

[Spike]

opengl doesn't permit you to change lots of state between glBegin and glEnd. Logically the only things you're allowed to change there restricted to actual vertex attributes (colour/texcoords/position). What you're definitely not able to change is blend modes.

ps: glGetError() is your friend. :)

[mh]

The fixed version would look something like this:

Code: Select all

extern      gltexture_t *char_texture;
void MyDrawString (int x, int y, char *str, float f)
{
   if (y <= -8)
      return;         // totally off screen

   if (f > 0.0f)
   {
      GL_Bind (char_texture);

      if (f < 1.0f)
      {
         glEnable (GL_BLEND);
         glColor4f (1,1,1,f);
         glDisable (GL_ALPHA_TEST);
         glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
      }

      glBegin (GL_QUADS);

      while (*str)
      {
         if (*str != 32) //don't waste verts on spaces
            Draw_CharacterQuad (x, y, *str);
         str++;
         x += 8;
      }

      glEnd ();

      if (f < 1.0f)
      {
         glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
         glEnable (GL_ALPHA_TEST);
         glDisable (GL_BLEND);
         glColor4f (1,1,1,1);
      }
   }
}

Also check your Draw_CharacterQuad function and make sure there's nothing happening in there that shouldn't be.

[frag.machine]

Heh, not mine, it's FitzQuake code I'm just messing around.

Draw_CharacterQuad has no state changes, IIRC it's only feeding vertexes to the pipeline. Thanks for the tips guys, I'll try this later.

[ceriux]

if you get it working you should post up a pic of it working.

see thru text in hl always annoyed me.

[frag.machine]

if you get it working you should post up a pic of it working.

see thru text in hl always annoyed me.

For the record, it was indeed just a case of moving the glBegin() and glEnd() so the state changes now happens out of the block delimited by them. It's much easier when you know what you're doing. Thanks again for the help, guys.

[ceriux]

way better than half-lifes =D looks great!

[frag.machine]

Some experiments with the "hud" command idea...

[Baker]

Looks really nice. All of it.

[r00k]

Could be used to interpolate the hud face animation, or fading of centerprint messages etc..

I used the alpha channel once apon a time when making this gif

[Sajt]

What's up with the row of messed up pixels above the quakeguy heads on that last screenshot?

[frag.machine]

No idea yet . I used the regular engine functions to load and draw it (Draw_PicFromWad() and Draw_Pic() ).

[Spike]

glquake writes into the wad data after the first time its loaded.
those pixels that you can see, those are integers. :)
its actually a glpic_t that you can see.
the second time its loaded, the image data comes from the wad again, but this time it already has the glpic_t corruption from last time around.
that's what those messed up pixels are.
the actual renderer is fine, its just the image loader/wad code at fault. it would work fine with a lmp. Or you could find the existing image instead and reuse it.

[frag.machine]

hmm, that's make sense. Thanks for the info Spike, I'll think about some clean way to deal with this later.