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

Pages: [1] 2 3 4
1
General / mapPixelToCoords returns
« on: December 02, 2013, 06:08:34 pm »
I dont understand why does mapPixelToCoords take in a an integer and returns a float, whereas mapCoordstoPixel takes in a float and returns an interger?
Quote
Vector2f        mapPixelToCoords (const Vector2i &point) const
        Convert a point from target coordinates to world coordinates, using the current view.
 
Vector2f        mapPixelToCoords (const Vector2i &point, const View &view) const
        Convert a point from target coordinates to world coordinates.
 
Vector2i        mapCoordsToPixel (const Vector2f &point) const
        Convert a point from world coordinates to target coordinates, using the current view.
 
Vector2i        mapCoordsToPixel (const Vector2f &point, const View &view) const
        Convert a point from world coordinates to target coordinates.

The part i am having a problem with is:
sf::Vector2f mouse = window.mapPixelToCoords(sf::Vector2i(event.mouseMove.x, event.mouseMove.y));
pixel to coords takes in an int,and returns a float...However floats are not needed. So i would rather return an integer for mouse, but yet cannot because pixels to coords must return of type Vector2f. That or have pixel to coords take in mouse as a float, but that it not possible as well. So how can i get nice flow of only integers or only floats without switching between the two?

2
General / Re: different results on several compiles with same code
« on: December 01, 2013, 01:20:21 pm »
@binary1248
In the past 3 years of programming , i have never used a debugger.  I have always used print statements to determine a value. I attempted to figure out how to use the debugger in Geany IDE, but i couldnt figure the process out.

@windertime
are you referring to:
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>

int main(){
    sf::RenderWindow window(sf::VideoMode(600,400), "Title", sf::Style::Titlebar | sf::Style::Close);
   
    sf::Vector2f position;
    sf::RectangleShape rect;
    float width, height;
   
    rect.setFillColor(sf::Color(200,200,200));
    width = 100.0;
    height = 20.0;
    position = {100.0,100.0};
    rect.setSize(sf::Vector2f(width, height));
    rect.setPosition(position);
   
    sf::Vector2i mouse;

    while (window.isOpen()){
        sf::Event event;
        while(window.pollEvent(event)){
            if (event.type == sf::Event::Closed)
                window.close();
            else if(event.type == sf::Event::MouseMoved){
                int mousex = event.mouseMove.x;
                int mousey = event.mouseMove.y;
               
                if (mousex > position.x &&
                mousex < (position.x + width) &&
                mousey > position.y &&
                mousey < position.y + height){
                    rect.setFillColor(sf::Color(50,50,50));
                }
                else{
                    rect.setFillColor(sf::Color(200,200,200));
                }
            }
        }
        window.clear(sf::Color::Black);
        window.draw(rect);
        window.display();
    }
}
because i still get the same problem.

And regarding mapPixelToCoors. What does this even do? Yes i read the docs. but "Convert a point from target coordinates to world coordinates. " doesn't make sense to me. Trying to read the SFML documentation in the eyes of a newbie is like trying to learn Greek. 

Quote
This function finds the pixel of the render-target that matches the given 2D point. In other words, it goes through the same process as the graphics card, to compute the final position of a rendered point.

Initially, both coordinate systems (world units and target pixels) match perfectly. But if you define a custom view or resize your render-target, this assertion is not true anymore, ie. a point located at (150, 75) in your 2D world may map to the pixel (10, 50) of your render-target – if the view is translated by (140, 25).

This version uses a custom view for calculations, see the other overload of the function if you want to use the current view of the render-target.
I dont know if this is just me or not, but i read this over like 10 times and still i am like WTF?

EDIT:
ok i think you mean this?
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>

