Topics

1

General / [WIN/NVidia] Context issues after context-refactoring

« on: November 09, 2016, 01:45:26 pm »

I have an issue with SFML since the commit about context-refactoring.

I get an error about failed context creation and other weird stuff (like invalid handle, etc) when using the git master SFML version. It all happens since the commit about removal of internal context-usage (creating context with gl version 0.0). It only appears on my Win7 HP Notebook using an NVidia Quadro 1000M (Driver version 8.17.12.7621). Using one commit earlier does not have any issues and runs just fine. I don't have the issue on other windows machines and by trying with Tank we noticed it's not related to the compiler being used either.
code:

#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>

int main()
{
    // Errors happening in the following line (failed to deactivate, created version 0.0, failed to activate, failed to activate):
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window", 7, sf::ContextSettings(24, 8, 0, 2, 0));
    sf::Texture texture;


    // Errors also happening in the following line:
    if (!texture.loadFromFile("walls.png"))
        return EXIT_FAILURE;


    sf::Sprite sprite(texture);
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }
        window.clear();
        window.draw(sprite);
        window.display();
    }
    return EXIT_SUCCESS;
}

Error log (the first line says: "The handle is invalid"):

(click to show/hide)

I don't think I will be the only person having this issue and I find it rather critical, especially since SFML does work with the previous commit just fine.

2

Window / [Android] Calling Window::create more than once causes blackscreens

« on: November 01, 2016, 03:05:51 pm »

As the title says. In case you're calling window.create() more than once on Android, the screen goes black and that's it. Even when calling it on the same window-instance!

3

Graphics / [Android] called unimplemented OpenGL ES API - GLEXT_glBlendEquation

« on: October 10, 2016, 10:28:18 am »

When setting a specific blendmode to render a sprite, I'm getting the following log-output on Android:

10-10 10:24:50.364: E/libEGL(18856): called unimplemented OpenGL ES API

target.draw(sprite, sf::BlendMode(sf::BlendMode::One, sf::BlendMode::OneMinusSrcAlpha));

When drawing it without a specific blend-mode, all is fine.

I can trace it down to this line in RenderTarget.cpp:

glCheck(GLEXT_glBlendEquation(equationToGlConstant(mode.colorEquation)));

Latest SFML master git version. Android 4.3 Samsung Galaxy S3.

4

Graphics / [Android] Creating texture in thread crashes the app

« on: October 21, 2015, 11:12:06 am »

Hi.

I got my game running on Windows, Linux, OS X and iOS, but I have an issue with Android. Whenever I create a texture inside a thread (which is used to load assets while still rendering/updating/animating the UI fluidly), the app crashes. Using current git branch "feature/system-handle". Mind that the following code works on the other 4 operation-systems without a problem.

Minimal sample:

#include <SFML/Window/Event.hpp>
#include <SFML/System/Thread.hpp>
#include <SFML/Graphics/RenderWindow.hpp>
#include <SFML/Graphics/Texture.hpp>

int main(int argc, char* argv[])
{
    sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "access violation in constructor");

    bool loaded = false;

    sf::Texture* tex;
    sf::Thread thread([&]()
    {
        tex = new sf::Texture(); // crashing in this line on Android only
        loaded = tex->loadFromFile("res/img/gui/Window.png");
    });

    thread.launch() ;

    while ( window.isOpen() )
    {
        sf::Event event ;
        while ( window.pollEvent(event) )
        {
            if ( event.type == sf::Event::Closed )
                window.close() ;
        }
        if(loaded)
            window.setTitle("Thread done, close now");
    }
    delete tex;

    return 0;
}

5

Window / [Ubuntu] Resizing a window hangs up app and system

« on: September 02, 2015, 03:02:12 pm »

