Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Debugging a text problem - 'invisible' text  (Read 12966 times)

0 Members and 1 Guest are viewing this topic.

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Debugging a text problem - 'invisible' text
« on: November 13, 2012, 05:17:29 am »
Alright, I'm stumped. It's been three days and I'm running out of options - I'm to the point of just trying random, seemingly pointless stuff just to get something to work.

I'm writing a program that binds to Lua and allows scripts to draw things to the canvas. The code is completely custom and is too large to simplify down (sorry Laurent, this one won't be easy).

I have tried running a bare-bones text drawing program, which, of course, works.

I have a font preloader (which does exactly what it sounds like - creates a font and loads from a file, stores it in an array, and then returns a raw pointer [Lua uses raw pointers]), as well as an image loader that works pretty much in the same way.

Images have a wrapper class, whereas the sf::Font class is bound directly to lua (no wrapper).

There is also a text class that lightly wraps the sf::Text class.

Text was working intermittently (certain, seemingly similar builds would show/hide text at random) until it just stopped working altogether. The text just seems to be completely invisible.

I have stepped through the program to the point my F10/11 keys are screaming for mercy, and all pointers/references/arguments/etc. seem fine. I have compared runtime break data for Fonts between the working sample program and the actual app - everything looks fine. There are absolutely no errors or exceptions, the text simply does not display.

The other weird thing is that images draw just fine. They also follow the same code-path as text does. It  seems to be an internal thing.

Here is a few code snippets to help visualize the code-path:

Button (which is what holds the text) instantiates the label (wrapper Text class):

Text                            _label;

which instantiates itself using the sf::Text default constructor. The button class then sets the label's string and calls the lua script to set itself up.

_label.setString(std::string("Test"));

-- Get Label
local label = self:GetLabel()
       
-- Set up font/color
label:SetColor(R.Color(255, 0, 0, 255))

-- _buttonFont is a font that was pre-loaded earlier in the script
self:GetLabel():SetFont(_buttonFont)

The above lua code works as far as I can tell; Even deeper into the draw functions, the color values are correct (255,0,0,255) and the font seems to be normal (the pointers are valid, the page count is 1 or so, and the pixel data is reasonable).

The code then continues on to draw, calling the lua callback with a reference to the target (which wraps a pointer to a rendertarget):

-- Draw image then text on top of it
--      Commented out image drawing; It works fine
--target:Draw(_buttonIdle)
target:Draw(self:GetLabel())

The target draw method is as follows:

ITarget&                                draw(Drawable& drawable)
{
        // Is it visible?
        if(!drawable.isVisible())
                return *this;

        // Init
        initStack();

        // Combine transform
        _transformStack->push(_transformStack->top());
        _transformStack->top().combine(drawable.getTransform());

        // Draw
        drawable.drawThis(*this);

        // Pop Transform
        _transformStack->pop();

        // Return
        return *this;
}

It is confirmed the drawable is visible (which is a method that belongs to a wrapper) and the transform stack (used to combine transforms for 'component'-ized drawables) is initialized and working fine.

The code goes on to draw the drawable's wrapper function, which calls the pure virtual method "onDraw" that actually does the drawing.

// Draw
target.drawRaw(*this);

drawRaw() simply calls another target wrapper draw method to call the SFML draw method itself:

// Copy + Combine states with transform
sf::RenderStates s = states;
s.transform.combine(_transformStack->top());

// Lock and load
lock();
_ref->draw(drawable, s);
unlock();
 

Again it pushes the transforms, etc. and locks (thread and GL states, including setting the target to be active) and draws.

This triggers the SFML sf::Text draw method. The m_font information at that point looks like this:


Beyond that, everything seems fine. Like I said, the color is there, the font information looks fine, and with the help of notepad+watch lists, I've confirmed all pointers are as they should be.

I seriously don't know why text is just invisible.

---

