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

Pages: 1 2 3 [4] 5 6 ... 31
46
General discussions / Re: Multi monitor support
« on: September 17, 2015, 06:12:32 pm »
Alright! I implemented the change. The new commit can be found here.

Updated testing code:
(click to show/hide)

It would be cool if someone with win7 or older could test this (even with 1 monitor) to see if the dpi is working correctly. Maybe also someone with a high dpi mointor. As always I am open for feedback :)

47
General discussions / Re: Multi monitor support
« on: September 17, 2015, 03:31:02 pm »
Thanks for the clarification! I sometimes get a little confused with the const rules ::)
Just to be sure here: you also think that public members instead of getters are the better design, right? If so I'll change that tonight.

48
General discussions / Re: Multi monitor support
« on: September 16, 2015, 08:18:24 pm »
OK I am not sure if I understand it correctly. Do you mean I should have the members (name, bounds, etc.) public and non-const and have Screen::get() return a const reference? Are the member of a object obtain by get not changeable in this case?

49
General discussions / Re: Fundraiser for a Mac mini
« on: September 16, 2015, 06:48:39 pm »
I totally agree! This is awesome!

50
General discussions / Re: Multi monitor support
« on: September 16, 2015, 06:45:47 pm »
Alrighty it took a little longer than I thought, but here is the new implementation: commit 3902d95d on a new branch.
Here is my testing code:

(click to show/hide)

As you can see I had to change the API a little bit. Originally I wanted sf::Screen to be an immutable object with public const attributes (see above). Apperently there is no way to make an object like this copy-/assignable in C++. So I had to go with an object that has private members and getters. If somebody has a better suggestion I'd be glad to hear it!
So this is what the current API looks like:
class Screen
{
public:

    static std::size_t count();
    static const Screen& get(unsigned int id);


    std::wstring getName() const;
    unsigned int getId() const;
    const IntRect& getBounds() const;
    const IntRect& getWorkingArea() const;
    unsigned int getRefreshRate() const;
    Vector2u getDpi() const;
    bool isPrimary() const;
    const std::vector<VideoMode>& getFullscreenModes() const;
    const VideoMode& getDesktopMode() const;


private:

    friend class priv::ScreenImpl;

    Screen(std::wstring name, unsigned int id, IntRect bounds, IntRect workingArea, unsigned int refreshRate, Vector2u dpi, bool isPrimary, std::vector<VideoMode> fullscreenModes, VideoMode desktopMode);

    void updateId(unsigned int id);


    ////////////////////////////////////////////////////////////
    // Member data
    ////////////////////////////////////////////////////////////
    std::wstring           m_name;            ///< Name of the screen
    unsigned int           m_id;              ///< Id of the screen
    IntRect                m_bounds;          ///< Bounds of the screen in virtual screen space
    IntRect                m_workingArea;     ///< Working area of the screen in virtual screen space
    unsigned int           m_refreshRate;     ///< Refresh rate of the screen
    Vector2u               m_dpi;             ///< Dpi (dots per inch) of the screen
    bool                   m_isPrimary;       ///< Is this the primary screen?
    std::vector<VideoMode> m_fullscreenModes; ///< Supported fullscreen modes of this screen
    VideoMode              m_desktopMode;     ///< Desktop mode of the screen
};
 

I changed a couple things: Reworked the code into the new design, changed the implementation quiet a bit (added dpi and workingArea for example), added a SFML_DEPRECATED macro, moved <SFML/Graphics/Rect.hpp> to <SFML/System/Rect.hpp>, removed the obsolete <Window/Win32/VideoModeImpl.hpp> and some more stuff.
I found the names bounds and workingArea most fitting, so I used those :)

Since quiet a lot changes I'd be happy when some people would test my code and give me some feedback. (For example if the dpi is working on pre win8). It would also be nice if someone from the team could take a look at the implementation and tell me if I got implementation right (especially the inheritance for the platform specific implementation).


Quote from: Hiura on September 15, 2015, 08:33:50 am
[...]we would have a static view of the screen system when the application is started.[...]
Yep thats the current state. I did a bt of reading and it seems that on windows a WM_DEVICECHANGE message is send when a monitor is plugged in or out. So we could react to that and reinitilize the screens. I didn't find anything concerning rearranging in virtual screen space yet.
Like I said I am all for supporting a way to deal with change. I also think we can stick it into the window event loop, because realistically what are you gonna do as a reaction to a screenChangedEvent if not adjusting your windows?
But of course if there is more global event stuff (like sensors) it might be worth rethinking the window event queue. But that's for somebody else to decide :D
I'd say for now we should focus on getting the API and the implementation setteled. The reaction to events can easily be added later.