Hey. My game uses resizeable windows and they can be resized properly on Windows and OS X, but when trying to resize them on Ubuntu, everything goes very bad. I pick the window-border, move the mouse a little and the window size changes, *but* a blink later it switches right back to the previous size and even worse, when releasing the mouse-button, the window *keeps* resizing with every mouse move (and switching back and forth) all the time. That results in the app basically hanging up and my system too. Rendering is getting totally messy overall and becoming unresponsive until I kill the app via CTRL+C in the terminal it was launched from. The more I move the mouse, the worse the overall system performance gets.
Any ideas?

6

Window / [Ubuntu] window.create crashes the application

« on: August 28, 2015, 03:30:19 pm »

When calling window.create, I get an X11-crash on my Ubuntu

    // using this causes a crash:
    sf::VideoMode videoMode(m_config.get<unsigned int>("ResolutionX"), m_config.get<unsigned int>("ResolutionY"));
    // this works:
    // sf::VideoMode videoMode(m_config.get<unsigned int>("ResolutionX"), m_config.get<unsigned int>("ResolutionY"), 16);
    sf::ContextSettings settings = sf::ContextSettings(24, 8, 0);
    m_screen.create(videoMode, m_windowTitle, m_fullscreen ? sf::Style::Fullscreen : sf::Style::Default, settings);

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  3 (X_GetWindowAttributes)
  Resource id in failed request:  0x320002d
  Serial number of failed request:  37438
  Current serial number in output stream:  37439

By explicitely specifying 16 bits in the video-mode, all is fine. Not specifying a bit-depth causes the application to crash with the above error.

7

Window / [Mac] SFContext::~SFContext crashes due to failed assertion

« on: March 22, 2015, 12:29:40 pm »

Hi.

When having loaded resources in a thread on OS X, the application crashes on exit due to a failed assertion in AutoReleasePoolWrapper.

Minimal sample:

(click to show/hide)

#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>

// Here is a small helper for you ! Have a look.
#include "ResourcePath.hpp"

class Loader {
private:
    sf::Texture& m_texture;
   
public:
    bool loaded;

    Loader(sf::Texture& texture) : m_texture(texture), loaded(false)
    { }
   
    void load()
    {
        m_texture.loadFromFile(resourcePath() + "cute_image.jpg");
        loaded = true;
    }
};

int main(int, char const**)
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
    window.clear();
    window.display();

    sf::Texture texture;
    Loader loader(texture);
    sf::Thread thread(&Loader::load, &loader);
    thread.launch();
   
    while (!loader.loaded)
        sf::sleep(sf::milliseconds(10));
   
    sf::Sprite sprite(texture);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed) {
                window.close();
            }
            if (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape) {
                window.close();
            }
        }

        window.clear();
        window.draw(sprite);
        window.display();
    }

    return EXIT_SUCCESS;
}
 

Stacktrace:

(click to show/hide)

0 --> AutoreleasePoolWrapper.mm
void releasePool(void)
{
0 --> assert(localPool != NULL);

    // If we're done with the pool, let's release the memory
    if (localPool->release())
    {
        delete localPool;
        localPool = NULL;
    }
}

1 --> SFContext.mm
SFContext::~SFContext()
{
    [m_context clearDrawable];
    [m_context release];

    [m_view release]; // Might be nil but we don't care.
    [m_window release]; // Idem.

1 --> releasePool();
}

2 --> GlContext.cpp
void GlContext::globalCleanup()
{
    // Destroy the shared context
    delete sharedContext;
    sharedContext = NULL;

    // Destroy the internal contexts
    sf::Lock lock(internalContextsMutex);
    for (std::set<GlContext*>::iterator it = internalContexts.begin(); it != internalContexts.end(); ++it)
2 -->     delete *it;
    internalContexts.clear();
}

PS: I'm using current master version from github.

8

Graphics / Shaders and RenderTextures

« on: January 29, 2015, 09:06:23 am »

Hi.

I don't know if I'm doing something wrong or if there's a problem with how SFML shaders and render-textures work, but here's what I got.

