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 - papush!

Pages: [1]
1
That cleared it up, thanks, you guys are doing great work  :)

2
Well attempting to do so either results in a bunch of “Failed to activate the window's context” followed by a “XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server: 0”, or an immediate “XInitThreads has not been called”. Considering that other people were having the same problem (and calling XInitThread isn’t cross-platform), I thought it was just impossible.

Here is a basic example that produces either of those errors (I’m guessing depending on wether draw() or waitEvent() gets called first):
#include <thread>
#include <memory>
#include <SFML/Graphics.hpp>

sf::Sprite sprite;
bool quit = false;

void draw(sf::RenderWindow *window) {
    while (!quit) {
        window->draw(sprite);
        window->display();
    }
}

int main() {
    sf::Texture texture;
    texture.loadFromFile("poivron.png");
    sprite = sf::Sprite(texture);
    sf::RenderWindow window(sf::VideoMode(640, 360), "test");
    window.setFramerateLimit(300);

    std::thread rendering(draw, &window);

    sf::Event event;
    while (true) {
        if (window.waitEvent(event)) {
            if (event.type == sf::Event::Closed)
                break;
        }
        else
            break;
    }
    quit = true;
    rendering.join();
}
 

Am I doing something wrong? I guess I should have made a post in the help forum first, sorry about that.

Edit, to clarify my point:
Synchronising the threads to prevent concurrent access like this:
#include <chrono>
#include <iostream>
#include <mutex>
#include <thread>
#include <memory>
#include <SFML/Graphics.hpp>

std::mutex m;
sf::Sprite sprite;
bool quit = false;

void draw(sf::RenderWindow *window) {
    unsigned i = 0;
    while(!quit) {
        sprite.setPosition((i % 10) * 30, (i / 10) * 30);
        i++;
        if (i > 100) {
            i = 0;
        }
        m.lock();
        std::cout << "Rendering." << std::endl;
        window->clear();
        window->draw(sprite);
        window->display();
        m.unlock();
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }
}

int main() {
    sf::Texture texture;
    texture.loadFromFile("poivron.png");
    sprite = sf::Sprite(texture);
    sf::RenderWindow window(sf::VideoMode(640, 360), "test");
    window.setFramerateLimit(300);

    std::thread rendering(draw, &window);
    window.setActive(false);

    sf::Event event;
    while (true) {
        m.lock();
        std::cout << "Waiting for an event…" << std::endl;
        bool ok = window.waitEvent(event);
        std::cout << "Event received." << std::endl;
        m.unlock();
        if (ok) {
            if (event.type == sf::Event::Closed)
                break;
        }
        else
            break;
    }
    quit = true;
    rendering.join();
}
 
effectively gets rid of the errors and crashes, but then the rendering is halted while waiting for an event (see attachment).

3
General discussions / Window.waitEvent() and multithreaded input handling.
« on: February 03, 2018, 09:53:54 pm »
Hi,
the official documentation for Window.waitEvent() says its main use is when called from a dedicated input handling thread, but after some experimentation and reading around it seems the only way to handle input in a separate thread is to:
  • create the window in the input handling thread (doesn’t seem to be a problem on GNU/Linux, but apparently most systems don’t like handling input on a different thread);
  • make sure not to draw on the window and gather input events at the same time.

So I guess I’m left with three questions:
  • What’s the point of waitEvent(), considering you can’t draw on the window while waiting for an event?
  • Is there a point to a separate rendering thread? Most people seem to agree there isn’t, considering you’d still have to synchronise it to the rendering, but maybe you could poll at a fixed interval in the input handling thread and draw the rest of the time to make sure input is framerate-independent (unless the framerate is lower than the polling rate, a possible solution would be to draw to a backbuffer and only lock the window for the (short) time it takes to copy the backbuffer to it)
  • Is the waitEvent() documentation just plain wrong then?

I’m just making a simple top-down 2D game, so I’m probably overthinking a lot of stuff, but it got me curious and I’d appreciate if someone could shine some light on the matter.

Pages: [1]