So check it out and tell me what you think!

51
General discussions / Re: Multi monitor support
« on: September 14, 2015, 07:53:22 pm »
Thanks for your thoughts!

I was looking at the Joystick API when I wrote the new proposal. But to me it seemed cleaner to have an immutable screen object, because a screens properties don't change (except for reconfiguration, but I come to that in a minute). So using sf::Screen::get(unsigned int) gets you an object with only const members and you can't construct one yourself.
For sf::Joystick it might make sense to use the other approach, because the joystick objects are constantly updated by the joystick manager and their values change frequently. Then again it might only be a leftover from the 1.6 sf::Input class which has not been refactored properly when it was put into a seperate class. I don't know. So maybe we should take a closer look for SFML 3.

I added DPI to the class. Good idea! ;)

I actually took the term 'geometry' from Qt ::) I thought it was quiet fitting because it includes both the position and the size. I don't think 'frame' would be better because it is associated with lots of other things. But I'm of course open for suggestions.

Of course we can add a property that specifies the usable area. I left it out originally, because in my first draft the screen was associated with a VideoMode and used mostly for the fullscreen stuff, so it didn't make sense. Now that we have sf::Screen seperate, I'll put it back in. In Qt it's called 'availableGeometry' by the way.

I really like the idea of being able to react to hotplugging/screen resolution changes/rearrangement in virtual screen space/scaling factor changes. I think it would really improve SFML in terms of a multimedia library. You can hotplug all input devices (mouse, keyboard, joystick, sound input), so why not have it for the output devices? I already looked into it for windows and it is defintly possible. But I guess it's not that important for most of the use cases (games). It is more something for multimedia installation or multi-screen apps involving beamers and multiple screens. Also this brings up new questions. For example: Should we put screen events into the window event queue? So I guess we leave that for later and focus on getting basic multi monitor support running. Reacting to events can always be added later.

So if noone else has anything to add I would start rewriting the API/windows implementation to match the proposal. I have some time during the next two weeks that I would like to dedicate to this. Also set up a linux testing rig, so I might start the linux implementation too.

52
General discussions / Re: Multi monitor support
« on: September 12, 2015, 07:43:33 pm »
Hmm yeah the more I think about it the less confusing and better it seems to me to have a seperate sf::Screen class. So I am making a new proposal. The code API would look something like mentioned in dabbertorres post. A seperate class sf::Screen with two static methods for getting the screen count and a screen object based on its ID. A screen object would contain all the info (name, geometry, etc.) and the desktop and fullscreen modes. The VideoMode class would only be used to store the actuall video mode data (width, heigth, bpp, etc.). The VideoMode::getFullscreenModes() and VideoMode::getDesktopMode() would still return the modes to the primary screen to keep backward compatibility, but they would be marked as deprected and could be removed later.

Here is what the code would look like:
class Screen
{
public:
    static unsigned int count();

    static const Screen& get(unsigned int id);


    const std::string name;
    const FloatRect geometry;
    const unsigned int frequency;
    const std::vector<VideoMode> fullscreenModes;
    const VideoMode desktopMode;

private:
    Screen(std::string Name, FloatRect Geometry, unsigned int Frequency);
}


class VideoMode
{
public:
    VideoMode(unsigned int modeWidth, unsigned int modeHeight, unsigned int modeBitsPerPixel = 32, unsigned int screenID = 0);

    bool isValid() const;


    SFML_MARKED_AS_DEPRECATED(static VideoMode getDesktopMode(););
    SFML_MARKED_AS_DEPRECATED(static const std::vector<VideoMode>& getFullscreenModes(););


    unsigned int width;        ///< Video mode width, in pixels
    unsigned int height;       ///< Video mode height, in pixels
    unsigned int bitsPerPixel; ///< Video mode pixel depth, in bits per pixels
    unsigned int screenId;     ///< The Id of the screen this video mode is assosiated with
}

So tell me your opinion. I would love to hear some feedback! What does the rest of the team think?

53
General discussions / Re: Multi monitor support
« on: September 09, 2015, 02:36:13 pm »
Thank you for testing and the feedback!

I like your thoughts about the API. Having sf::Screen seperate from sf::VideoMode sounds interesting. Although it might make the backwards compatibility confusing. (Being able to create video modes through sf::VideoMode and sf::Screen) But let's wait and see what other people think.

