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 - dulsi

Pages: [1]
Window / Re: Window not responding you may choose to wait
« on: February 09, 2016, 03:59:31 pm »
How much image data are you loading then?

Windows will only start complaining that the window is not responding after a few seconds of no event processing, but if a game is getting stuck for a few seconds, then it's usability wise anyways recommended to do the image loading asynchronously and render some progress bar. Keep in mind that if you do load things asynchronously, you should really only load data from disk to memory and not do anything with OpenGL.
It's not loading a lot of data. Fedora must be configured to popup the message much earlier than windows. It's take a second or less to display the starting screen at which point it is calling pollEvent. Interestingly the popup takes a while before it loads. That combined with the fast startup caused me to not consider the image/sound files loading to be a problem. When I commented out all the processing and still received the error I looked at the loading code. Loading asynchronously is not worth the complexity at the moment. I modified it to simply load everything before creating the render window.

Window / Re: Window not responding you may choose to wait
« on: February 08, 2016, 09:36:27 pm »
I think I figured out the problem. The game created the window then loaded a bunch of images and sounds. Finally it started the game loop with pollEvent. If I add a pollEvent before the loading the images and before loading the sounds, the popup doesn't occur. (At least most of the time. There was a another screen switch where I saw it once so that might need some modification.)

Window / Re: Window not responding you may choose to wait
« on: February 08, 2016, 02:26:40 pm »
Do you mean that the application is never responding, or only in specific circumstances (like when you move or resize it)?
The application is responding. It is running just fine. Fedora just doesn't believe it is for some reason. So to run Ostrich Riders, I start the program, let the window saying it isn't responding popup, click on wait, and then play the game. I took this simple example, fixed the location for the font, and ran it. It too popped up the window saying it isn't responding. I don't try moving or resizing the window. It's just a simple pollEvent loop that causes the warning.

Edit: Now I can't recreate the problem with the example program I mentioned. M.A.R.S. is in Fedora, uses SFML and doesn't have the problem. I don't know why Ostrich Riders isn't working.

Window / Re: Window not responding you may choose to wait
« on: February 08, 2016, 12:52:09 pm »
Why use multithreading? On event handling/drawing you lose performance instead of gain it.
I don't want to use multithreading. I want to stop the window saying the application isn't responding and having to click wait. I have not found a way of doing that using pollEvent in a single thread. If you know how to fix that I'd gladly use that instead of multi threads.

Window / Window not responding you may choose to wait
« on: February 08, 2016, 05:16:28 am »
I've been porting Ostrich Riders to the SFML 2.3.2. I've got it working but soon after starting it complains a with:

“Ostrich Riders 0.6.1” is not responding.

You may choose to wait a short while for it to continue or force the application to quit entirely.

If you wait everything works fine. I'd like to stop the message from appearing. I played around with the sample from here. Just had to fix the path to the font. That still gets the message. Suspecting that anything using pollEvent gets the error, I switched to waitEvent. No error but obviously doesn't display properly. I moved the waiting for events in a separate thread. That works for a while. Eventually you get:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.

Using Fedora 23, is it possible to avoid the "not responding" message window? Do any examples using pollEvent avoid this message? If you must use waitEvent is it possible to use it in a separate thread from the window drawing without causing it to crash?

Here is a simple example I tried with a thread. I've tried both drawing in the main thread and waiting for events in the main thread. Neither made a difference. (Don't worry about the use of globals or anything. I'm just doing a proof of concept which oviously hasn't worked.)

#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>
#include <cstdlib>
#include <ctime>

enum State { Closed, Normal } ;

void update_normal(sf::RenderWindow & w ) ;

const std::string fontLocation = "/usr/share/fonts/liberation/LiberationSans-Regular.ttf" ;
sf::Font font ;

State state;
sf::RenderWindow *win;

struct ConsumeEvent
 void operator()();

void ConsumeEvent::operator()()
    while ( win->isOpen() )
        if ( state == Closed )
            win->close() ;
            continue ;

        win->clear() ;
        update_normal(*win) ;

        win->display() ;

int main()
    std::srand(std::time(0)) ;
    sf::RenderWindow window( sf::VideoMode(800,600), "Pause me!") ;
    win = &window;
    state = Normal;

    if (!font.loadFromFile(fontLocation))
        return 0 ;

    ConsumeEvent c;
    sf::Thread t(c);
    sf::Event event ;
    while ( win->waitEvent(event) )
        case sf::Event::Closed:
            state = Closed ;
            break ;
            break ;
        if (state == Closed)

void update_normal(sf::RenderWindow & w )
    static sf::Text text("Running!", font) ;
    text.setColor( sf::Color(63, 127, 127) ) ;
    text.setPosition( 200 + std::rand() % 50, 275 + std::rand() %50 ) ;
    w.draw(text) ;

Pages: [1]