Messages

1

Window / Re: Created GL context does not meet requested

« on: October 06, 2018, 10:01:36 pm »

Fixed the issue, created #1495. Even if the logic does not meet what you expect from OpenGL, it should be sound.

2

Window / Re: Created GL context does not meet requested

« on: October 06, 2018, 04:43:44 pm »

I'm afraid this issue still exists in SFML master in a non-determinisic way.

I get different availability of extensions and corresponding outputs of sf::err() for 32-bit and 64-bit Linux builds. This also affects RenderTexture (RenderTextureImplFBO works for me, RenderTextureImplDefault does not - seems to be related to GL contexts).
glxinfo lists all extensions as expected.

Ubuntu 16.04 Linux VM, HW accelerated (NV), hosted in Windows 7.
SFML master as of today.

32-bit build works, output of sf::err():

Setting vertical sync not supported

64-bit does not work, output of sf:err:

Warning: The created OpenGL context does not fully meet the settings that were requested
Requested: version = 1.1 ; depth bits = 0 ; stencil bits = 0 ; AA level = 0 ; core = false ; debug = false ; sRGB = false
Created: version = 0.0 ; depth bits = 24 ; stencil bits = 8 ; AA level = 0 ; core = false ; debug = false ; sRGB = false
Setting vertical sync not supported
sfml-graphics requires support for OpenGL 1.1 or greater
Ensure that hardware acceleration is enabled if available
OpenGL extension SGIS_texture_edge_clamp unavailable
Artifacts may occur along texture edges
Ensure that hardware acceleration is enabled if available

3

Window / Re: Created GL context does not meet requested

« on: February 11, 2017, 04:09:36 pm »

I see, thanks!
Looking at the changes to GlxContext.cpp, it seems that the specific commit patch can be applied verbatim without a full upgrade, still on the version before the contextless branch commit. Will it stand a good chance of working?

4

Window / Re: Created GL context does not meet requested

« on: February 04, 2017, 08:48:40 am »

I'm using SFML version 2.4 with additional commits up to the XCB-->Xlib transition (inclusive), just before the contextless branch commit. Is this issue relevant also to this version?

I'm asking because I use AA but prefer to not upgrade unless necessary.

5

Window / Re: Windowed fullscreen (a.k.a borderless fullscreen window)

« on: December 02, 2016, 01:24:39 pm »

Thanks, you were both right, issue (3) is indeed in Ubuntu Unity, unrelated to SFML.
As for issue (2), it seems to be specific to VirtualBox HW acceleration, probably re-creating the window invalidates all the textures created by the previous window. So this is not connected with neither SFML nor my code.
What remains is issue (4), which looks real but I already have a workaround for.

6

Window / Re: Windowed fullscreen

« on: November 12, 2016, 01:22:14 pm »

By 'windowed fullscreen' I was referring to borderless fullscreen window. I'll edit the post to make it clearer.
Adding window.setPosition(sf::Vector2i(0, 0)) did not seem to solve problem (3) above.

Here's the code:

m_isWindowedFullscreen = !m_isWindowedFullscreen;
if (m_isWindowedFullscreen) {
        m_prevWindowWidth = window.getSize().x;
        m_prevWindowHeight = window.getSize().y;
        m_prevWindowPosX = window.getPosition().x;
        m_prevWindowPosY = window.getPosition().y;
        window.create(sf::VideoMode::getDesktopMode(), getWindowTitle(),
                sf::Style::None, getIdealContextSettings());
        window.setPosition(sf::Vector2i(0, 0));
} else {
        assert(m_prevWindowWidth != -1);
        window.create(sf::VideoMode(m_prevWindowWidth, m_prevWindowHeight), getWindowTitle(),
                sf::Style::Default, getIdealContextSettings());
        window.setPosition(sf::Vector2i(m_prevWindowPosX, m_prevWindowPosY));
}

7

Window / Windowed fullscreen (a.k.a borderless fullscreen window)

« on: November 12, 2016, 08:10:34 am »

In order to switch between windowed and 'windowed fullscreen' (EDIT: also known as 'borderless fullscreen window') modes, I tried to re-call Window::create(), toggling between passing sf::Style::None + sf::VideoMode::getDesktopMode() and passing sf::Style::Default with the previously-saved window size.

• Is it the recommended practice?
• In Linux, the switch caused all letters to become white rectangles-of-some-sort, I had to reload all fonts to fix that. Windows did not seem to have this problem.
  Is it normal or something wrong on my side?
  Update: this seems to be specific to VirtualBox HW acceleration, unrelated to SFML.
  
• In Ubuntu Linux, there's that launcher at the left side of the screen, and the windowed-fullscreen window appeared next to it so the right side of the window went out of the screen.
  How do I make the window cover that launcher, or alternatively, is there any way to return the working area (in contrast to getDesktopMode() that returns the full resolution)?
  Update: this is an issue in Ubuntu Unity, unrelated to SFML (see below).
  
• In Windows, Alt-tabbing in windowed fullscreen mode out of the SFML window sometimes resulted in the screen becoming black, with its content gradually appearing following the mouse cursor.
  When I tried this code + calls to sf::Window::setSize() so that SFML was aware of the new size, this problem disappeared.
  Is it a known problem?

