Messages

1

Graphics / Re: No stencil buffer support for RenderTextures?

« on: October 10, 2015, 09:49:10 pm »

It is implemented with #846.

I see it's currently not merged, but I do like the interface. Great job! And that answers this question well enough haha.

2

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?

3

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

« on: October 10, 2015, 06:00:59 pm »

You see now why I asked this: I know how sf::Window works internally, and I knew it was supposed to report the correct size if you had an event loop ; and I would probably have directed you to the solution if you had described your problem in the first post, instead of focusing on what you thought had to be fixed.

You're right and I probably should have made it a bit more clear from the start. Sorry about that. :/

4

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

« on: October 07, 2015, 12:52:48 am »

It's an internal detail and nothing that should be documented. Maybe the tutorial could point out even more that processing events is a must. Even though we already have this red box in the tutorials:

A mistake that people often make is to forget the event loop, simply because they don't yet care about handling events (they use real-time inputs instead). Without an event loop, the window will become unresponsive. It is important to note that the event loop has two roles: in addition to providing events to the user, it gives the window a chance to process its internal events too, which is required so that it can react to move or resize user actions.

Fair enough. I looked through the Events Explained tutorial and didn't see it; did not realize it was in Opening and Managing a Window.

5

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

« on: October 07, 2015, 12:36:02 am »

@Theshooter7 while I am thinking about it, are you sure you are still polling the SFML window events when embedded in another window? I remember there being a few issues that would happen if SFML's events were not polled.

Indeed I do not, as I delegated all events to wxWidgets. Turns out you're actually right! At least, glancing over the SFML source, it looks like m_size gets cached when filterEvent() is called from within pollEvent()/waitEvent().

Thank you for pointing this out. Perhaps a small change to the Documentation could be made to mention this for anyone in the future? Since no tutorial or otherwise mentions at this point that the event queue of a window must be processed in order for m_size to stay correct (and m_size is the only value that seems to be subject to this as well)

6

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

« on: October 06, 2015, 11:52:25 pm »

Do we even need the Window::m_size member variable? It's currently only an optimization. And if we can't rely on it being up-to-date and have to query the PImpl anyway, then it's useless.

The size not being up-to-date could be part of the issue at hand here, hence why requesting the size from m_impl seems to be fixing the problem.

I'm sorry if I missed something, but... I can't find any description of a bug in this discussion. What's wrong? Why is it a "bug" that Window::getSize() returns m_size? The implementation is supposed to make this work correctly, even when sf::Window wraps a native window.

I suppose it wouldn't be considered a "bug" per-say, but what exactly would you call it otherwise? An oversight? An error?
In any case, I primarily found this "issue" when adding a RenderWindow to a wxWidgets application. When I obtained the RenderWindow's size to use in an sf::View, it would return incorrect results causing things that I drew to it to be placed incorrectly and/or scaled improperly. I initially found the fix through searching in this thread (although the author mentions SFML 1.6, he was working with 2.0. His intent might be lost as the post isn't the clearest). Once I added this in to my own copy of SFML, everything worked just fine.

I admit that a potential work around might have been to use a RenderTexture, but even then, I would say reporting the wrong size is a problem. :x

7

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.

8

General / Re: Multithreaded Loader sometimes(?) failing

« on: March 01, 2015, 09:12:02 am »

I think I figured out the problem, as dumb as the solution may have been. It didn't occur to me that, in my World::LoadWorld() function, the LightSystem is being instantiated. After crawling through the LTBL source, and finally realizing that at that point is where the RenderTextures used for lighting are created, that this is probably indeed causing a context race between the threads.

My solution was to move the creation of the light system and data-parsing stuff out of the loader thread into a separate function so that it can run on the main thread. The post-load parsing takes very little time (if anything noticeable at all) so this is more than acceptable for fixing this problem.

Thank you so much anyway; the things you mentioned did help me figure out the issue eventually. I'm just disappointed that I didn't actually catch this sooner.

9

General / Re: Multithreaded Loader sometimes(?) failing

« on: February 28, 2015, 06:28:15 pm »

Yes, sorry about that, my post was heavily rushed as it was getting really late for me. At least I know someone is reading. :p

1. It would be nice to know exactly where the GL_INVALID_OPERATION comes from. SFML tells you the exact line number when building in debug.

Texture.cpp, lines 490, 516, 517, and 520. Looking at the source, these are when calls to glBindTexture, glMatrixMode, and glLoadMatrixf are made.

2. Threads + (it works sometimes and sometimes not) sounds like your typical race condition to me. SFML wasn't designed to be thread safe, and although OpenGL contexts are supposed to enable multi-threading without explicit synchronization, I really wouldn't rely on it. Where do you synchronize? I don't see it in the code you provided.