int main(){
    sf::RenderWindow window(sf::VideoMode(600,400), "Title", sf::Style::Titlebar | sf::Style::Close);
   
    sf::Vector2f mouse;
    sf::Vector2f position;
    sf::RectangleShape rect;
    float width, height;
   
    rect.setFillColor(sf::Color(200,200,200));
    width = 100.0;
    height = 20.0;
    position = {100.0,100.0};
    rect.setSize(sf::Vector2f(width, height));
    rect.setPosition(position);
   

    while (window.isOpen()){
        sf::Event event;
        while(window.pollEvent(event)){
            if (event.type == sf::Event::Closed)
                window.close();
            else if(event.type == sf::Event::MouseMoved){
                mouse = window.mapPixelToCoords(sf::Vector2i(event.mouseMove.x,event.mouseMove.y));
            }
               
            if (mouse.x > position.x &&
            mouse.x < (position.x + width) &&
            mouse.y > position.y &&
            mouse.y < position.y + height){
                rect.setFillColor(sf::Color(50,50,50));
            }
            else{
                rect.setFillColor(sf::Color(200,200,200));
            }
           
        }
        window.clear(sf::Color::Black);
        window.draw(rect);
        window.display();
    }
}
if so even after using mappixeltocoords, i stll have the same problem.

3
General / Re: different results on several compiles with same code
« on: November 30, 2013, 03:29:10 pm »
it took me awhile to test it to ensure it was still happening as i did get a kernel update and had to re-compile it. Although it still happens with the newer kernel.

All in all, now it happens 1/20 of the time in arch for some reason, regardless of being float or int. Which makes it worse. As it is even harder to test.

Quote
The only spot I could think of where something might go wrong is during the conversion from int to float. Normally it should not be a problem since it is not a narrowing conversion, but considering something has to be a problem, that would be the most likely candidate,
changing everything to float to ensure there is no conversion, i also still get the same problem.



It is driving me nuts as i am not sure i can safely move around in distros and expect the same results with SFML.

#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>

int main(){
    sf::RenderWindow window(sf::VideoMode(600,400), "Title", sf::Style::Titlebar | sf::Style::Close);
   
    sf::Vector2f position;
    sf::RectangleShape rect;
    float width, height;
   
    rect.setFillColor(sf::Color(200,200,200));
    width = 100.0;
    height = 20.0;
    position = {100.0,100.0};
    rect.setSize(sf::Vector2f(width, height));
    rect.setPosition(position);
   
    sf::Vector2i mouse;

    while (window.isOpen()){
        mouse = sf::Mouse::getPosition(window);
        sf::Event event;
        while(window.pollEvent(event)){
            if (event.type == sf::Event::Closed)
                window.close();
            else if(event.type == sf::Event::MouseMoved){
                if (mouse.x > position.x &&
                mouse.x < (position.x + width) &&
                mouse.y > position.y &&
                mouse.y < position.y + height){
                    rect.setFillColor(sf::Color(50,50,50));
                }
                else{
                    rect.setFillColor(sf::Color(200,200,200));
                }
            }
        }
        window.clear(sf::Color::Black);
        window.draw(rect);
        window.display();
    }
}

4
General / Re: different results on several compiles with same code
« on: November 27, 2013, 11:43:18 pm »
Quote
Could you please make this example more minimal

#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>





int main(){
    sf::RenderWindow window(sf::VideoMode(600,400), "Title", sf::Style::Titlebar | sf::Style::Close);
   
    sf::Vector2f position;
    sf::RectangleShape rect;
    int width, height;
   
    rect.setFillColor(sf::Color(200,200,200));
    width = 100;
    height = 20;
    position = {100,100};
    rect.setSize(sf::Vector2f(width, height));
    rect.setPosition(position);
   
    sf::Vector2i mouse;

    while (window.isOpen()){
        mouse = sf::Mouse::getPosition(window);
        sf::Event event;
        while(window.pollEvent(event)){
            if (event.type == sf::Event::Closed)
                window.close();
            else if(event.type == sf::Event::MouseMoved){
                if (mouse.x > position.x &&
                mouse.x < (position.x + width) &&
                mouse.y > position.y &&
                mouse.y < position.y + height){
                    rect.setFillColor(sf::Color(50,50,50));
                }
                else{
                    rect.setFillColor(sf::Color(200,200,200));
                }
            }
        }
        window.clear(sf::Color::Black);
        window.draw(rect);
        window.display();
    }
}
I tried this is Ubuntu 12.04.3 and Windows 8 and they both seem to work 100% of the time. It appears to only happen in Arch.

