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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Qix

Pages: 1 [2] 3 4 ... 10
16
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 28, 2012, 06:40:21 am »
Found the bug. Even have a proposed workaround.

This is the wiki page with the entire bugfind log. Reading some of the other pages linked in this thread, it gave me the idea to test a few things.

Tl;dr scroll to very bottom (summary section). I don't know if this is the same bug as others are having, but it may help.

I will try the workaround and get back to you.

EDIT: This bug, whether it be an SFML bug or a driver bug, is indeed mystical. The workaround seems to be:

Load the desired font
Load a dummy font
Create the text object
Apply desired font
Apply dummy font
Apply desired font again
Unload dummy font and desired font (if I'm understanding how the font/text creation system in SFML works, this will leave just the text object. I realize no sizing operations can be carried out after that at the risk of access violations).

This has to be done for each font (yes, load/unload even the same font for each text object) or else glyphs are missing.

If this works, and no other character sizing is done, then the only downside to this would be slower load up times and a ton of file reads. Memory-wise it shouldn't be too intensive.

I'll try this workaround and see if it works.

17
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 28, 2012, 01:17:55 am »
I thought I tried updating to 12.11 with no good results. I'll try again on this computer. Current version is 12.6. I'll let you know.

EDIT: Well the small scale works on this now after updating, but the main app doesn't. However, it's kind of mangled from all of the testing. I'm going to do a hard reset back to a commit where it should have worked and test from there.

EDIT2: Still recooping from the reset; since SFML was in a submodule the project configurations were a little different. Before the reset I modified the sample code a bit to do the drawing in a separate thread, much like how the main app does it. Still worked fine, so hopefully going back to a presumed working copy will help.

EDIT3: Alright, back to images working and text not working :/

EDIT4: Just tried on integrated intel card. The version I have is working. Anything I should try? I don't know how the internals of opengl work all that well, so I'm kind of on standby for any suggestions.

EDIT5: I'm going to try from the other way; I'm going to try to recreate the problem with the samples instead of stripping the main program down.

EDIT6: Alright, interesting results. Couldn't re-create the bug going backwards. However, the code that triggers the hierarchy of drawing in the main program was commented out and I replaced it with just a simple draw of a text object. It worked. I'll keep going down the structure until it stops drawing to see where it's fouling up.

EDIT7: I found where the borking is happening. I know it's probably meaningless to anyone, but the following code works:
debug(); // Sets up a test label/font
getBehavior()->onInit(); // Behaviors set up the interface components
 
and the following does not:
getBehavior()->onInit(); // Behaviors set up the interface components
debug(); // Sets up a test label/font
 

I'll do a bit more testing with the code inside of onInit to see what the issue is.

EDIT8: Very strange. onInit() isn't breaking the debug text (which is completely unrelated); the debug text requires the call to onInit(). I'll start commenting out stuff in onInit() to see what breaks it.

18
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 27, 2012, 05:07:13 pm »
Unless you use the not-yet-released SDL 2.0 with the OpenGL back-end, SDL doesn't use OpenGL, it's plain software rendering.
If that's what "all other OpenGL libraries" mean, sorry but this is not a valid argument ;)
Yes, SDL 2.0. I think I would have noted that before talking about SDL.

Which ones?
All source engine games, all webGL experiments, basically any other application that uses OpenGL and text works perfectly fine.

That ATI drivers are crappy. That's the only thing to say. And until you fully read and understand SFML code, you'll have to trust me.
Laurent, we're both programmers. You and I both know that "trust me" isn't a term that is easily digested.

It's frustrating, I know. But again, don't say "everything else" if you can't be more precise on this point.
I can be precise. I've had no other text drawing issue when using any other OpenGL application other than the samples I use with SFML.

It is, because I'm not supposed to work around driver bugs, and I usually don't unless the modification straight-forward.
If I had a lot of free time I would probably write a test program and start investigating. But I can't. But you can ;)
I have written a test program, and you shot it down as something I shouldn't care about. Now we're here, and you're suggesting I do the same thing. I'm out of options.

As the library maintainer, I know a lot of driver bugs reported by users, and I know my code perfectly. You know none of them (or at least not better than me), so please don't say there is a flaw, unless you can spot it.
That is a really shitty excuse for ignoring an obvious problem.

I bought one only to help users with ATI bugs. But I don't have the time too investigate.
Well we're users, and we're having ATI bugs. You also won't help us fix it, so you must want to fix it on your own.

Perhaps it's time to start investigating.

I know that something can be done, there is always a ugly workaround to apply to make things work. But ATI won't fix their drivers if everyone works around their bugs.

Two retorts to this god awful statement: 1) Please, enlighten us. I'm sure many people would gladly put this "ugly workaround" in as a temporary fix to this gaping hole of a bug. 2) That's like saying "my son won't learn to not play with fire if we keep pouring water on him when he dowses himself in gasoline and decides to have a smoke".

