Messages

1

Graphics / Re: How to pass Vec4 to sf::Shader

« on: September 22, 2016, 09:32:13 pm »

Hmm... interesting. It seems to be an IDE error. I am using CLion 2016.2.2, and with that exact line it highlights

sf::Glsl::Vec4(color)

with the error "Too many arguments, expected 0".

But if I hit build anyway (which I hadn't before, because it said there was an error), it compiles and runs just fine. I guess I'll go file a bug report on their side then.

Thanks again.

2

Graphics / [SOLVED] How to pass Vec4 to sf::Shader

« on: September 22, 2016, 08:00:27 pm »

tl;dr - I think I found a bug in the new Shader API.


Hi all,

I'm having a little trouble passing a Vec4 color into my shader using the new shader API on 2.4. The documentation suggests that a sf::Color can be converted to a sf::Glsl::Vec4 to be passed into the setUniform method, but I can't get that to happen.

I define my color:

const sf::Color outlineColor = sf::Color::Red;

And then I try the following, which result in the following errors:

shader.setUniform("outlineColor", outlineColor);

Parameter type mismatch: Types 'float' and 'const sf::Color' are not compatible

shader.setUniform("outlineColor", sf::Glsl::Vec4(outlineColor));

Too many arguments, expected 0

I've also tried setting it to a variable first:

sf::Glsl::Vec4 color = outlineColor;

Class 'const sf::Color' is not compatible with class 'sf::Glsl::Vec4'

Thinking maybe it was because my color was const, I tried removing that to no effect. I tried passing a reference:

shader.setUniform("outlineColor", &outlineColor);

But then I get a warning saying: "Parameter type mismatch: Taking boolean from pointer 'sf::Color *' without a cast"

Yet the documentation for setUniform clearly states this should work:

/// This overload can also be called with sf::Color objects
/// that are converted to sf::Glsl::Vec4.

The documentation for Vec4 even says it:

/// sf::Glsl::Vec4 vector(1.f, 2.f, 3.f, 4.f);
/// sf::Glsl::Vec4 color = sf::Color::Cyan;

But having tried both of those, I get errors.

This being my first venture into C++ in many years (I work mostly in C# and Java these days), maybe I'm just missing something. Is there some other way I should be going about causing this conversion, or is this a bug in the new Shader API? I wanted to ask here first before creating an issue on GitHub just in case I'm missing some really obvious step. For now I've resorted to calling the old setParameter method which takes an sf::Color directly, but that causes big ugly errors in my output (rightly so, it's deprecated).

Thanks for the help.

3

DotNet / Re: Corrupted Programmatic Texture

« on: September 17, 2013, 11:39:07 pm »

Well it's good to know that I wasn't missing anything I suppose. Thanks for working out what the problem was and for coming up with a fix so quickly.

4

DotNet / Re: How to connect SFML.NET to Visual Studio 2012?

« on: September 16, 2013, 06:52:46 am »

Looks like you're all set up and running but I wanted to post this here in case people come across it with the same problem. Since it looks like the other SFML.NET Project Template published in the gallery dropped support for VS2012, I went ahead and made one myself. It's not terribly hard to set it up yourself if you know what to do, but I thought I'd share this for a little extra convenience.

http://visualstudiogallery.msdn.microsoft.com/9b4ad5fc-e786-4cc2-9e48-9d3ced32d496

5

DotNet / Corrupted Programmatic Texture

« on: September 16, 2013, 06:42:49 am »

I have been wracking my brain for the past day or so trying to figure this one out, so I thought maybe someone here would be able to see what I'm doing wrong. I'm trying to create a texture that, given a point, will create a circular gradient emanating from that point. I originally had this implemented in a shader, but when I couldn't get it to display properly I re-implemented it in software to make sure I had the logic right. Apparently I don't.

Knowing that Image.SetPixel is a very slow operation, I attempted to create a 2D Color array and pass that in directly instead.

public static class Program
{
    private static readonly Color CornflowerBlue = new Color(100, 149, 237);
    private static readonly Vector2i WindowSize = new Vector2i(1280, 720);

    public static void Main()
    {
        RenderWindow window = new RenderWindow(new VideoMode((uint)WindowSize.X, (uint)WindowSize.Y), "SFML Window");
        window.Closed += (sender, eventArgs) => window.Close();

        Color[,] sourceMap = new Color[WindowSize.X, WindowSize.Y];
        Vector2f startPointInTexels = new Vector2f(0, 0);

        for(int y = 0; y < sourceMap.GetLength(1); y++)
        {
            for (int x = 0; x < sourceMap.GetLength(0); x++)
            {
                Vector2f currentPixelInTexels = new Vector2f(x / (float)WindowSize.X, y / (float)WindowSize.Y);

                float dist = Distance(currentPixelInTexels.X, currentPixelInTexels.Y, startPointInTexels.X, startPointInTexels.Y);
                dist = Math.Min(dist, 1.0f);

                sourceMap[x, y] = new Color((byte)(dist * byte.MaxValue), (byte)(dist * byte.MaxValue), (byte)(dist * byte.MaxValue), 255);
            }
        }
        Sprite sprite = new Sprite(new Texture(new Image(sourceMap)));

        while (window.IsOpen())
        {
            window.DispatchEvents();
            window.Clear(CornflowerBlue);
            window.Draw(sprite);
            window.Display();
        }
    }

    private static float Distance(float x1, float y1, float x2, float y2)
    {
        float x = Math.Abs(x2 - x1);
        float y = Math.Abs(y2 - y1);

        return (float)Math.Sqrt(x * x + y * y);
    }
}
 

But this results in the attached image. From what I can tell, it looks like the underlying OpenGL texture is using an incorrect stride or format, but I couldn't find any way to change these through SFML.NET's API. Does anyone know what I'm missing or doing wrong here?

6

Window / Re: Screen flash on focus change

« on: August 21, 2013, 12:02:00 am »

With the release of SFML/SFML.NET 2.1, I've tried this again and the results have changed somewhat. Creating a borderless window less than the monitor resolution functions as before, with no flash occurring on focus change but the Start bar staying in front of the window.

Creating a borderless window larger than the monitor resolution now functions exactly the same way, so the issue of the window not appearing has indeed been fixed.

A borderless window with the same resolution as the monitor will now cause the flash after the first focus change, but from then on will act the same as the above two scenarios, no longer flashing, but showing the start bar in front of the window. This, unfortunately seems to be a little worse than in 2.0 as it is the most common scenario and while before the visual flash was merely a minor annoyance, the start bar staying in front of the window creates usability issues. It does seem that alt-tabbing back to the window brings it to the foreground (in front of the Start bar, and causes the flash) but merely clicking on the window to bring it into focus does not.

Is there a step I'm missing in the initialization of the window that would solve this problem, or would the appropriate next step be to file a bug report?

7

Window / Screen flash on focus change

« on: June 26, 2013, 08:10:11 pm »

I'm using SFML.NET 2.0 on Windows 7, though I think this issue is also being referred to by this thread which was using C++.

I have a dual monitor setup. I wrote a small app that opens a "fullscreen borderless window" on the primary monitor. I've noticed that whenever the window loses or gains focus (by clicking on something in the second monitor, tapping the windows key, or alt-tabbing) that both monitors present a quick black flash. It doesn't seem to affect functionality at all (I assume the window stops receiving updates, but I haven't actually tested that), so it is a very tiny issue, but it is somewhat annoying. I mainly bring this up as other programs/games that support "fullscreen borderless window" do not present this flash. Of course, this is likely due to however SFML handles focus changes internally.

The app:

using SFML.Graphics;
using SFML.Window;

namespace FocusApp
{
    public static class Program
    {
        public static void Main()
        {
            // Create the main window
            RenderWindow window = new RenderWindow(VideoMode.DesktopMode, "SFML window", Styles.None);

            // Start the game loop
            while (window.IsOpen())
            {
                // Process events
                window.DispatchEvents();

                // Clear screen
                window.Clear(Color.Red);

                // Update the window
                window.Display();
            }
        }
    }
}
 

Update 1: Of interesting note is that this only happens if the window is exactly the same as the monitor resolution. For reference, my native desktop resolution is 1920x1200 on my primary monitor. If, leaving the window borderless, I set the video mode to 800x600, it performs as I would expect and there is no flashing on focus change. If I set the video mode to 1920x1199 (which, admittedly, is probably unsupported but SCIENCE!) the window appears to work as expected, except that the start bar stays on top of it. If I set the video mode to 1920x1201, the window doesn't seem to appear at all (though this places it outside the monitor bounds, and again is likely unsupported) but the icon is still visible on the start bar. Tests with the border turned on resulted in the exact same results as borderless, except that the black flash doesn't NOT occur when the window resolution matches the desktop resolution.

Update 2: It seems the window not appearing thing is already a known issue and it looks like that issue was resolved about a week ago. Would anyone happen to know if this flashing issue I've come across got resolved as a part of that one? I could, of course, download and build the sources myself to find out (I assume, does the .NET binding source stay up-to-date alongside the c++ build?) but if anyone already knows it would save me the trouble.