5
General / Re: different results on several compiles with same code
« on: November 27, 2013, 04:56:13 pm »
well this is quite interesting...
If i compile the previous post's code in Ubuntu 12.04.3, i do not have any problems that i can see. The button always gets highlighted. I tried it about 20 times. Same thing every time. However in Arch Linux, with the same code compiled, most of the time the button gets highlighted, but roughly 1/4 the time i get the problem of the mouse having to be below the button for it to get highlighted. I tried this about 20 times with having this problem about 4 of those times. Such like: http://www.youtube.com/watch?v=Yy1fRtQCXlo&feature=youtu.be
Note the last 2 compiling/runs.

Now my question is what is different about arch and ubuntu. Both of my distros have the required libs for SFML, obviously otherwise they would not compile at all. I normally blame my code first, but i think this time the only thing i can think of is a bug in SFML. Can another Arch Linux user compile this code and have it work 100% of the time?

Both my Arch and Ubuntu are using SFML 2.1 64 bit

6
General / Re: different results on several compiles with same code
« on: November 27, 2013, 04:33:21 pm »
Here is the entire code with that implemented. Your method looks a lot more complex for something i do not understand the benfits of, as it does the same thing as sf::Mouse::getPosition(window) and sending it to Button::update.
Regardless...(if this code is correct in what you meant) the original problem of the OP #1 still exists in the matter of the button gets hovered color sometimes when the mouse is off below the button and somtimes compiled when the mouse is on hte button. identical to the video clip.

#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>


class Button{
    public:
        sf::Vector2f position;
        sf::RectangleShape rect;
        bool is_hovering;
        int width, height;
       
        Button(){
            rect.setFillColor(sf::Color(200,200,200));
        }
           
        void create(float w, float h, float x, float y){
            width = w;
            height = h;
            position = {x,y};
            rect.setSize(sf::Vector2f(w,h));
            rect.setPosition(position);
        }
       

       
        void update(sf::Vector2f mouse){
            if (mouse.x > position.x &&
            mouse.x < (position.x + width) &&
            mouse.y > position.y &&
            mouse.y < position.y + height){
                is_hovering = true;
            }
            else{
                is_hovering = false;
            }
           
            if (is_hovering)
                rect.setFillColor(sf::Color(50,50,50));
            else
                rect.setFillColor(sf::Color(200,200,200));
        }
};

class Control{
    public:
        sf::RenderWindow window;
        sf::Clock clock;
        sf::Time frame_time = sf::seconds(1.f/60.f);
        sf::Time time = sf::Time::Zero, update_time = sf::Time::Zero;
        sf::Vector2i mouse;
        Button button;
       
        Control(){
            window.create(sf::VideoMode(600,400), "Title", sf::Style::Titlebar | sf::Style::Close);
            button.create(100,20, 100,100);
            //window.setKeyRepeatEnabled(false);
        }
       
        void time_update(){
            time = clock.restart();
            update_time += time;

            while(update_time > frame_time){
                update_time -= frame_time;

            }
        }
       
        void update(){
            time_update();
            mouse = sf::Mouse::getPosition(window);
            //button.update(mouse);
           

            render();
        }
       
        void render(){
            window.clear(sf::Color::Black);
            window.draw(button.rect);
            window.display();
        }
       
        void event_handler(){
            sf::Event event;
            while(window.pollEvent(event)){
                if (event.type == sf::Event::Closed)
                    window.close();
                else if(event.type == sf::Event::MouseMoved)
                    button.update(window.mapPixelToCoords(sf::Vector2i(event.mouseMove.x,event.mouseMove.y)));
            }
        }
       
        void run(){
            while (window.isOpen()){
                event_handler();
                update();
            }
        }
};

int main(){
    Control app;
    app.run();
}
 

