Certain events only working with framelimit on or off

[ezio160324]

I am working with a simple window that plays some music and shows a red circle. In my code, the code I have to lock the cursor to the center only works with framelimit off. Also, my code for pressing 'esc' to close the window only works with it on. It's confliction. Here's my code:

#include <SFML\System.hpp>
#include <SFML\Config.hpp>
#include <SFML\OpenGL.hpp>
#include <SFML\Window.hpp>
#include <SFML\Graphics.hpp>
#include <SFML\Audio.hpp>
#include <btBulletCollisionCommon.h>
#include <btBulletDynamicsCommon.h>


sf::Event event;
sf::Event event2;
sf::Event event3;


int main() {


        sf::Music music;
        if (!music.openFromFile("meh.flac"))
                return -1; // error
        music.setLoop(true);

        sf::RenderWindow window(sf::VideoMode(800, 600), "OpenGL");
        sf::CircleShape shape(50.f);
        shape.setPosition(100, 0);
        shape.setFillColor(sf::Color::Red);

        sf::Mouse::setPosition(sf::Vector2i(400, 300), window);

        music.play();

        while (window.isOpen())
        {                      
                //input handler loop
                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Escape)) {
                        window.close();
                }


                //event handler loop
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed) {
                                window.close();
                        }
                }

                while (window.pollEvent(event2)) {
                        if (event2.type != sf::Event::MouseLeft) {
                                sf::Mouse::setPosition(sf::Vector2i(400, 300), window);
                        }
                }

                        window.clear();
                        window.draw(shape);
                        window.display();

                }
       

                return 0;
        }

I'm very sensitive about my code, too, so please don't make fun of me for it. 

[Strelok]

You might want to read the tutorials again before someone without temper starts pulling his own hair off looking at this code.
http://www.sfml-dev.org/tutorials/2.1/window-events.php

• You should declare sf::event before the pollevent loop.
• One pollevent loop is all you need
• You're mixing real time input with input handled by the events, are you sure you want to do that?

[Hapax]

Strelok is right. The pollEvent loop should only be done once. When one of the the pollEvent loops finishes, there are no events left so the other will have nothing to work with.

The code is far from the tutorial. Try starting from it and adapting adding in your needs 

#include <btBulletCollisionCommon.h>
#include <btBulletDynamicsCommon.h>

I don't think you really need to be testing collisions etc. in this code 

[ezio160324]

#include <btBulletCollisionCommon.h>
#include <btBulletDynamicsCommon.h>

I don't think you really need to be testing collisions etc. in this code 

Ha, I just have it there for once I'm ready to use it.

But thank you both I got it working now.

[Jesper Juhl]

Since others have already answered your main question and commented on the most important stuff I'll just follow up with a few minor nits:

#include <SFML\System.hpp>

You should use frontslashes "/" consistently when including files (and working with file paths in general), not backslashes "\".
Front slashes work with all compilers and on all operating systems, backslashes only work on Windows (and maybe VMS - can't remember for sure). Also backslashes have to be escaped "\\" in many contexts which you don't have to worry about if you use frontslashes. So just use "/" always.

sf::Event event;
sf::Event event2;
sf::Event event3;


int main() {

As others have already said, you only need a single sf::Event, but that's not what I wanted to comment on here. What I want to say is that you really, really, really want to avoid global variables and especially global variables of SFML types.
To quote from an older post of mine (and another one):

Global variables bring you all sorts of headaches; like:

- It's hard to keep track of where they are read/written since they are not encapsulated.
- Different objects each using the same global variable become very tightly coupled (and you should try to minimize coupling between your classes).
- Global variables in different translation units have undefined order of initialization, so you can't count on one being initialized before another.
- Global variables are constructed before entering main() and destroyed after leaving it which means that they operate in a world where certain things that you assume about your runtime environment may not be true.
- Since they are visible to your entire project, changing one of them potentially requires recompilation of a lot of files.
And more. Just say no.  Friends don't let friends use global variables

Just don't use globals - they are not worth the trouble.

...
        return -1; // error
...
        return 0;
...
 

Those are rather bad values to use for return values from main(). Although in general the rule is that main returns zero for success and non-zero for failure, the only standardized values you can really count on across different systems are the EXIT_SUCCESS and EXIT_FAILURE macros from the <cstdlib> header (and no, EXIT_SUCCESS isn't actually 0 on all operating systems although it probably is for all you care about). Especially returning -1 is a bad idea since not all systems deal sanely with negative return values from main. For example, on Linux the return value from main is actually "the_value_you_provide & 0377" so, for example "return -1" becomes an actual return code of 255, "return -3" becomes 253 and "return 123456" becomes 64 - see where that could become confusing when the operating system tells you that the program exited with error code 255 and you then can't find that anywhere in your code?
Just stick to only ever returning EXIT_SUCCESS and EXIT_FAILURE from main() and you'll be fine on all platforms and compilers.

Ohh and finally, I can recommend clang format if you want a tool to help you format your code consistently (makes it easier to read).

Edit: Forgot one thing I wanted to also mention;
You probably want to use sf::Window::setVerticalSyncEnabled rather than sf::Window::setFramerateLimit when you can. Vsync gives a much better result when it works (is not disabled in drivers). Just remember to never use both at the same time. They interact badly. Only ever use one or the other.

[eXpl0it3r]

Those are rather bad values to use for return values from main(). Although in general the rule is that main returns zero for success and non-zero for failure, the only standardized values you can really count on across different systems are the EXIT_SUCCESS and EXIT_FAILURE macros from the <cstdlib> header (and no, EXIT_SUCCESS isn't actually 0 on all operating systems although it probably is for all you care about). Especially returning -1 is a bad idea since not all systems deal sanely with negative return values from main. For example, on Linux the return value from main is actually "the_value_you_provide & 0377" so, for example "return -1" becomes an actual return code of 255, "return -3" becomes 253 and "return 123456" becomes 64 - see where that could become confusing when the operating system tells you that the program exited with error code 255 and you then can't find that anywhere in your code?
Just stick to only ever returning EXIT_SUCCESS and EXIT_FAILURE from main() and you'll be fine on all platforms and compilers.

Or use a better structure/error handling and not return anything from main(), it's officially allowed by the C++ standard.

[Jesper Juhl]

Sure §3.6.1 states that leaving main without returning a value implicitly returns 0, so that's certainly a valid option. But returning EXIT_FAILURE and EXIT_SUCCESS on success is quite a useful convention - maybe not so much for games and similar applications, but it would be hard or impossible to string multiple commands together on the commandline in many cases if programs didn't generally follow the convention.
Even simple things like - build my app and run it if it build successfully:

$ scons -j 8 && build/my_app

But anyway, we are getting off topic.