About the sf::Screen::frameRate. I agree that refreshRate is the more fitting name in this case. But I don't know if it should be kept in the struct. I initially thought you could use it to sync your rendering with the monitors refresh rate (using sf::Window::setFramerateLimit()), but of course that's what sf::Window::setVerticalSyncEnabled() is for...
Also I thought that I'm putting the monitors nativ refresh rate in there, but looking at the code again, I am actually putting the desktop modes refresh rate in. I don't know how useful that is. Maybe it could still be kept for informational purpose (maybe rename it to defaultRefreshRate).

I was able to get rid of the biggest hack. The platform specific device name is no longer exposed in the public API. I added a new priv::getDisplayDeviceFromId(unsigned int screenId) function to the windows implementation and seperated the deviceName into it's own vector. The API is now cleaner and platform-independent. Here is the new commit 86a6eb93.

I wanted to wait with the Linux implementation until we have decided on a final API, to keep the rewriting work low. I only had a quick look at the Linux code and it seems even more complicated :D Also I don't have a proper multi-monitor linux setup yet, so any help is appreciated.

54
General discussions / Multi monitor support
« on: September 08, 2015, 09:38:35 pm »
Good evening everbody!
I'm starting another attempt at the good old multi monitor setup issue :) But this time I am bringing a fully functional reference implementation for windows with me! You can check it out here: https://github.com/Foaly/SFML/tree/multi-monitor-windows (commit d3bfdbfb)
This weekend I dug through the old discussions and the MSDN and implemented a working multi monitor API for windows. It follows the ideas brought up inprevious threads. I designed the API so that it is fully backwards compatiple with the current SFML master. The usage looks like this:

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

int main()
{
    std::cout << "# of connected Screens: " << sf::VideoMode::getScreenCount() << std::endl;

    // display all supported fullscreen resolutions for all monitors
    for (unsigned int id = 0; id < sf::VideoMode::getScreenCount(); ++id)
    {
        std::vector<sf::VideoMode> modes = sf::VideoMode::getFullscreenModes(id);
        std::cout << "Valid resolutions for screen " << id << std::endl << std::endl;
        for(std::size_t i = 0; i < modes.size(); ++i)
        {
            sf::VideoMode mode = modes[i];
            std::cout << "Mode #" << i << ": "
                      << mode.width << "x" << mode.height << " - "
                      << mode.bitsPerPixel << " bpp" << std::endl;
        }
        std::cout << std::endl;
    }

    // display the desktop resolution for all screens
    for (unsigned int i = 0; i < sf::VideoMode::getScreenCount(); ++i)
    {
        sf::VideoMode mode = sf::VideoMode::getDesktopMode(i);
        std::cout << "Desktop mode for screen #" << i << ": "
        << mode.width << "x" << mode.height << " - "
        << mode.bitsPerPixel << " bpp" << std::endl << std::endl;
    }

    // get infos about the second screen
    sf::Screen screen = sf::VideoMode::getScreenInfo(1);
    std::wcout << "Monitor 1 name: " << screen.realName << std::endl
               << "x: " << screen.geometry.left << " y: " << screen.geometry.top << " width: " << screen.geometry.width << " height: " << screen.geometry.height << std::endl
               << "framerate: " << screen.frameRate << "Hz" << std::endl;


    // open a window on the second monitor
    sf::VideoMode videoMode(1280, 1024, 32, 1);
    sf::Window window(videoMode, "Multi Monitor Example!" /*, sf::Style::Fullscreen*/);

    // run the program as long as the window is open
    while (window.isOpen()) {
        // check all the windows events
        sf::Event event;
        while (window.pollEvent(event)) {
            // "close requested" event: we close the window
            if (event.type == sf::Event::Closed)
                window.close();

            else if (event.type == sf::Event::KeyReleased) {
                // close if escape key was pressed
                if (event.key.code == sf::Keyboard::Escape) {
                    window.close();
                }
            }
        }

        // display the windows content
        window.display();
    }

    return 0;
}

Of course this is a proof of concept rather than a polished and finished implemention. It's supposed to be a base for further discussion about the API and the implementation. I know there are some dirty hacks in there (like including sf::Rect from the graphics package, exposing platform specific details in the public API or breaking compilation on Linux/Mac... ::)) but I'd still love to hear feedback (both on the implementation and the API). Also the code needs testing. I tryed it with my setup (win7 + NVIDIA GTX 970 + 3 monitors) and everything works as expected, but there are loads of different configurations and the winapi is quiet complicated, so if some more people with different configuration would test this, that would be awesome!