7
General / Re: different results on several compiles with same code
« on: November 27, 2013, 03:51:42 pm »
Quote
As long as there is a resize button on the window you want to be compatible to it. Some people click it even without thinking about it.
I tried it without touching the window at all to ensure not touching the window resize. However, it still has the same results. I also added sf::Style::Titlebar | sf::Style::Close to window.create() to disable winodw resizing, however i still get the same results.

Quote
You call pollEvent, but you throw away all the information you get instead of using it. You should read the tutorial about all event types. Then you dont need to call Mouse::getPosition anymore. Thats because the mouse does not always move on every frame.
I have read the tutorials. I actually have spent the past few days re-reading and re-reading the tutorials. I have at least read events tutorial page 4 times yesterday. If you are referring to specific method, i would advise you to note that method. No where in this quote do you suggest what specifc event you are referring to. If you are referring to sf::Event::MouseMoved, however i dont know, because you do not say... why use that over this method? Plus i do not see where that would cause such strange behavior with the button class?

Quote
Even worse you have a useless busy loop that calls Button::update a million times with the same data that prevents your program from getting fresh events.
ah ok. Thanks. That makes sense. I had that there after reading the SMFL book. Although now i am not sure why the SFML book states to even have that loop in the first place.
        void update(){
            mouse = sf::Mouse::getPosition(window);
            button.update(mouse);
           
            time = clock.restart();
            update_time += time;

            while(update_time > frame_time){
                update_time -= frame_time;

            }
            render();
        }

8
General / Re: different results on several compiles
« on: November 27, 2013, 03:24:02 pm »
Quote
I suspect its because you sometimes maximize the window before testing. You have to either catch the resize event and adapt the window accordingly or you need to always use mapPixelToCoords on the coordinates you got for the mouse.
I do not change the window size at all. Is this still accurate if i do not?

Quote
I would also think it is better you only update the coordinates when you get a mouse event from the included data and not always read mouse status.
To be 100% honest, i am not exactly sure what you mean by this?

9
General / Re: different results on several compiles
« on: November 27, 2013, 03:07:19 pm »
Quote
Can't reproduce.
I posted this to represent my problem.
Note i did this before i read your second part regarding the missing brackets
http://www.youtube.com/watch?v=Yy1fRtQCXlo&feature=youtu.be
Also the execute button is not just re-running, but also recompiling via:
g++ -std=c++11 -Wall -o "%e" "%f" -lsfml-audio -lsfml-graphics -lsfml-window -lsfml-system &&"./%e"


and 2), ah thanks, I guess i should just always put the brackets when i put one line of code being the fact that i add a line and forget to add the brackets. thanks.

EDIT:
deleted original youtube video and thus replaced previous link with latest link

10
General / different results on several compiles with same code
« on: November 27, 2013, 02:15:18 pm »
My obvious goal is to get a button class in which changes color on mouse hovering over the button. I have 2 problems. 1) if i recompile time after time again, sometimes it prints correctly when the mouse is inside the rectangel, sometimes it prints when the mouse is bleow the rectangle. It is different each time compiling. 2) At the time it does display correctly when the mouse is inside the rectangle, i expected it to change color bassed on is_hovering bool value. However the color never changes, yet the display messages do?

I tried minimizing it, but i am not sure how to minimize it more without losing a working example.

#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>


class Button{
    public:
        sf::Vector2f position;
        sf::RectangleShape rect;
        bool is_hovering;
        int width, height;
       
        Button(){
            rect.setFillColor(sf::Color(200,200,200));
        }
           
        void create(float w, float h, float x, float y){
            width = w;
            height = h;
            position = {x,y};
            rect.setSize(sf::Vector2f(w,h));
            rect.setPosition(position);
        }
       

       
        void update(sf::Vector2i mouse){
            if (mouse.x > position.x &&
            mouse.x < (position.x + width) &&
            mouse.y > position.y &&
            mouse.y < position.y + height){
                std::cout << "inside rect" << std::endl;
                is_hovering = true;
            }
            else
                std::cout << std::endl;
                is_hovering = false;
           
            if (is_hovering)
                rect.setFillColor(sf::Color(50,50,50));
            else
                rect.setFillColor(sf::Color(200,200,200));
        }
};

