-
Compiler: MinGW
IDE: CodeBlocks 13.12
Platform: Win7, 64bit
Repeatability: Always
Any special compiler settings: None
Version of SFML being used: Using 2.1, grabbed from the official downloads page.
This is the bug: When calling mouseCoord = sf::Mouse::getPosition(window)
and the mouse cursor enters a region around (37,n+) (n+ being any positive number) for what ever reason event.key.code == sf::Keyboard::Escape
becomes true. I am not sure why and I simply don't have enough skill to find out why.
Putting mouseCoord = sf::Mouse::getPosition(window)
after the even code loop still causes event.key.code == sf::Keyboard::Escape
to register as true.
I've actually noticed that the results are different depending on the key used. A couple of keys I've tested are listed at the bottom.
Using the global version of getPosition() doesn't seem to reproduce the bug.
Image used (http://i.imgur.com/FTcqRKI.png). The red part is generally where the "problem area" is.
#include <SFML/Graphics.hpp>
#include <iostream>
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
sf::Texture texture;
if(!texture.loadFromFile("test.png"))
{
return -1;
}
sf::Sprite image(texture);
sf::Vector2i mouseCoord(0,0);
while(window.isOpen())
{
mouseCoord = sf::Mouse::getPosition(window);
std::cout << mouseCoord.x << " " << mouseCoord.y <<"\n";
sf::Event event;
while(window.pollEvent(event))
{
if(event.key.code == sf::Keyboard::Escape)
{
window.close();
}
}
window.clear();
window.draw(image);
window.display();
}
return 0;
}
These are the keys I tested, but I'm sure it affects far more, maybe even all of them
A: Always marked as true
B, C, D, E, F, G, H, I, J, K, L, M: The problem area seems to be around 0,n
Pause: The problem area seems to be around n,0
End, Home: 62,n+
-
You are using sf::Event wrong: http://www.sfml-dev.org/tutorials/2.1/window-events.php
Fix the bugs in your code and then see if the SFML bug still manifests itself.
-
Still happens.
And, if I'm not mistaken, functionally there isn't much different from what I have and the switch statement used in the first example area other than pollEvent() is used to process every pending event.
-
The problem is you don't check if event.type == sf::Event::KeyPressed first, did you correct that?
-
In the added switch statement? Yes.
The statement is
switch (event.type)
{
case sf::Event::KeyPressed:
{
if(event.key.code == sf::Keyboard::Escape)
{
window.close();
}
break;
}
}
EDIT:
So when is the switch suppose to be used and when is pollEvent used? Or are you saying that my while loop should have had a if loop that checked sf::Event::KeyPressed first?
-
If this code causes problem then it's SFML or files/compiler problem:
#include <SFML/Graphics.hpp>
#include <iostream>
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
sf::Texture texture;
if(!texture.loadFromFile("test.png"))
{
return -1;
}
sf::Sprite image(texture);
sf::Vector2i mouseCoord(0,0);
while(window.isOpen())
{
mouseCoord = sf::Mouse::getPosition(window);
std::cout << mouseCoord.x << " " << mouseCoord.y <<"\n";
sf::Event event;
while(window.pollEvent(event))
{
if(event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape)
{
window.close();
}
}
window.clear();
window.draw(image);
window.display();
}
return 0;
}
The point is you should never ever read from any field of sf::Event before checking its type field.
-
That seems to fix it, but why would it still appear here even though it is checking. Or am I not seeing something?
#include <SFML/Graphics.hpp>
#include <iostream>
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
sf::Texture texture;
if(!texture.loadFromFile("cb.bmp"))
{
return -1;
}
sf::Sprite image(texture);
sf::Vector2i mouseCoord(0,0);
while(window.isOpen())
{
sf::Event event;
switch (event.type)
{
case sf::Event::KeyPressed:
{
if(event.key.code == sf::Keyboard::Escape)
{
window.close();
}
break;
}
}
mouseCoord = sf::Mouse::getPosition(window);
std::cout << mouseCoord.x << " " << mouseCoord.y <<"\n";
window.clear();
window.draw(image);
window.display();
}
return 0;
}
And even then, I don't get why getPosition would have an affect on event.
-
Your switch(event.type) should be in while(window.pollEvent(event)) loop, as show in tutorial.
I don't get why getPosition would have an affect on event.
It doesn't, unless there is a bug in SFML which we are trying to confirm or bust, but your code is not correct in a way that allows anything to happen but usually will yield garbage or wrong values, as explained in the tutorial.
-
And even then, I don't get why getPosition would have an affect on event.
Because Event is an union.Please note that the event parameters are defined in a union, which means that only the member matching the type of the event will be properly filled; all other members will have undefined values and must not be read if the type of the event doesn't match. For example, if you received a KeyPressed event, then you must read the event.key member, all other members such as event.MouseMove or event.text will have undefined values.
And sf::Key::Escape is around the 37th value in the enum. So if you're checking event.key.code while not checking you're in a keyboard event, it can be ~37 because of mouse move events.
-
Thanks everyone! I'm not much of a technical person so some of the concepts are hard for me to grasp properly.