Ok I'd love to hear improvents, comments or criticsim. Let's get this feature implemented!

edit: also just noticed 400th post yay :D

55
Graphics / Re: Can't use texture coordinates without a texture
« on: August 05, 2015, 06:19:37 pm »
Has anybody else from the team an opinion about this?

56
Graphics / Re: Can't use texture coordinates without a texture
« on: July 30, 2015, 05:13:48 pm »
But think about it, right now the behaviour is inconsistent. When you have a texture the texture coordinates correspond to their normalized position within the bounds of shape. If you have no texture there is no way to access that position data. Wouldn't it be more consistent to give access to that data in every case?

I know that special behaviour that requires consulting the doc is bad, but the only people who would notice this, would be the people that want to use texture coordinates without a texture anyway. And those people would expect the coords to be set properly.

57
Graphics / Re: Can't use texture coordinates without a texture
« on: July 29, 2015, 02:53:17 pm »
I agree that screen coorinates can be very useful in shaders, but the standart way is to work with normalized coordinates in the fragment shader.
I know it might seem counter intuitive to have texture coordinats set, when there is no texture, but they are set anyway (to 0,0 right now), so why not set them to something useful that people can work with? There are use cases for it. I mean you had the same problem and I am sure other would benefit from this too. Also as a user there is no way to change the texture coordinates of a shape, because they are encapsulated.

@Laurent: could you explain why the second solution would be more hacky? It could simply be stated in the documentation that if there is no texture set, the texture coordinates correspond normalized local coordinates.

edit:
by the way here is the shader code that I am using in case someone is interested:
void main(void)
{
    vec2 uv = gl_TexCoord[0].xy / 40.0;
    const vec2 center = vec2(0.5, 0.5);

    float distanceFromCenter = distance(uv, center);
    const vec2 radiuses = vec2(0.5, 0.3);

    vec4 vertexColor = gl_Color;
    vec4 opaqueColor = vec4(gl_Color.rgb, 0.0);

    float interpolator = 1.0 - smoothstep(radiuses.x, radiuses.y, distanceFromCenter);

    //gl_FragColor = vec4(uv.x, uv.y, 1.0, 1.0);
    gl_FragColor = mix(vertexColor, opaqueColor, interpolator);
}

58
Graphics / Can't use texture coordinates without a texture
« on: July 29, 2015, 12:44:47 pm »
Hello there!

Yesterdy I checked out the radial gradient shader that appeared on the wiki recently, because I wanted to use this effect in a little project of mine. While I was browsing the code I wondered why the code is so complicated. You have to specify a center, a radius and the windows height; all in screen coordinates! So I thought there has to be an easier way using variables that are already defined in the shader, like texture coordinates.

It turns out it's not that easy. I set up a sf::CircleShape with a size, a color, a position and a gradient fragment shader. Something was wrong with the texture coordinates though. When I set the output color to gl_TexCoord[0].xy the output was always black for all fragments. Debbuging into the code of sf::Shape it turns out the texture coordinates are only calculated properly if m_textureRect is set. So I set the texture rect to sf::Int(0, 0, size, size) and the texture coordinates in the shader turned white, meaning there was another problem. I debugged a little further and remembered that SFML uses non-normalized texture coordinates. Since I don't have a texture applyed sf::Texture::bind doesn't get called and the texture coordinates are not being converted. If I devide the coordinates by the shapes size in the shader everything works as expected.

All of that seems quiet hackey to me though. I think we should be able to use the texture coordinates even if the shape has no texture. A lot of effects rely on texture coordinates, especially post processing effects done in the fragment shader, it would be sad if you can't use them with an untextured shape. Or is there a reason that this has been left out?
I'd suggest if m_texture is NULL, set m_textureRect to the shapes dimensions and apply the texture transform matrix in the draw method or simply set the texture coordinates to normalized coordintes when m_texture is NULL. I can write a pull request if this gets agreed on.

59
Feature requests / Re: sf::Text horizontal character spacing
« on: July 21, 2015, 07:16:44 pm »
Ok. As I promised: Cleaned and documented code in a seperate pull request.  :)

60
Feature requests / Re: sf::Text horizontal character spacing
« on: July 21, 2015, 02:02:45 pm »
Cool! Yeah that's what I did.
I will clean my code, document it, push it to a separate branch and send a pull request with an example. Maybe I'll have time to do it tonight.

Pages: 1 2 3 [4] 5 6 ... 31
anything