My question isn't 'how do I fix this' or 'what's wrong with my code' (since condensing this to something simpler would be pointless) - but more of how can I begin to debug text drawing? I have already updated GLEW and Freetype, building from source, and I'm using the latest (as of a few hours ago) dev snapshot of SFML 2.0.
« Last Edit: November 13, 2012, 05:44:44 am by Qix »
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Debugging a text problem - 'invisible' text
« Reply #1 on: November 13, 2012, 08:03:37 am »
You can try an OpenGL debugger (gDebugger?), it will show you the current states and textures that are used for drawing.

You can also reduce your code to the minimum. Since a minimal code written from scratch doesn't reproduce the problem, instead try to remove irrelevant parts from your app, until you reach the minimum amount of code that still has the problem.
Laurent Gomila - SFML developer

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Re: Debugging a text problem - 'invisible' text
« Reply #2 on: November 13, 2012, 04:04:42 pm »
You can try an OpenGL debugger (gDebugger?), it will show you the current states and textures that are used for drawing.

You can also reduce your code to the minimum. Since a minimal code written from scratch doesn't reproduce the problem, instead try to remove irrelevant parts from your app, until you reach the minimum amount of code that still has the problem.

Oh interesting, didn't know such a thing existed.

I will create a new branch and git and see what I come with.

Thank you Laurent!
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Re: Debugging a text problem - 'invisible' text
« Reply #3 on: November 13, 2012, 04:18:34 pm »
Alright so it might be nothing, but with gDebugger, two things happened - one, the image texture is fine, but what I'm assuming is the font texture (the program only loads two and gDebugger is reported two) is completely invisible.

Two, I'm getting the error