Yeah, definitely a typical data race. The thing that confuses me the most however is that (as I tried to explain in my initial post, but failed horribly), the thread has practically exclusive access to the data; other than the use of the sf::RenderTexture to draw the animated loading screen stuff (which was already loaded before the thread is even launched), the main thread and the loader thread do not interact with the same data, because the main thread is more-or-less doing nothing until the loader thread signals it is done (by calling Gamestate::Notify()).

As for synchronization, the threads are never synchronized (i.e. calling join()); after completing their task they are put to sleep until notified to run another task. This is, at its core, how a thread pool works. Do you think adding synchronization could have an effect, seeing as how SFML is not particularly thread-safe as you mentioned?

3. Why are you using glFlush() and glFinish() everywhere? glFlush() makes sense, but only when you tell OpenGL to actually do something prior, which you do in 2 of 3 blocks. glFlush() followed directly by glFinish() makes no sense at all. glFinish() implies glFlush(). glFinish() is evil, try to never have to use it, it will kill any advantage the asynchronous nature of OpenGL provides you. In your application, it will even synchronize with all other contexts (and threads) since it is a GPU synchronization command. If they are there just for debugging then you could have mentioned it too.

Yeah it was just an attempt at debugging the situation. I had read that glFinish() and/or glFlush() would solve potential issues where a texture wasn't fully uploaded but something tried to access it, causing the data to corrupt and potentially causing these problems. Although I appreciate that insight into the difference of the two.

I assume that the loader takes a bit to load and parse the files, which is the reason why you threw that part into a thread. It sure won't help with the time it takes OpenGL to do stuff (which happens immediately from our perspective). Did you measure where most of the time is spent? Because if the file loading and parsing doesn't take any time at all, I don't see how throwing all that stuff into a separate thread can help.

Relatively speaking, the loader does take some time to complete (relatively being about 3-5 seconds on my machine), on a level that isn't fairly large (84x32 tiles of size 32x32), using a tileset of only 25 different tiles. Because of the time it takes (which will likely scale up with the size and complexity of levels), I placed it in another thread so that a loading screen could be done and animated without being blocked (since the loader will not return until it has finished or failed at some point).

On the other hand, I have not taken exact measurements of where the majority of time is spent, and I could do that. Although my best guess would be in loading the textures in the TMX loader. It seems that the TMX loader actually loads the files into sf::Image before uploading them to an sf::Texture, which is probably helpful in regards to OpenGL, but I doubt that one way or the other it should have an impact here.

My initial guess is that your code relies on "unreliable" cross-context behaviour that even the specification doesn't guarantee. In order to tell what is really going on, we will need much more information than you have provided us. We need to know what contexts elsewhere are doing as well.

If you can't provide more code for certain reasons, try to construct a minimal example that mimics the way your application uses contexts in a multi-threaded way. Run it multiple times, and if the same error occurs you can post that here instead.

It certainly seems to be a context problem. I'll try to come up with some sort of example, although I may have narrowed the problem down slightly. It's a problem with LTBL (and I probably should have mentioned the use of that library in my hastily-written first post ). To try to sum things up, this error started happening when I switched over to the use of RenderTextures instead of drawing to the RenderWindow directly (because I wanted to remove the visual distortion I was getting, and found that drawing to a RenderTexture, then applying the texture to a sprite and scaling it up to the size of the window gave pixel-perfect results).

However, LTBL only accepted a RenderWindow as one of its parameters for the LightSystem class. See here:

(click to show/hide)

LightSystem::Create(const AABB &region, sf::RenderWindow* pRenderWindow, const std::string &finImagePath, const std::string &lightAttenuationShaderPath)

I figured they both utilized sf::RenderTarget, so changing the parameter to a RenderTexture (and any other references needed) should do the trick.

(click to show/hide)

LightSystem::Create(const AABB &region, sf::RenderTexture* pRenderWindow, const std::string &finImagePath, const std::string &lightAttenuationShaderPath)

Then for the parameter, I just pass in the RenderTexture I use that is defined in my App class, using GetRenderTexture(). The class looks like this:

(click to show/hide)

class App
{
public:
        App(std::string app_name);
        void Init();
        bool IsRunning() const;
        void StopRunning();
        void ShutDown();
        void ShutDownRenderer();
        void RestartRenderer();
        sf::RenderWindow *GetWindow();
        sf::RenderTexture *GetRenderTexture();

        float GetDeltaTime();
        void SetDeltaTime(float dt);

        ConfigFile *GetConfig();

        void SetFramerateLimit(int fps);

        void Error_Fatal(std::string errmsg, ...);
        void Error(std::string errmsg, ...);

        double frameTime;

private:
        void InitRenderer();

        int fpslimit;
        float deltaTime;

        sf::RenderWindow *m_window;
        sf::RenderTexture *m_renderTexture;
        sf::ContextSettings m_settings;
        sf::VideoMode m_vidmode;

