Debugging a text problem - 'invisible' text

[Laurent]

GDebugger shows the glyphmap as invisible, as well as the saved image.

It's freetype.

Ah, ok.

But a simple code works, so we still don't know if:
- your code contains an undefined behaviour that somehow messes up the font's texture
- your code contains something unusual that exhibits a bug in FreeType

Until you succeed to reproduce it with a simple example, you can't send a bug report to anyone.

[Qix]

Laurent, check the link I posted earlier. It's a simple example. The bug originally manifested in the full program, but the small-scale worked fine. Then after updating/building from source the small scale stopped working as well.

Already submitted a bug report, as suggested by the people in IRC.

[Laurent]

Laurent, check the link I posted earlier. It's a simple example. The bug originally manifested in the full program, but the small-scale worked fine. Then after updating/building from source the small scale stopped working as well.

Sorry, I totally missed it.

But if it works with some graphics cards, how could it be FreeType? FreeType doesn't use the graphics card at all, it only generates pixels, and SFML copies them to a texture and draws them with OpenGL.

[Qix]

There is an ATI card where it works. I don't know, I'm so confused as to why it's working on some and not others - I knew that freetype loads the pixel data and that's it; has nothing to do with the graphics card.

Which is why this is so confusing. I would copy the build onto multiple computers and some would work and some wouldn't. All up to date graphics drivers. The loaded texture would be transparent on some and work on the others. Images worked on all of them, however.

I'm trying to build with the trace/error macros enabled on freetype (as they suggested in the bug report I sent off over there) - however, the entire library is a mess and it is requiring a ton of hacks just to get them to work.

[Laurent]

I'm trying to build with the trace/error macros enabled on freetype

Don't bother with that, just save the glyphs bitmaps directly to a file (before they are copied to the texture) and you'll see that they are all generated correctly.

At line 474 of Font.cpp, insert something that creates a sf::Image from &m_pixelBuffer[0], w, and h, and save it to a file (a different one for each call).

Trust me, this is most likely a driver bug, there were a lot of similar problems with AMD drivers recently. Look at which version of the driver the working computers use, and try the same version on yours.

[Qix]

I will do that now.

Trust me, this is most likely a driver bug, there were a lot of similar problems with AMD drivers recently. Look at which version of the driver the working computers use, and try the same version on yours.

I did There was another thread I think I mentioned earlier that said to upgrade to the .12 beta catalyst drivers. I did that; no beans.

[Laurent]

I was more thinking about an older version of the driver.

[Qix]

I did what you said to do (put that image save in loadGlyph) and just to make sure I set a breakpoint. It never gets called.

Scratch that, I realize why it's not. I'll post back with the images in a sec.

[Qix]

The sizes are right, the images are still transparent.

        // Write the pixels to the texture
        unsigned int x = glyph.textureRect.left + padding;
        unsigned int y = glyph.textureRect.top + padding;
        unsigned int w = glyph.textureRect.width - 2 * padding;
        unsigned int h = glyph.textureRect.height - 2 * padding;
               
                // DEBUG
                sf::Image img;
                img.create(w, h, &m_pixelBuffer[0]);
                std::stringstream ss;
                ss << "dbg_pxlbuf_save_" << _saveCount << ".png";
                if(!img.saveToFile(ss.str().c_str()))
                        printf("WARNING: Could not save debug pixel buffer to file\n");
                ++_saveCount;

        page.texture.update(&m_pixelBuffer[0], w, h, x, y);
 

[attachment deleted by admin]

[Qix]

Raw pixel data for those is attached. I'm not sure of the format of the raws so photoshop is just spitting out garbage, but maybe they can be of use.

This is a file being opened and writing &m_pixelBuffer[0] (with size = m_pixelBuffer.size()).

[attachment deleted by admin]

[Laurent]

The sizes are right, the images are still transparent.

Hmm? Did you use the image preview of Windows explorer to watch them?
They are perfectly fine, I can see that the glyphs are 'T, 'e', s', and 't'.

[Qix]

Yes laurent... Then why can't I see them?

EDIT: FFS screen brightness was too high. Alright, so it's not freetype.

If images load in fine, why aren't these working? No matter the background color, they won't display. Lua is reporting their bounds to be fine, so it's not a polygon thing as far as I can tell. Further, there aren't any incorrect things in sf::Text such as the vertices being defined backwards... Images work, so should Text >.>

[Laurent]

Driver issue

[Qix]

Driver issue

But that makes no sense if images can be loaded/displayed just fine. Aren't image textures the SAME THING as text textures?

[Laurent]

They are. But the context in which they are used is different. And it's enough to exhibit a strange driver bug. Don't try to understand, there's nothing to understand. Graphics driver bugs are mystical, don't expect something obvious such as "texturing is broken", it's much more subtle.