Topics

1

Graphics / No stencil buffer support for RenderTextures?

« on: October 10, 2015, 06:09:36 pm »

Hi,

Following the guidelines of the Issues page, I'm creating a quick forum thread for this (and I'll likely be posting a couple others over the next couple of days, hence why this text is quoted).

Alright, so from the looks of things, RenderTextures do not have any internal support for a stencil buffer, although you are certainly free to request a depth buffer. I'm curious: is there a particular reason for not having an optional stencil buffer implemented? And if not, could we discuss a good way to implementing it/what would be needed?

2

Window / Window::getSize() incorrectly returns m_size when using handle-based Window

« on: October 06, 2015, 06:51:03 pm »

Hi,

Following the guidelines of the Issues page, I'm creating a quick forum thread for this (and I'll likely be posting a couple others over the next couple of days, hence why this text is quoted).

It appears that calling Window::getSize() will always return m_size, even when the window is instantiated as a child of another window (by passing a handle in the constructor, for instance). This bug was mentioned once in some buried thread somewhere, but I cannot seem to find it at the moment.

While a minimal code example is hard to produce (since it requires setting up some kind of platform-specific application like a Windows Forms app, or some external libs like wxWidgets), I cannot necessarily provide one, but the fix is really, really simple.

Just change line 230 (the body of Window::getSize()) in Window.cpp from:

return m_size;

to

return m_impl ? m_impl->getSize() : m_size;

I figure this is simple enough of a change that a pull request would be unnecessary, but I could put one together if really needed (and perhaps get around to making an example as well; although it would require dependencies that would potentially be painful to download).

EDIT: Forgot to mention, but I encountered this bug in SFML 2.2, although supposedly it's been around for a little while now, and it is still present in the current git revision, as well as 2.3.2 (obviously enough). Less relevant, but still following the guidelines, I'm on Windows 10 Home using Visual Studio 2013.

3

General / Multithreaded Loader sometimes(?) failing

« on: February 28, 2015, 06:13:17 am »

(Wasn't sure where to put this so I put the topic in General)
Hi,

In the game I am working on, I have a series of gamestates, and when a level is supposed to be loaded, a 'loading' state is set that shows and animates some graphics, while a separate thread loads the level.

More often than not, it works perfectly. However, on some occasions, when the loader finishes, the console output is flooded with GL_INVALID_OPERATION errors (related to SFML's Texture.cpp calls). So my guess is that the contexts are not sharing texture names properly. The strange part is that it isn't entirely reproducible; most of the time it works just fine and the level loads without problems, but on some seemingly random times, it will as mentioned, seemingly fail to share them.

I figure it has to be something in my multithreaded function, so here is the code in particular:

(click to show/hide)

        std::function<void()> f([&] () {
                sf::Context context;
                context.setActive(true);
                if(!FileSystem::OpenDir("./levels/"))
                {
                        glFlush();
                        glFinish();
                        context.setActive(false);
                        app->Error("FileSystem::OpenDir() -- Could not open dir ./levels/");
                        Gamestate::Notify(GAMESTATE_GOTO_MENU);
                        return;
                }
                std::string level = FileSystem::GetFileLocation("testlevel.tmx");
                if(World::LoadWorld(level))
                {
                        glFlush();
                        glFinish();
                        context.setActive(false);
                        Gamestate::Notify(GAMESTATE_GOTO_PLAYING);
                        return;
                }
                else
                {
                        glFlush();
                        glFinish();
                        context.setActive(false);
                        app->Error("World::LoadWorld() -- Could not load level");
                        Gamestate::Notify(GAMESTATE_GOTO_MENU);
                        return;
                }
        });

Obviously it's a lambda function, which then gets placed into a Thread Pool that queues it up on an open thread.

The game uses the TMX Loader library, creating sf::Texture instances for tiles and such. World::LoadWorld() mostly just passes on the level to said TMX loader, and does some parsing. As can be seen from the code, the thread is definitely running because the Gamestate will not be changed until the loader has finished (or returns some error). In short, there shouldn't be anything out of the ordinary...right?

[EDIT] As I've read around a bit and see that it could be relevant, I'm running on Windows 7 Home Premium 64-bit, using SFML 2.2.