Quote
Debug String: Detected error: The debugged process asked for an extension function pointer (glUseProgramObjectARB) from one render context, but called this function pointer in another render context (context #3)

Context #3 is where the two textures are being loaded.
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Debugging a text problem - 'invisible' text
« Reply #4 on: November 13, 2012, 04:39:10 pm »
You can find whether error #2 is part of the problem or not, by not using shaders.
Laurent Gomila - SFML developer

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Re: Debugging a text problem - 'invisible' text
« Reply #5 on: November 13, 2012, 04:41:58 pm »
Well unless there is some sort of build setting or something to not use shaders, my code doesn't use any shaders at this time, nor does it touch any sort of shader aspect of SFML.
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Debugging a text problem - 'invisible' text
« Reply #6 on: November 13, 2012, 04:53:22 pm »
Ah, so I guess that the error refers to glUseProgramObjectARB(0) which is called once when you create a render-target.

So it probably has nothing to do with the problem.
Laurent Gomila - SFML developer

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Re: Debugging a text problem - 'invisible' text
« Reply #7 on: November 13, 2012, 05:07:06 pm »
While I'm shaving down the problem, is there anywhere else I should be looking?
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Debugging a text problem - 'invisible' text
« Reply #8 on: November 14, 2012, 07:54:34 am »
I have no idea ;D
Laurent Gomila - SFML developer

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Re: Debugging a text problem - 'invisible' text
« Reply #9 on: November 14, 2012, 05:11:07 pm »
Is there a way to get gDebugger and Visual Studio to debug the same process at the same time.
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Re: Debugging a text problem - 'invisible' text
« Reply #10 on: November 18, 2012, 06:14:45 am »
This seems to be a bug with ATI. After almost a week of debugging and testing, I've tested the same program on multiple ATI, nVidia, and integrated Intel graphics cards. So far, every single ATI card has failed to show text, while every single nVidia/Intel integrated has worked.

It's going to be a while more before I can do any opengl debugging on ATI because CodeXL is refusing to work on any of the machines I'm testing on.

Really stressed out about this!

ATI Count: 3
nVidia Count: 3
Integrated Intel Count: 2


EDIT: Just stumbled onto this link. The white artifacts aren't showing up on mine, but I need to check out the beta of the catalyst driver.
« Last Edit: November 18, 2012, 07:05:14 am by Qix »
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Re: Debugging a text problem - 'invisible' text
« Reply #11 on: November 18, 2012, 11:01:27 pm »
As of the latest freetype build and SFML 2.0 dev snapshot, the sample code is not working. I've tried with two different fonts, one with both TTF and OTF versions.

Some results:

Working (AMD 6870)


Not working (ATI Mobility Radeon HD 5000 Series)

Quote
The graphics driver installed in your computer returned information that shows that your graphics adapter should be able to run Topicscape.
-----------------------------------------------------------------------
Graphics Adapter:   Intel(R) HD Graphics
Manufacturer:   ATI Technologies Inc.
GL Version:   4.2.11991 Compatibility Profile Context
Resolution:   1920 X 1080 X 0 bpp
Driver version:   .
-----------------------------------------------------------------------
Windows Version: Windows 7 Professional
CPU: Intel(R) Core(TM) i5 CPU       M 480  @ 2.67GHz(2660MHz)
Physical Memory Usage: 1439/4095MB
Virtual Memory Usage: 4095/4095MB

Working (NVidia Gt630m)
Quote
-----------------------------------------------------------------------
Graphics Adapter: Intel(R) HD Graphics 4000
Manufacturer: Intel
GL Version: 4.0.0 - Build 9.17.10.2867
Resolution: 1920 X 1080 X 32 bpp
Driver version:
Video Memory Size: 2112 MB
-----------------------------------------------------------------------
Windows Version: Windows 8 Pro
CPU: Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz(2295MHz)
Physical Memory Usage: 4095/4095MB
Virtual Memory Usage: 4095/4095MB

Other working cards (Without info)
  • NVIDIA GeForce GTX 560M


Should a bug report be filed?
« Last Edit: November 18, 2012, 11:36:58 pm by Qix »
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Re: Debugging a text problem - 'invisible' text
« Reply #12 on: November 19, 2012, 08:32:49 am »
This seems to be a bug in freetype. I just implemented libdrawtext (which also uses freetype) and I get the same result.

Seeing as how Laurent is in the actual credits as a major contributor, hopefully he can have some insight on this.
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Debugging a text problem - 'invisible' text
« Reply #13 on: November 19, 2012, 08:48:05 am »
Quote
This seems to be a bug in freetype
I don't think so. If the sf::Font's texture is properly filled with glyphs (which you can check with font.getTexture(size).copytoImage().saveToFile()), then FreeType did its job successfully. If it's a rendering issue, it's between SFML and your graphics driver. And I really think it's your driver (hint: it works on nVidia cards) ;)

Quote
Seeing as how Laurent is in the actual credits as a major contributor
A contributor of what? Where?
Laurent Gomila - SFML developer

Qix

  • Full Member
  • ***
  • Posts: 139
  • I am Qix!
    • View Profile
    • Natoga Technologies
Re: Debugging a text problem - 'invisible' text
« Reply #14 on: November 19, 2012, 08:54:50 pm »
I don't think so. If the sf::Font's texture is properly filled with glyphs (which you can check with font.getTexture(size).copytoImage().saveToFile()), then FreeType did its job successfully. If it's a rendering issue, it's between SFML and your graphics driver. And I really think it's your driver (hint: it works on nVidia cards) ;)

GDebugger shows the glyphmap as invisible, as well as the saved image (which is attached).

It's freetype.

// DEBUG
        sf::Font fnt;
        if(!fnt.loadFromFile("sys/theme/rippl/fonts/MankSans.ttf"))
        {
                LOGW("Could not load manksans for debug");
        }
        else
        {
                fnt.getTexture(30).copyToImage().saveToFile("glyphsheet_dbg.png");
        }
 

UPDATE: Tried with the latest freetype snapshot (fa22ec1cfba5975c0622e374f8506c742d3f8d18) and the problem still persists.

A contributor of what? Where?

Oops, went back and looked - I think it was the jpeg/png library that had your name in the credit-comments ;) For some reason I was thinking it was freetype.

[attachment deleted by admin]
« Last Edit: November 19, 2012, 09:22:47 pm by Qix »
~ Qix
Creator of Rippl Studio
Code: [Select]
<danharibo> iostream: I don't do enough drugs to think that's a good idea.