class Control{
    public:
        sf::RenderWindow window;
        sf::Clock clock;
        sf::Time frame_time = sf::seconds(1.f/60.f);
        sf::Time time = sf::Time::Zero, update_time = sf::Time::Zero;
        sf::Vector2i mouse;
        Button button;
       
        Control(){
            window.create(sf::VideoMode(600,400), "Title");
            button.create(100,20, 100,100);
            //window.setKeyRepeatEnabled(false);
        }
       
        void update(){
            mouse = sf::Mouse::getPosition(window);
           
            time = clock.restart();
            update_time += time;

            while(update_time > frame_time){
                update_time -= frame_time;
                button.update(mouse);
            }
            render();
        }
       
        void render(){
            window.clear(sf::Color::Black);
            window.draw(button.rect);
            window.display();
        }
       
        void event_handler(sf::Event event){
            while(window.pollEvent(event)){
                if (event.type == sf::Event::Closed)
                    window.close();
            }
        }
       
        void run(){
            while (window.isOpen()){
                sf::Event event;
                event_handler(event);
                update();
            }
        }
};

int main(){
    Control app;
    app.run();
}
 

11
General / Re: window creation lag before it centers
« on: November 25, 2013, 02:17:57 pm »
Quote
SDL provides the ability to center the window upon creation. SFML doesn't, you have to do it after the window has been created. That's the difference ;)
ok thanks. It's not really a big deal to anyone other than the programmer anyways.

12
General / window creation lag before it centers
« on: November 25, 2013, 04:48:04 am »
I figured this code to center the window on a single monitor. It does work in general. However it appears to lag for a second or two off to the top-left corner before the window moves/jumps to the center. I would consider this normal behavior, for the exception that Python/Pygame's SDL center window does not do this. It immediately creates it's window without lag in the center.

So i am assuming it is me doing something wrong in coding it. I just do not know what?

The code stripped down to min:
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <iostream>

class Control{
    public:
        sf::RenderWindow window;
        unsigned int monitor[2] = {sf::VideoMode::getDesktopMode().width, sf::VideoMode::getDesktopMode().height},
            screen[2] = {800,600};
        std::string title = "SFML test";
       
        Control(){
            window.create(sf::VideoMode(screen[0], screen[1]), title);
            center_window();
        }
       
        void center_window(){
            window.setPosition(
                sf::Vector2i(
                    (monitor[0] / 2) - (screen[0] / 2),
                    (monitor[1] / 2) - (screen[1] / 2)
                )
            );
        }
       
        void events(sf::Event e){
            while(window.pollEvent(e)){
                if (e.type == sf::Event::Closed){
                    window.close();
                }
            }
        }
       
        void render(){
            window.clear();
            window.display();
        }
       
        void run(){
            while (window.isOpen()){
                sf::Event event;
                events(event);
                //update();
                render();
            }
        }
};

int main(){
    Control app;
    app.run();
}
 

EDIT:
actually it is not like 2 seconds but more like a half a second. It is just enough to notice the difference between SDL centering.

13
General / determine multiple monitors or not
« on: November 25, 2013, 04:22:23 am »
I know SFML does not yet support multiple monitors, more than one fullscreen, etc. I was however, looking for a method to determine whether there was a second montior hooked up or not. I have no idea how to test in windows, but the only thing i can think of in linux is xrandr.
metulburr@laptop:~$ xrandr
Screen 0: minimum 8 x 8, current 3200 x 1080, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
TV-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       60.0*+
HDMI-0 connected 1920x1080+1280+0 (normal left inverted right x axis y axis) 886mm x 498mm
   1920x1080      60.0*+   59.9     24.0     30.0     30.0  
   1440x480       30.0  
   1360x768       60.0  
   1360x765       60.0  
   1280x1024      60.0  
   1280x720       60.0     59.9  
   1024x768       60.0  
   800x600        60.3  
   720x480        59.9     30.0  
   640x480        59.9     59.9  
