high, im trying to draw a health bar over the enemies head... anyway, im having some problems.. for some reason, the quad is showing up transparent and i dont understand why. its prolly something obvious so ill just show you guys the code

 //draw this quad red 

glColor4f(1.0f,0.0f,0.0f,1.0f);

//the top left corner coordinates of where the health should be drawn

	 float hx = xPos - (float)scroll_x;
	 float hy = yPos - (float)scroll_y - 20.0f;

	 float hheight = 10.0f;
	 glBegin(GL_QUADS);               
   
         //top left

	glVertex2f(hx,hy); 
  
        //top right

	glVertex2f(hx + health_to_draw,hy); 
	
        //bottom right

	glVertex2d(hx + health_to_draw,hy + hheight); 

         //bottom left

	glVertex2f(hx,hy + hheight);//glVertex2f(hx,hxb); 

	 
   glEnd();

ok, i DO have glEnable(GL_BLEND). glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). i call these 2 functions once in the begining of the code. this is what the quad looks like : i was thinking it does this because i have blending enabled, but at the top of my code, i explicetly state "draw this quad opaque", even with blending enabled, shouldnt my quad be opaque??? but here is the weird thing - if i put this code in a bracket of glDisable(GL_BLEND) / glEnable(GL_BLEND) (ie i disable blending for this code), my quad DOES show up opaque, BUT look at it - do you see the color? this doesnt look like 1,0,0 to me. 1,0,0 should be BRIGHT red, not this dark red which seems to show up transparently in the first picture also... anyone know why im getting these weird results? thanks for any help [edited by - graveyard filla on May 29, 2004 4:26:44 PM]

I think it is probebly because you do have GL_BLEND enabled. you should disable is before drawing the quad if you don''t want it blended, or not, other wise. Here, let MSDN explain it =>

glBlendFunc
The glBlendFunc function specifies pixel arithmetic.

void glBlendFunc(
GLenum sfactor,
GLenum dfactor
);

Parameters
sfactor
Specifies how the red, green, blue, and alpha source-blending factors are computed. Nine symbolic constants are accepted: GL_ZERO, GL_ONE, GL_DST_COLOR, GL_ONE_MINUS_DST_COLOR, GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_DST_ALPHA, GL_ONE_MINUS_DST_ALPHA, and GL_SRC_ALPHA_SATURATE.
dfactor
Specifies how the red, green, blue, and alpha destination-blending factors are computed. Eight symbolic constants are accepted: GL_ZERO, GL_ONE, GL_SRC_COLOR, GL_ONE_MINUS_SRC_COLOR, GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_DST_ALPHA, and GL_ONE_MINUS_DST_ALPHA.
Remarks
In RGB mode, pixels can be drawn using a function that blends the incoming (source) RGBA values with the RGBA values that are already in the framebuffer (the destination values). By default, blending is disabled. Use glEnable and glDisable with the GL_BLEND argument to enable and disable blending.

When enabled, glBlendFunc defines the operation of blending. The sfactor parameter specifies which of nine methods is used to scale the source color components. The dfactor parameter specifies which of eight methods is used to scale the destination color components. The eleven possible methods are described in the following table. Each method defines four scale factors, one each for red, green, blue, and alpha.

In the table and in subsequent equations, source and destination color components are referred to as (RS,GS,BS,AS) and (Rd,Gd,Bd,Ad). They are understood to have integer values between zero and (kR,kG,kR,kA), where

kR = 2mR – 1

kG = 2mG – 1

kB = 2mB – 1

kA = 2mA – 1

and (mR ,mG ,mB ,mA) is the number of red, green, blue, and alpha bitplanes.

Source and destination scale factors are referred to as (sR ,sG ,sB ,sA) and (dR ,dG ,dB ,dA). The scale factors described in the table, denoted (fR ,fG ,fB ,fA), represent either source or destination factors. All scale factors have range [0,1].