My configuration: desktop with one monitor, Win 7-64 & NV GPU (Aero disabled), Ubuntu 16.04 in a VM (HW accelerated).
SFML version: 2.4 with XCB removal commit.

8

General / Re: Memory leak in SFML master (not occuring in 2.3.2)

« on: September 10, 2016, 11:52:26 am »

Well, I've looked into it further. Fixed everything by adding the following at the end of main():

#ifdef _DEBUG
        // fix the following SFML memory leaks:
        // - new ContextType(NULL) in GlContext::globalInit()
        // - new sf::Context in getInternalContext()
        // - new ContextType(sharedContext) in GlContext::create()
        sf::priv::GlContext::globalCleanup();
#endif

As I link statically, no change to SFML was needed, only the following declaration before main():

namespace sf { namespace priv { class GlContext { public: static void globalCleanup(); }; } }

I could've done it earlier if I hadn't relied on the following SFML version for a fix. Will learn next time.

9

General / Re: Memory leak in SFML master (not occuring in 2.3.2)

« on: September 10, 2016, 07:06:33 am »

@DarkRoku, this is not a semantic discussion regarding memory leaks, but a highly practical one.

Let me tell you straight - I almost never test for memory leaks, even not for recurring ones. That's because I don't need to:

• I use Visual Studio's CRT debug facilities, which have the option of automatically creating a memory leaks report file when leaks are present on program exit.
• The mere presence of that file on my HDD tells me that since I last checked, there have been memory leaks in at least one of my runs, and where.

So the practical issue is that SFML's memory leaks create noise that masks other leaks. As I'd been using SFML 2.3.2 for some time, I actually forgot about the file. But now it keeps being created on every run, no matter if there are other leaks or not.

Beyond that, as library developers you may want to consider the following:

• Those memory leaks are not only memory, but also your destructors are not called. They may have important logic in the future.
• "One-time" leaks tend to become recurring leaks once the library is used in a different way than the original developer was thinking about.
• How can a library user know that these leaks are indeed one-time and do not accumulate, when the SFML team does not even acknowledge their existence? It seems to be a necessary step towards more meaningful discussions.
• The impact of memory leaks on the confidence of users in the reliability of the library.
• Probably more to say, but that should be enough for now.

10

General / Re: Memory leak in SFML master (not occuring in 2.3.2)

« on: September 09, 2016, 02:45:08 pm »

I see that other people keep encountering the same leaks now that 2.4 is released, and that the SFML team is quick to dismiss their reports and mark their issues as closed (see #1143).

For your convenience, I've described in #1143 a simple test that demonstrates that these leaks are real in a manner that does not depend on leak detection tools nor debuggers. I really hope you'll take the time to fix this issue at last.

11

Feature requests / Re: Extending Font & Text to support multiple textures (bug fix)

« on: March 18, 2016, 10:07:44 am »

More specifically, I need to know whether the bug fix (#1034) is going to be merged. I can update it to support outlined text but I will not bother to do so just for my project.
As I target PCs not mobiles, I may as well just join the club of those having their own version of SFML, where I can freely implement additional fixes/optimizations (#1015 and this one) without regard for new SFML functionality.

12

Graphics / Re: [Solved] Need help with drawing Text using VertexArray

« on: February 13, 2016, 09:54:21 am »

I have simply taken the origin sf::Text source code and modified it to fit my needs

If all you need is access to the vertices of sf::Text, you can manage without duplicating its code by doing something along the lines of:

#define getString getString() const; \
    friend class YourClass; \
    void doNothingJustAHack
#include <SFML/Graphics/Text.hpp>
#undef getString
 

Then YourClass will have access to the private members of sf::Text. It's really fun, and you may be nominated to the Nobel prize in software engineering

13

General / Re: Memory leak in SFML master (not occuring in 2.3.2)

« on: February 12, 2016, 05:09:22 am »

Well, returning back to the original technical issue discussed...

These resources seem to be deallocated correctly, have you made sure that the corresponding code is not reached (by debug output or breakpoints)?

Now I have, for the two 48-byte leaks. Placing breakpoints in WglContext c'tors and d'tor, it seems that 3 instances are created but only 1 is deleted.

Visual Studio's leak detector stopping too early is as well an issue as starting too late. It cannot see the deallocation after its lifetime, and so it regards such resources as leaked.

Why are you saying that? You don't use #pragma init_seg in SFML, why shouldn't this facility be reliable?

No, it only means that the VS detector didn't see any leaks for 2.3.2. And this does not imply that master is leaking...

Actually I use master of 2.5 months ago, but I believe that nothing has changed in this regard.

14

Feature requests / Re: Determining if glyphs for a given character size have been discarded

« on: February 09, 2016, 09:42:10 pm »

Then again the PR itself could probably go either way. In the end it's not really that important.

Sure. The important thing to ask is, what process do you use to decide regarding undecided PRs?

15

General / Re: Memory leak in SFML master (not occuring in 2.3.2)

« on: February 09, 2016, 09:33:06 pm »

::_CrtSetDbgFlag(::_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);

as the first line of main().

SFML has certain global states, so if you start tracking memory allocations only after main() is called, you're already missing things.

VS debug runtime tracks all memory allocations from the start, including non-local static objects. This line only triggers reporting, so if you moved it to the end of main() you would get exactly the same 3 leaks.
This means that 2.3.2 was not leaking (at least not system/window/graphics).