I bet you are doing something wrong.
I don''t know what it is.
But it has to be really simple.
Just a boolean from GL_TRUE to GL_FALSE or something like that.

Did you try to "forget" the textures (eg, don''t load any texture, and don''t bind them) ?

I don''t uderstand...

I went back to my code before I added the support for text.
I commented all the functions that are in lesson #13 (except WinMain and WndProc) and replaced them with the ones from lesson #13.
I added the lines of my code one by one, rebuilding and running my project after each new line...
Everything is OK until I load some textures. If I load even one texture, the color of the text goes black. I don''t understand why. For loadind the textures I use the code from lesson #10 with a little modifications (I create just 1 texture from each loaded bitmap instead of 3 from lesson 10).
If you know what might be the problem please help me. Thanx

Could you either set the code online or post it there please ?
The zip file is a good idea, but it does not allow everyone in the forum to read it.


I think your memory overlaps somewhere.
If you did not allocate enough memory, it's more than possible to experience such problems.
you have to check that you allocates the memory correctly while loading the texture or else you're already dead

Edited by - vincoof on January 22, 2002 3:53:00 PM

FINALLY IT WORKS.

First of all I want to thank you people for your help.

I still don''t know where the problem was but at least it works now. I''m so tired that I''ll not look for the error today.

As a said in the previous post a started by replacing my code with code from lesson #13.
After I loaded the textures all I had to do was to turn of the texture mapping while printing the string.
I don''t know why my code didn''t work. I''m pretty sure that it was the same as in lesson #13. I just changed the variable base to FontBase.
Anyways it''s working now and I''m happy and tired. I''g going to take a bath and go to bed (it''s 10:10 P.M. here right now).

Once again thank you people for your help.

I got a chance to look over the zip you sent me, and I figured out what was happening. It took a little bit, but the first thing I found was that if you swapped the order of the glRasterPos() and glColor3f() so that you set the color before the raster position, then it would work fine. I didn''t understand wny this is, and after looking in the blue book and running a few tests using glGetFloatv() for both GL_CURRENT_COLOR and GL_CURRENT_RASTER_COLOR, I realized what exactly was going on.

When you set the current raster position, it also sets the current raster color and texture coordinates. Where it gets those values basically depends on whether lighting is enabled. When lighting is disabled, as in your program, it gets the new raster color from the current color associated with GL_CURRENT_COLOR (which you would set using glColor3f()). But this means after you call glRasterPos(), the current raster color (GL_CURRENT_RASTER_COLOR) stays the same color as at the time of the glRasterPos() call, regardless of any calls to glColor3f() after it, even if it''s before drawing the font.

To make a long story short, the glColor3f() call was valid and was properly processed by GL, but in order for it to effect your font, you''ll have to move it to before the glRasterPos() call.

The blue book is online somewhere if you want more info about glRasterPos(), I''m sure opengl.org has a link somewhere.

Jason

omg, I think I have an idea of what it could be.

In OpenGL, every procesing related to raster requires to have a *valid* raster position.
Before calling glRasterPos, the raster position is not valid. So, every processing related to raster (like changing the raster color) is ignored.

I''ve read that somewhere in OpenGL specifications.
I''ll try to pick up the lines of it.

There are some lines written about glRasterPos :

quote:

---

2.12 Curent Raster Position
The transformed coordinates are passed to clipping as if they represented a point. If the "point" is not culled, then the projection to window coordinates is computed (section 2.10) and saved as the current raster position, and the valid bit is set. If the "point" is culled, the current raster position and its associated data become indeterminate and the valid bit is cleared.

---

(OpenGL specifications 1.2)

So I guess that when you call glColor, the "point" is culled and the associated data (which includes current raster color) is indeterminate.
Because the raster color is initialized as (1,1,1,1), it keeps this values, and never changes later.
At least, that's what I think.

You should try to check the current raster position valid state :
GLboolean is_valid;
glGetBooleanv(GL_CURRENT_RASTER_POSITION_VALID, &is_valid);

Check it before and after calling glRasterPos. If this theory is correct, the return value may be false before glRasterPos, and true after glRasterPos. Please check it on the erroneous code (if you haven't deleten it yet).

jassmith : thank you for your help. I probably wouldn't have found that without you

Edited by - vincoof on January 23, 2002 4:47:27 AM

Than you guys.

That was exatly the cause of my problems. And that was a reason why I didn''t manage to solve it. I thought the problem was in glColor3f or the enabled texture mapping. I didn''t thing that glRasterPos could be it so I never looked at it.

Thank you again for your help.

NO NO NO NO NO
My theory is wrong
But I finally figured out what it is

In fact, the raster color is assigned when glRasterPos is called, and only at this time !
It is a bit normal, from a particular point of view : raster color is assigned only during a raster operation.

Let''s walk through some code :

glColor(1.0f, 1.0f, 1.0f); /* reset color to white for "good" texturing */
glEnable(GL_TEXTURE_2D);
/* draw textured objects here */
glDisable(GL_TEXTURE_2D);
glRasterPos2f(X_text_pos, Y_text_pos); /* set text position */
glColor3f(1.0f, 0.0f, 0.0f); /* set color to red */
glPrint("My text supposed to be red"); /* draw text */

What would you expect from such code ?

It displays white text ! And that is normal !

when glRasterPos2f is called, the current color is white (because latest call to glColor was glColor3f(1.0f, 1.0f, 1.0f) for texturing) : the raster color becomes white.
when glColor3f(1.0f, 0.0f, 0.0f) is called, it does NOT change the RASTER COLOR, so the red color is ignored in the raster operation, unless glRasterPos is be called just between glColor and glPrint.
when glPrint is called, the last known RASTER COLOR is white, so the text is displayed white, regardless to CURRENT COLOR (which is red).


The thing you have to remember is that CURRENT_RASTER_COLOR and CURRENT_COLOR are two distinct colors.
glColor immediately updates CURRENT_COLOR (unless lighting is enabled, but that''s another story) but does not immediately update CURRENT_RASTER_COLOR. The CURRENT_RASTER_COLOR will be updated only when gRasterPos will be called.


Finally, I think that covers the whole probelm.
phew, man I need to drink something.

Did nobody think to tell him to just set the texture environment mode to GL_MODULATE? Thats all there is to it.

Sheesh.. some of the responses I read in this thread!