metulburr@laptop:~$
Of course i am not exactly sure on how to parse the output in c++. Is there at least a method in SFML to test whether there is a lone monitor or not?

14
General / Re: [Solved] SFML 2.1 and Code::Blocks
« on: November 25, 2013, 04:11:56 am »
Quote
4 Hours wasted. Great. Thank you!
At least you didn't take a week, like me, to figure the same out.

15
General / Re: Having trouble solving SFML linker errors
« on: November 23, 2013, 11:43:00 am »
i get a g++.exe/cc1plus.exe/etc. No disk error when using the latest mingw. This led me to believe there was something wrong with the latest mingw based on some forums who said to get a different version. I am not sure how exactly as their website has no previous versions. I prefer cygwin, as then i have access to bash commands in wins command prompt, but SFML complained that it was the wrong type of operating system if i attempt to compile it with cygwin's gcc/g++.
C:\Users\micah_000>g++ -std=c++11 test.cpp -IC:\SFML-2.1\include -LC:\SFML-2.1\l
ib -o test -lsfml-audio -lsfml-system -lsfml-window -lsfml-graphics
cygwin warning:
  MS-DOS style path detected: C:\SFML-2.1\include
  Preferred POSIX equivalent is: /cygdrive/c/SFML-2.1/include
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
In file included from C:\SFML-2.1\include/SFML/System.hpp:32:0,
                 from C:\SFML-2.1\include/SFML/Window.hpp:32,
                 from C:\SFML-2.1\include/SFML/Graphics.hpp:32,
                 from test.cpp:1:
C:\SFML-2.1\include/SFML/Config.hpp:65:6: error: #error This operating system is
 not supported by SFML library
     #error This operating system is not supported by SFML library
      ^
In file included from C:\SFML-2.1\include/SFML/Window.hpp:40:0,
                 from C:\SFML-2.1\include/SFML/Graphics.hpp:32,
                 from test.cpp:1:
C:\SFML-2.1\include/SFML/Window/Window.hpp:105:34: error: expected `)' before `h
andle'
     explicit Window(WindowHandle handle, const ContextSettings& settings = Cont
extSettings());
                                  ^
C:\SFML-2.1\include/SFML/Window/Window.hpp:141:17: error: `WindowHandle' has not
 been declared
     void create(WindowHandle handle, const ContextSettings& settings = ContextS
ettings());
                 ^
C:\SFML-2.1\include/SFML/Window/Window.hpp:424:5: error: `WindowHandle' does not
 name a type
     WindowHandle getSystemHandle() const;
     ^
In file included from C:\SFML-2.1\include/SFML/Graphics.hpp:40:0,
                 from test.cpp:1:
C:\SFML-2.1\include/SFML/Graphics/RenderWindow.hpp:93:40: error: expected `)' be
fore `handle'
     explicit RenderWindow(WindowHandle handle, const ContextSettings& settings
= ContextSettings());
                                        ^

C:\Users\micah_000>
So then i just stole code blocks mingw and copied it over to c:\ to use instead. This at least successfully compiles. However running the program resusts in the error:
the procedure entry point __gxx_personality_v0 could not be located in the dynamic link library C:\SFML-2.1\bin\sfml-graphics-2.dll
with the command:
C:\Users\micah_000>g++ -std=c++11 test.cpp -IC:\SFML-2.1\include -LC:\SFML-2.1\l
ib -o test -lsfml-audio -lsfml-graphics -lsfml-window -lsfml-system
and i am not quite sure what that means. After how easy it is to install in any linux distro i find it quite absurd the process in windows.

EDIT:
oh ok so i came across that code blocks mingw needs sfml TDM. Which now it runs in windows. So in that case is there a version that would run by cygwin's gcc/g++?

Sorry OP, i didn't mean to hijack your thread.

Pages: [1] 2 3 4