Seriously? ATI doesn't give two shits about SFML. It's ATI. A big, multi-million (possibly multi-billion) dollar corporation. Their intent is to make money their own way. If they had cared the least bit about making sure there weren't any bugs, we wouldn't be having this issue in the first place.

You aren't ATI's father, you can't 'teach them a lesson'. They have a bug that has been present for several versions now, and the next couple of betas they have put out have failed to fix it thus far.

I'm not angry but I'd like people to focus on technical and relevant details. Saying "there's a flaw" or "it works with all other libraries" without any detail doesn't lead anywhere. Debug stuff on your side, do more tests, try to understand the code, etc. Don't come here every hour to say "there's a flaw". Please.

We've given you many, many "technical and relevant details". You're telling us you're not going to explain anything and that SFML is just fine and we should just ignore this bug. I've been debugging this for two weeks. There is no other explanation other than SFML isn't working without some help from you.

I'm not here every hour. I spent a week trying to fix it on my own, and finally made a thread about it. In fact, I've been taking a break from the project for another week now waiting for replies from somebody shedding some light on the matter. You gave up on it telling me that the drivers were mystical and I shouldn't try to understand why there is a bug.

To me, that sounds like you either don't care about SFML working right, just about it being clean. Secondly, it sounds like you're so caught up with the idea that SFML is yours and you want nobody to touch it that you're forgetting that it's open source and ignoring the fact that there is something wrong with it!!

There is a bug that can be fixed in SFML. We've given you all we have so far. We are two users who would rather not have to stop using SFML, which is why we made threads. I have personally spent more time on this than I should have had to spend, and the fact that the only person who seems to know this magical workaround is cock-blocking his user-base is utterly frustrating.

I would advise that instead of attacking us for asking for help, perhaps it's time to break out the ATI, give us some direction with debugging, or tell us about this magical fix from the mystical garden of workarounds...

So... I can't help at the moment, I'm really sorry, but you two can continue to investigate and find more interesting things related to this bug. I think that's the best thing to do until I can help more.

Look at the "RenderTexture bug" thread: someone decided that it was time to solve this old problem, and within a few days it was solved. Users did an amazing job.

Dear god man. We have investigated. We are at a dead end. What the hell do you expect us to do?

Not everyone has an ATI card, and not all ATI cards are affected. The only people who are going to be interested in investigating are us and you, and you seem to be doing a good job at being nonchalant about your own project.

19
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 27, 2012, 04:38:58 pm »
Please, don't hate each other now because there is a bug somewhere we don't know yet. I am really on it, and I think I have gotten pretty far on this one already. I think Laurent, we all know you'd rather keep SFML as-is and blame everything to ATI drivers, but since we don't understand the problem yet this is a stupid approach. I hope you understand that in our eyes, something can be done from SFML's side. Also, we probably have made it clear that we do not expect you to fix this for us, not only because you don't have the testing capabilities but also because we know you do this in your free time, and you don't have that much free time for issues you don't understand. But please stop trying to convince us to wait for some magic in ATI drivers to happen that fixes the issue.

I understand that some people may be angry with you (maybe Qix is) for not caring about this for a long time now. I don't think that is worth it, since you as the developer of a great piece of free software still have no responsibility for it to work. We should make it work together.

As you may have noticed, I have some basic understanding of what is going on in OpenGL myself, and while I appreciate any help from everyone here to understand the problem, I may need your help to understand what SFML is doing and why. I can't read the whole codebase and understand it, you have designed it and I would rather have some details explained by you than guessing what it is supposed to do and why. So that is what we need you for. I think we can solve the problem if we stay in touch, and you stop trying to blame ATI and forget about this bug.

+1

20
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 27, 2012, 04:20:21 pm »
Please tell me which ones you've tested, so that I can compare source code.

SDL, Laurent. I've said this several times. This had been tested before and worked just fine.

Further, all other OpenGL applications that I use have never exhibited any text display issues. Why is it just SFML?

Don't say this please.

What should I say, then, Laurent? It's frustrating to see everything else work but SFML, after I've spent months building major portions of a product I had hoped to release before 2013 around a library that inexplicably refuses to work doing something you seem to think is so mundane. A revamp like switching to SDL means another 3-4 months of development/testing.

Because a driver bug is hard to exhibit, doesn't mean that there's a design flaw in SFML. Driver bugs are usually a combination of several small (and unrelated) things, and all libraries do things differently; unfortunately this time the winner is SFML, but it doesn't mean that my code is wrong (I'm pretty sure it is correct).

Perhaps you should re-read my earlier post. The fact there is a driver bug is irrelevant. SFML isn't working when other OpenGL libraries do the same thing just fine on the same graphics card SFML is broken on.

There is a flaw. I don't know how you can deny it.

What needs to be done to debug and fix this? I can't sit around and wait anymore. I need to know whether or not to ditch SFML.