        sf::Context context;

        ConfigFile *cfg;
        std::string m_name;
        bool m_running;
};

(the extra sf::Context is from some debugging, although I have yet to test removing it actually. I'll give that a shot right now; it is instantiated before the RenderWindow and RenderTexture are, after all. But since Contexts are supposed to be shared by default, this shouldn't affect anything should it?)
I'm unsure if you're familiar with the LTBL source--it uses a lot of raw OpenGL. When stepping through the debugger, this function in particular is where the glErrors are thrown:

(click to show/hide)

        void LightSystem::RenderLightTexture()
        {
                Vec2f viewSize(m_viewAABB.GetDims());

                m_pWin->setActive();

                // Translate by negative camera coordinates. glLoadIdentity will not work, probably
                // because SFML stores view transformations in the projection matrix
                glTranslatef(m_viewAABB.GetLowerBound().x, -m_viewAABB.GetLowerBound().y, 0.0f);

                //m_compositionTexture.getTexture().bind();
                sf::Texture::bind(&m_compositionTexture.getTexture());

                // Set up color function to multiply the existing color with the render texture color
                glBlendFunc(GL_DST_COLOR, GL_ZERO); // Seperate allows you to set color and alpha functions seperately

                glBegin(GL_QUADS);
                        glTexCoord2i(0, 0); glVertex2f(0.0f, 0.0f);
                        glTexCoord2i(1, 0); glVertex2f(viewSize.x, 0.0f);
                        glTexCoord2i(1, 1); glVertex2f(viewSize.x, viewSize.y);
                        glTexCoord2i(0, 1); glVertex2f(0.0f, viewSize.y);
                glEnd();

                if(m_useBloom)
                {
                        //m_bloomTexture.getTexture().bind();
                        sf::Texture::bind(&m_bloomTexture.getTexture());

                        glBlendFunc(GL_ONE, GL_ONE);

                        glBegin(GL_QUADS);
                                glTexCoord2i(0, 0); glVertex2f(0.0f, 0.0f);
                                glTexCoord2i(1, 0); glVertex2f(viewSize.x, 0.0f);
                                glTexCoord2i(1, 1); glVertex2f(viewSize.x, viewSize.y);
                                glTexCoord2i(0, 1); glVertex2f(0.0f, viewSize.y);
                        glEnd();
                }

                // Reset blend function
                glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

                m_pWin->resetGLStates();
        }

The line for m_pWin->setActive(); is something I added for debugging an earlier problem where the LightSystem would only draw a full-white quad across the screen (i.e. nothing was being drawn, or Texturing was disabled or something). I mention this because this is clearly where a context switch happens. Note however that nothing related to the LightSystem is called before the loader finishes.

10

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.

11

SFML projects / Re: 'Tiled' Tile-map Loader

« on: February 27, 2015, 03:51:21 am »

I've implemented the Tiled loader into my game successfully and all, and have been using it quite heavily. One problem I continue to have, however, is a strange visual artifact:

(click to show/hide)

If you can't quite spot it, here is an image cropped out to highlight the problem (notice the internal edges of the tiles looking really strange?)

(click to show/hide)