I'm using latest SFML master from github on Win7 x64 in a 32-bit-build.

======= Sample 1 =======
I'm rending a rect to a RenderTexture and then rendering this texture via shader to the window.

(click to show/hide)

#include <SFML/Graphics/Shader.hpp>
#include <SFML/Graphics/RenderTexture.hpp>
#include <SFML/Graphics/RectangleShape.hpp>
#include <SFML/Window/Event.hpp>

int main(int argc, char* argv[])
{
    sf::RenderWindow window(sf::VideoMode(550, 350), "SFML window");

    sf::RenderTexture target;
    target.create(window.getSize().x, window.getSize().y);
    sf::Shader shader;
    if(!shader.loadFromMemory(
        "uniform sampler2D inputTex;\
        void main()\
        {\
           vec4 renderTargetColor = texture2D(inputTex, gl_TexCoord[0].xy);\
           gl_FragColor = vec4(0, renderTargetColor.g, renderTargetColor.r, 1);\
        }", sf::Shader::Fragment))
         return 1;

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed) {
                window.close();
            }
        }
        sf::RectangleShape a(sf::Vector2f(250, 250));
        a.setFillColor(sf::Color(0, 255, 0, 255));
        target.clear(sf::Color(255, 0, 0, 255));
        target.draw(a);
        target.display();
        glFinish();
       
        window.clear();
        shader.setParameter("inputTex", target.getTexture());
        sf::Shader::bind(&shader);
        sf::Sprite b(target.getTexture());
        window.draw(b);
        window.display();
        sf::Shader::bind(0);
    }
    return 0;
}

The first rendered frame looks like this (green rect on red ground) and it is wrong - its basically the result without use of the shader at all:

All consecutive rendered frames look like this (green rect on blue ground), which is correct use of the shader:

9

SFML projects / Rickety Racquet [including Beta download]

« on: January 22, 2015, 07:34:27 pm »

Download

Rickety Racquet is a tricky game of skill where the player has to control teeters to slap a ball through the level in order to hit required targets. The levels grow difficult pretty quickly and the player has to overcome various traps and obstacles or utilize the environment to reach the desired targets. Bonus-goals increase the points earned for each regular target. These points can be exchanged for goodies which make it easier to complete a level or to gain more points quickly.



The game comes in two modes - the regular mode where all targets have to be hit in order to complete the level and a time attack mode where the player has a fixed amount of time in which he can collect as many points as possible. The points can be tracked in a local and in a global online highscore.

The game is planned to be released for Windows, Mac OS X, Android tablets and iPad. The beta version for windows is completed, the ports for other platforms are being worked on (and looking good for Mac and iPad so far, the game is running and only needs minor adjustments). HD versions are planned and more levels and features are still being implemented.

RicketyRacquet.de

10

Window / [Mac] sf::Mouse::getPosition(relativeTo) in fullscreen always returns (0/0)

« on: January 14, 2015, 12:07:51 am »

Hi.

I'm using SFML master branch and when calling sf::Mouse::getPosition(const sf::Window &relativeTo) in fullscreen mode, I always get (0/0) returned. Not so on Win7. There it is working as expected. Using sf::Mouse::getPosition() does return changing values when moving the mouse.

Greetings

11

Window / [Mac] Fullscreen modes not scaled to screen size

« on: January 13, 2015, 11:55:19 pm »

Hi.

I'm using master branch SFML on OS X 10.10 and when setting fullscreen-modes with a resolution smaller than my desktop resolution, I get a small window in the middle of the screen and large black areas around it. It doesn't get scaled to the full screen size on OS X, but it does scale to the full screen on Win7. Other games on OS X in fullscreen do scale properly, just SFML doesn't. The smaller resolution I chose, the smaller gets the displayed window in the center of my screen. The used resolutions are valid fullscreen-modes and are retained/confirmed via sf::VideoMode::getFullscreenModes().
What am I missing? I am not using multiple monitors or something.

