[SOLVED] Text blurred on some positions

[Anrock]

Please see attached image, it is self-descriptive. Why text in middle of screen is blurred while text on the edges is ok? Is it #228 issue? I still got sfml2.1

[Nexus]

Do you align both text and view to integral coordinates? Check the latest sf::Drawable and sf::View documentation (master branch, not website) for detailed description of the issue.

[Laurent]

Try a minimal example: use no view, don't resize the window, don't scale anything. Just output one multi-line text at position (0, 0), and see if it still happens.

You can also try the current git version, to see if the font improvements help in your case.

[Anrock]

@Nexus text is aligned to integral coordinates, yes. How do i get coordinates of view? I didn't see anything related to my issue in docs from git master, would you tell what exactly i should look for?

@Laurent minimal example is fine, even on my 2.1. So it's a view problem, i guess.

[Nexus]

I meant the notes added in this commit. Make sure those conditions are fulfilled. If necessary, reduce your application until it's obvious what causes the blur.

[Anrock]

Checked attributes of sf::Text objects - everything is integral.
Center of view and it's size was fractional. I std::rounded them and got opposite result: now text on edges is blurred and in central part is ok. Isn't that because rounded size of view is smaller/bigger, than size of viewport rect? Maybe i should stop  using viewport with 0.975x0.025 size and 0:0.025 coords and specify viewport in absolute pixels somehow?

[Ixrec]

Specifying viewport size with fractions is better because those fractions are independent of window size.   I believe this is only a problem in your case because you have a very short viewport (why exactly do you need 0.975x0.025?) AND you're drawing text inside of it (text is far more sensitive to individual pixels than most graphical entities).

If you really need to draw text through such an oddly-shaped viewport, try to find a fraction that divides nicely into the window sizes you plan on supporting.  After fiddling with my calculator for a minute, it seems like many common window sizes these days can be divided by 16, and some can be divided by 32.  Would 1/16 (0.0625) or 1/32 (0.03125) be close enough for your purposes?

P.S. I think setting a viewport in absolute pixels might be unfeasible (even if Laurent thought it was a good idea), because OpenGL itself appears to take floats, not pixels (see the source for RenderTarget::applyCurrentView()).

[Anrock]

Oh shi~, view i'm having problems with is the big central one with 0.75x0.975 size, so it's not because view is odd or small for sure. Narrow upper one is indeed 0.75x0.025.

[Ixrec]

The point still applies, since that very odd scaling fraction will still cause the off-by-one-pixel blurriness you're having trouble with (as you saw when you moved everything half a pixel and the other text became blurry).  Put another way: using 39/40ths in a viewport is just as strange as using 1/40th.

It almost sounds like you're using views to split the screen up into logically distinct UI regions.  If so, this is absolutely not what you should be using them for.  If not, please explain why you want 40ths in the first place.

[Anrock]

Well, yes, i am trying to do pretty much what you said. For explanations why, please this topic:
http://en.sfml-dev.org/forums/index.php?topic=14759.0
Views worked out well, except this text issues.

[Ixrec]

That does explain a lot.

Unfortunately, the conflict between text and viewports is probably unavoidable.  Text that gets upscaled or downscaled *after* being rendered is going to look strange unless it happens to get scaled by just the right factor.  SFML can't do anything about that.

I have no idea what your scaling needs are (can the user resize each GUI region? or do they all have fixed sizes? a finite selection of sizes?) so I can't guess at a good solution for this.  You might have to do a bunch of experiments with font sizes and scaling factors to see if there's a set of decent-looking combinations you can actually use.

Edit: After mulling this over and rereading your previous thread, my gut feeling is that your subprocesses should only get the data to display in each window, and there should be a separate process for rendering everything (ie, separate graphics from game logic), which would use the default view for drawing the terminals/windows.

It might also be a good idea to research how real OSs handle this problem.

[Anrock]

>Unfortunately, the conflict between text and viewports is probably unavoidable.  Text that gets upscaled or downscaled *after* being rendered is going to look strange unless it happens to get scaled by just the right factor.  SFML can't do anything about that.
And no way to make view not-scaled? Geez, i couldn't ever imagine taking rect area of window would be so hard.

>I have no idea what your scaling needs are (can the user resize each GUI region? or do they all have fixed sizes? a finite selection of sizes?)
User can't resize any window. Views have fixed ratios and sizes are changed depending on window size to keep this ratios.

> my gut feeling is that your subprocesses should only get the data to display in each window, and there should be a separate process for rendering everything (ie, separate graphics from game logic), which would use the default view for drawing the terminals/windows.
I don't think this would be nice solution. You see, this big main panel is where interactive proccesses are run. And they could be just anything - from simple text terminal to gui email client or tetris or whatever. Right now i can inherit class from ProgramBase (with update, draw, input and reference to host-OS) and do whatever i want inside this process and then just render to passed view. If i put all rendering to OS class - it's going to become hardly maintanable god object also making writing new process very-very hard. 

[Ixrec]

If the sizes are fixed, then you may be able to get away with rendering each window to a fixed-size (but smaller than the window) rendertexture and then drawing its texture to the window with the default view.  You'll have to tell each process the size of its assigned rendertexture so it can pick appropriate font sizes for the text, but the rendertexture will neatly enforce the size constraint, and then all the main process has to do is transfer that texture to the right part of the window.

>And no way to make view not-scaled?
Views scale part of the game world to fit in a particular region of the window.   Only the default view (and some other trivial/useless views) do no scaling.  It's kind of an inherent part of the functionality.

>Geez, i couldn't ever imagine taking rect area of window would be so hard.
I believe your original goal was to restrict a process to drawing in a rectangular area of the window, without letting it know what the real window size was.  That's probably never going to happen without some kind of limitation (like this scaling problem).

[Anrock]

Okay, i'll fiddle some more with views and resort to rendering textures if fail.

[Laurent]

Sorry if I'm out of topic, I've read this discussion very quickly, but if it's just a problem with the viewport's scale factors, then all you have to do is to compute them from integer pixel values instead of using arbitrary decimal numbers.

float viewportWidth = some_integer_value / window.getSize().x;
// same for left, top and height...

And if you really need to define them with scale factors instead of pixel sizes, then adjust them so that multiplied by the window size it makes an integer.

float viewportWidth = static_cast<unsigned int>(some_scale_factor * window.getSize().x) / window.getSize().x;

(you may have to adjust the rounding method when converting from float to integer to get correct results)