The kind of placeholders I am using aside, for some reason the tiles become quite distorted. Characters and such do not face this problem as I use sf::Texture::setSmooth() on them, but even adding that into the tiled loader source does not produce acceptable results (and messes with the use of LTBL's light texture).

Now I don't believe it is specifically a fault of the tiled loader, but I'm wondering if something can be done. And yes, my sf::View's are clamped to whole integers. My tiles are 32x32, and my sf::View defaults to 800x600 at a 4:3 resolution (though it adjusts for widescreen resolutions as well), if that helps.

[EDIT] Also, sorry for bumping this from page 4, if that's a concern.

12

SFML projects / Re: SFML Light System - Let There Be Light

« on: May 06, 2014, 06:57:23 am »

Well i fixed it .
In the parts where it says:

glBegin(GL_QUADS);
                        glVertex2f(0.0f, 0.0f);
                        glVertex2f(width, 0.0f);
                        glVertex2f(width, height);
                        glVertex2f(0.0f, height);
                glEnd();

in the lightsystem.cpp file, comment all that out. Then it works fine. He is clearing 2 times. First normally and then with the clearing shown above.

Exact lines? There are several instances where this shows up. But good job!

[EDIT] Ok took another swing at the problem I'm having (didn't realize you could setActive() a render texture so that's a step forward), but I get odd results; the play area comes up pure white and the sky comes out gray. This is the code I've got:

Code: [Select]

sf::RenderTexture rt1, rt2;
        rt1.create(app->GetWindow()->getSize().x, app->GetWindow()->getSize().y);
        rt2.create(app->GetWindow()->getSize().x, app->GetWindow()->getSize().y);

                        /* ... */

                //app->GetWindow()->draw(app->GetBackdrop());
rt1.setActive();
rt1.clear();
rt1.draw(app->GetBackdrop());
world->GetBackgroundLightSystem()->RenderLights();
world->GetBackgroundLightSystem()->RenderLightTexture();
rt1.display();
sf::Sprite tempsprite1(rt1.getTexture());

//app->GetWindow()->draw(*world->GetLevel());
rt2.setActive();
rt2.clear();
rt2.draw(*world->GetLevel());
world->GetLightSystem()->RenderLights();
world->GetLightSystem()->RenderLightTexture();
rt2.display();
sf::Sprite tempsprite2(rt2.getTexture());

app->GetWindow()->setActive();

app->GetWindow()->draw(tempsprite1);
app->GetWindow()->draw(tempsprite2);

app->GetWindow()->display();
[EDIT 2] this code just gets me black render textures, as if nothing is being drawn to them for some reason.

Code: [Select]

//app->GetWindow()->draw(app->GetBackdrop());
rt1.setActive();
rt1.clear();
//rt1.draw(app->GetBackdrop());
world->GetBackgroundLightSystem()->RenderLights();
rt1.setActive();
world->GetBackgroundLightSystem()->RenderLightTexture();
rt1.resetGLStates();
rt1.display();
sf::Sprite tempsprite1(rt1.getTexture());

//app->GetWindow()->draw(*world->GetLevel());
rt2.setActive();
rt2.clear();
//rt2.draw(*world->GetLevel());
world->GetLightSystem()->RenderLights();
rt2.setActive();
world->GetLightSystem()->RenderLightTexture();
rt2.resetGLStates();
rt2.display();
sf::Sprite tempsprite2(rt2.getTexture());

app->GetWindow()->setActive();

app->GetWindow()->draw(app->GetBackdrop());
app->GetWindow()->draw(tempsprite1);
app->GetWindow()->draw(*world->GetLevel());
app->GetWindow()->draw(tempsprite2);

app->GetWindow()->display();
}

13

SFML projects / Re: SFML Light System - Let There Be Light

« on: May 06, 2014, 04:27:28 am »

I guess the shadow fin is for the shadow part only, i was unsure what to call the dark area, but basically i want everything brighter, not just the shadow. I see in your screenshots it's not entirely black.

Basically m_ambientColor doesn't work at all with bloom turned off for me.

Oh. Yeah I have bloom enabled and m_ambientColor doesn't work for me with it off either. :/

14

SFML projects / Re: SFML Light System - Let There Be Light

« on: May 06, 2014, 01:05:23 am »

Not having used LTBL myself, but you could probably draw all your tiles [including the lighting] onto a render texture. Then draw that render texture on top of your sky background in the window.

I was going to do this but the problem is LTBL uses raw OpenGL, and thus bypasses any way to use the Render Textures with it.

If i understand correctly i think i would draw the background stuff first, then the background lightsystem and then foreground boxes etc and the lightsystem and set

m_renderLightOverHull = false;

if you want it like the image.

I've tried this, and the result is the same unfortunately. Although I have not provided a hull for the backdrop, so I'm not sure if I should experiment with that, and if so, where to start? Make the hull as big as the window? That doesn't seem right.

I have a problem myself btw. I'm trying to change the brightness of the shadows.

This does nothing to the black color which i have for shadows, but the lights works:

ls.m_ambientColor = sf::Color(50,50,50);
ls.m_useBloom = false;

If i change bloom to true then i can change the shadows color but then the lights wont work anymore.

edit: To be clear my game is completely black, i want to be able to make it less dark .

edit2: Managed to make it work with bloom on now by setting intensity to over 1, but bloom doesn't work well at all so i need it off.

What if you used a different shadow fin image? Like, you take the existing one, modify it so the dark portion is lighter, and use that with your/a light system? I think that would in turn make the shadows themselves brighter and combined with ambient lighting will brighten things up overall.

15

SFML projects / Re: SFML Light System - Let There Be Light

« on: May 05, 2014, 08:56:33 pm »

So you want two equally big lightsystems stacked on eachother? Well i'm no expert but it's very hard to get any help about this light system since the developer seems to have abandoned this project.

I have never tried this and don't know of the issues with it but ofourse the front layer can't become brighter than the back one if that's your issue. Maybe post some screenshots again of your new issue so i understand better, but i don't think i will be able to help you, especially if it requires changes of the lightsystem itself, since i don't have a big understanding of how this lightsystem works.

This is what I was aiming for (using photoshop since I can't get it to work for real)
http://i.imgur.com/1uFZAMf.png
(Note the contrast of the sky texture against how dark the tiles are)

I understand if this is outside of the scope of just a simple implementation detail. I do appreciate all your help so far and I can see that this is basically abandoned.