Edit: The sf::Mouse::getPosition() call does return 0/0 for the left upper point of the screen, but not when moving it to the area at which my SFML-window is displayed. When using an 800x600 window on a 1440x900 screen, the upper left coordinate where my window is displayed returns a mouse-coordinate of 320/150. That I can even move the mouse outside of the area at which my window is displayed, feels odd.

Greetings.

12

Window / [Mac] sf::VideoMode::getDesktopMode() returns wrong values for retina

« on: January 13, 2015, 05:51:43 pm »

Hi.

I'm using SFML master version and have set HighResolutionCapable in my info.plist to true.
sf::VideoMode::getFullscreenModes() returns me all available modes including 2880x1800.
sf::VideoMode::getDesktopMode() however returns only 1440x900 instead of the expected 2880x1800.

Greetings

13

Window / [iOS] RenderWindow turns 90° when using style-flags in constructor

« on: November 21, 2014, 10:36:36 am »

Hi.
When using style flags in a RenderWindow-constructor, the screen turns 90° clockwise. If not specifying any flags, it looks fine.
Using iOS 8.1. In 7.x it looks different, but also wrong (with and without flags actually).

Minimal sample code:

#include <SFML/Graphics.hpp>
#include <SFML/Main.hpp>

int main(int argc, char *argv[])
{
    auto mode = sf::VideoMode::getFullscreenModes()[0];
    // the next line causes the problem if some sf::Style flags are passed as parameters (any)
    sf::RenderWindow window(mode, "SFML window", sf::Style::Titlebar );
   
    auto leftRect = sf::RectangleShape(sf::Vector2f(window.getSize().x/2, window.getSize().y));
    leftRect.setFillColor(sf::Color::Red);
    auto rightRect = sf::RectangleShape(sf::Vector2f(window.getSize().x/2, window.getSize().y));
    rightRect.setFillColor(sf::Color::Green);
    rightRect.move(window.getSize().x/2, 0);
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed) {
                window.close();
            }
        }
        window.clear();
        window.draw(leftRect);
        window.draw(rightRect);
        window.display();
    }
   
    return 0;
}

I have attached two screenshots showing the results of passing flags and not passing flags. When not passing flags, the two rects fill the entire screen:
  The red one on the left, the green one on the right - as the code suggests.
When passing flags to the window constructor, the rects get misaligned:


I'm using latest trunk revision of SFML.

14

Window / iOS Settings Version Number

« on: November 18, 2014, 09:32:23 am »

Hi.

I'm currently trying to get SFML to display anything at all on iOS simulator and I noticed that GlContext initializes the settings with version-numbers like that:

Code: [Select]

const GLubyte* version = glGetString(GL_VERSION);
if (version)
{
// The beginning of the returned string is "major.minor" (this is standard)
m_settings.majorVersion = version[0] - '0';
m_settings.minorVersion = version[2] - '0';
}
Now I get the following string returned: "OpenGL ES-CM 1.1 Apple-10.1.5"
The resulting major and minor version numbers are 31 and 53, because it tries to use "O" and "e". Is that a problem or can that be ignored?
(The OpenGL ES specification also verifies this string: https://www.khronos.org/opengles/sdk/1.1/docs/man/glGetString.xml - so the "standard" differs )

15

Window / [solved] Weird Window-Sizes on MacOS

« on: November 12, 2014, 11:01:50 am »

Hi.

I'm using MacOS 10.9 and SFML 2.1 on a MacBook Pro (NVIDIA GeForce GT 750M) with retina display (2560x1600). SFML only lists me video-modes up to 1680x1050 and it looks like the window gets scaled up about twice in size. Even the system-specific window-buttons to close or minimize the app only show in half resolution compared to all other apps.
I don't have such issues with other games. For example Diablo 3 always has the correct size and even allows retina resolution.

Any ideas what's going on? The SFML-sample-applications or Xcode-Templates behave the same by the way.