Parameter (f (R) ,f (G) ,f (B) ,f (A) )
GL_ZERO (0,0,0,0)
GL_ONE (1,1,1,1)
GL_SRC_COLOR (RS/kR,GS/kG,BS/kB,AS/kA)
GL_ONE_MINUS_SRC_COLOR (1,1,1,1) -
(RS/kR,GS/kG,BS/kB,AS/kA)
GL_DST_COLOR (Rd/kR,Gd/kG,Bd/kB,Ad/kA)
GL_ONE_MINUS_DST_COLOR (1,1,1,1)
GL_SRC_ALPHA (Rd/kR,Gd/kG,Bd/kB,Ad/kA) -
(AS/kA,AS/kA,AS/kA,AS/kA)
GL_ONE_MINUS_SRC_ALPHA (1,1,1,1) -
(AS/kA,AS/kA,AS/kA,AS/kA)
GL_DST_ALPHA (AD/kA,AD/kA,AD/kA,AD/kA)
GL_ONE_MINUS_DST_ALPHA (1,1,1,1) -
(AD/kA,AD/kA,AD/kA,AD/kA)
GL_SRC_ALPHA_SATURATE (i,i,i,1)


In the table,

i = min (AS,kA– AD) / /kA

To determine the blended RGBA values of a pixel when drawing in RGB mode, the system uses the following equations:

R (d) = min(kR,RssR+RddR)

G (d) = min(kG,GssG+GddG)

B (d) = min(kB,BssB+BddB)

A (d) = min(kA,AssA+AddA)

Despite the apparent precision of the above equations, blending arithmetic is not exactly specified, because blending operates with imprecise integer color values. However, a blend factor that should be equal to one is guaranteed not to modify its multiplicand, and a blend factor equal to zero reduces its multiplicand to zero. Thus, for example, when sfactor is GL_SRC_ALPHA, dfactor is GL_ONE_MINUS_SRC_ALPHA, and As is equal to kA, the equations reduce to simple replacement:

Rd= Rs

Gd= Gs

Bd= Bs

Ad= As (

)

Examples
Transparency is best implemented using glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) with primitives sorted from farthest to nearest. Note that this transparency calculation does not require the presence of alpha bitplanes in the framebuffer.

You can also use glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) for rendering antialiased points and lines in arbitrary order.

To optimize polygon antialiasing, use glBlendFunc(GL_SRC_ALPHA_SATURATE, GL_ONE) with polygons sorted from nearest to farthest. (See the GL_POLYGON_SMOOTH argument in glEnable for information on polygon antialiasing.) Destination alpha bitplanes, which must be present for this blend function to operate correctly, store the accumulated coverage.

Incoming (source) alpha is a material opacity, ranging from 1.0 (KA), representing complete opacity, to 0.0 (0), representing complete transparency.

When you enable more than one color buffer for drawing, each enabled buffer is blended separately, and the contents of the buffer is used for destination color. (See glDrawBuffer.)

Blending affects only RGB rendering. It is ignored by color-index renderers.

The following functions retrieve information related to glBlendFunc:

glGet with argument GL_BLEND_SRC

glGet with argument GL_BLEND_DST

glIsEnabled with argument GL_BLEND

Error Codes
The following are the error codes generated and their conditions.

Error code Condition
GL_INVALID_ENUM Either sfactor or dfactor was not an accepted value.
GL_INVALID_OPERATION glBlendFunc was called between a call to glBegin and the corresponding call to glEnd.


Requirements
Windows NT/2000: Requires Windows NT 3.5 or later.
Windows 95/98: Requires Windows 95 or later. Available as a redistributable for Windows 95.
Header: Declared in Gl.h.
Library: Use Opengl32.lib.

See Also
glAlphaFunc, glBegin, glClear, glDisable, glDrawBuffer, glEnable, glGet, glIsEnabled, glLogicOp, glStencilFunc

thanks for the reply, i have read that MSDN page before and it only explains the arithmitic behind blending. it doesnt explain why my quad is showing up near transparent, or why its not showing up bright red like it should...

also, i DO want that quad to be blended, but not near transparent like it is now... if i disable blending, and try to specify

glVertex(1.0f,0.0f,0.0f,0.5f);

that i want the quad to be bright red with half transparency, it will be fully opaque (probably because i disabled blending).... but if i keep blending enabled, well, it will be very transparent (see above pic) even with 1.0f specified as the alpha color. does anyone know why this is happening, and how i can get a LIGHTLY blended bright red quad ?

thanks for any help!!

dude, you rock. that fixed it ... im guessing it binds a NULL texture to the quad or something? i dunno, but it works, thanks.