iirc he has a Nvidia card

Hell, if I lived in France I'd hand-deliver an ATI card to him.

I realize the To-do list is huge and it's not easy to just fix one thing because someone (me) is whining about it. However, I've found similar issues dating back to February of this year (arguably back to December of last year) regarding text.

I don't know what else I can say past this point to persuade you that there is, indeed, something that can be done with SFML to fix text.

You can start by cloning SFML from github, baking it (cmake etc., see tutorial page), installing it to /usr/local/lib/, taking the test source from the pastebin in my OP, compiling it, and running it with LD_LIBRARY_PATH=/usr/local/lib/...

I've done this already. I've gone as far as building all related libraries SFML uses from source. I've tried building dynamically, statically, etc.

21
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 27, 2012, 03:48:59 pm »
...it's not freedraw. If it's not freedraw...
FreeType I assume... ;)

Although I didn't follow the whole other thread and thus don't have as much insight as Qix, but I agree.
Then again we all know that Laurent has little time on his hands and iirc he has a Nvidia card, so maybe we (as a community) can hunt down the problem and try fixing it and I'm sure he'll try to be as much of a help as possible. ;)

Oops, you're right; edited. Was getting confused with "libdrawtext".

I'd be totally up for testing and helping getting this fixed; it's just a matter of Laurent willing to admit there needs to be a fix ;)

I have several systems with ATI cards that I can test on and whatnot, but I honestly don't know where to go as far as testing/debugging from here. I need a little direction.

22
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 27, 2012, 03:24:38 pm »
I still don't understand how other libraries do just fine, Laurent. Other OpenGL libraries draw text just fine. While it's true it seems to be an ATI thing it's obviously not an absolute 100% ATI bug; there is a design flaw in SFML somewhere that is being missed. I've been able to do nothing for more than two weeks now because of this. ATI won't respond to my bug report, you don't seem to want to do anything about it; I am at a total deadlock right now.

It's obvious there are numerous people having issues with text. I hate to be the asshole, but something needs to be done on SFML's part. Ask yourself what you know about your code, Laurent, and why other libraries work just fine and SFML doesn't. Sure, ATI might be to blame, but there has to be something you can do with SFML - even if it's a patch or a hotfix that certain users can download for solving text problems.

As we deduced from the thread I had created, it's not freetype. If it's not freetype, and it's not the code built on top of SFML, and we don't have the ability to magically change the source code of the drivers, the only other component that can be changed in the equation is SFML.

This bug is killing productivity. It needs to be fixed. I really, really don't want to have to switch back to SDL because of this. I'm tired of pushing back release dates because of things that shouldn't be happening. People are asking why and all I can say is "I don't know, it's the graphics library I use. It simply doesn't work".

23
Graphics / Re: Debugging a text problem - 'invisible' text
« on: November 21, 2012, 11:30:50 pm »
Quote
I thought sf::Text implemented sf::Sprite?
Nop, every high-level class directly uses a vertex array internally.

Aha, that makes sense.

24
Graphics / Re: Debugging a text problem - 'invisible' text
« on: November 20, 2012, 11:13:22 pm »
You mean that sf::Text never works on your machine? So it's even simpler, just find what's different between sf::Text and sf::Sprite.

I thought sf::Text implemented sf::Sprite?

25
Graphics / Re: Debugging a text problem - 'invisible' text
« on: November 20, 2012, 11:01:27 pm »
All you can do is to find what makes your code so special compared to the other examples that work. Once you've found that, you'll see if a workaround can be found.

Have you tried older versions of the driver? It may be the easiest solution for you, if you can find a version which works.

None of the examples work. That is the problem.

I'll try older versions of the driver.

26
Graphics / Re: Debugging a text problem - 'invisible' text
« on: November 20, 2012, 10:45:25 pm »
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.

So should I file a bug report with ATI? I need a fix for this :P Is there any way to modify the text class to fix this? I've been sitting here twiddling my thumb for a week and a half and I'm like a crack addict on withdrawals I'm so desperate.

I don't care if I have to modify SFML itself for this project - what can I do to fix this now while waiting for a bugfix that might take months? This makes me upset seeing as how text works in every other OpenGL application I use, so it can't all be a driver bug.

27
Graphics / Re: Debugging a text problem - 'invisible' text
« on: November 20, 2012, 10:33:29 pm »
Driver issue :P

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

28
Graphics / Re: Debugging a text problem - 'invisible' text
« on: November 20, 2012, 10:19:36 pm »
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 >.>

29
Graphics / Re: Debugging a text problem - 'invisible' text
« on: November 20, 2012, 12:26:11 am »
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]

30
Graphics / Re: Debugging a text problem - 'invisible' text
« on: November 19, 2012, 11:59:52 pm »
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]

Pages: 1 [2] 3 4 ... 10
anything