Messages

1

Window / Re: Window setMouseCursorVisible set to false not effective upon start (osx)

« on: September 25, 2014, 12:38:07 am »

Success! I confirm that the "bugfix/osx_cursor_hide" build fixes the cursor problem! 

After a few days outstanding I had lost hope on this one and deserted the forums a while, I'm glad it got sorted out in the end thanks a lot

2

Window / Window setMouseCursorVisible set to false not effective upon start (osx)

« on: September 09, 2014, 05:06:45 am »

I use setMouseCursorVisible to hide to mouse cursor when it enters the SFML window. When set to false, the cursor is still visible when it hovers over the running window until it loses focus and gets it back. Only then the cursor remains hidden over the window.

Here's a small program showing this behavior on osx:

(click to show/hide)

#include <SFML/Graphics.hpp>

int main(int, char const**)
{
    sf::RenderWindow window(sf::VideoMode(1280, 1024), "SFML window");
    window.setMouseCursorVisible(false);
 
    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.display();
    }

    return EXIT_SUCCESS;
}

I use the latest SFML github source.

Simply moving the mouse cursor over the dock then back over the window kicks in the cursor hide. Command+tab does the same as well.

The same issue can be observed in fullscreen video modes.

3

Graphics / Re: Card flipping animation

« on: August 27, 2014, 04:52:16 am »

I think I got the rotation around y-axis to fly but it only works on origin, which makes it rather useless.

This example generates a pattern texture sprite and rotates it on y-axis in the top left corner:

(click to show/hide)

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

int main(int, char const**)
{
    int screenWidth = 1024;
    int screenHeight = 768;
   
    sf::RenderWindow window(sf::VideoMode(screenWidth, screenHeight), "SFML window");
    window.setVerticalSyncEnabled(true);
   
    int width = screenWidth/2;
    int height = screenHeight/2;

    unsigned long size = width * height * 4;
   
    sf::Uint8* pixels = new sf::Uint8[size];
    for (int i = 0; i < size; i+=4) {
            pixels[i+0] = (i%128)+127;
            pixels[i+1] = 255;
            pixels[i+2] = 128;
            pixels[i+3] = 255;
    }
   
    sf::Texture texture;
   
    if (!texture.create(width, height))
    {
        return EXIT_FAILURE;
    }
   
    texture.update(pixels);
       
    sf::Sprite sprite;
    sprite.setTexture(texture);
    sprite.setOrigin(width/2, height/2);
   
    int angle = 0;
   
    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();
            }
        }

        angle++;
        if ( angle > 359) {
            angle = 0;
        }
       
        float rad = angle * 3.141592654f / 180.f;
        float cos = std::cos(rad);
        float sin = std::sin(rad);
       
       
        sf::Transform rotationy(cos,  0,  sin,
                                0,    1,  0,
                               -sin,  0,  cos);
       
        window.clear();
        window.draw(sprite, rotationy);
        window.display();
    }

    return EXIT_SUCCESS;
}
 

I was not able to blend the center translation in the matrix as it is done in the Transform::rotate method, doing so might solve the problem:

(click to show/hide)

Transform& Transform::rotate(float angle, float centerX, float centerY)
{
    float rad = angle * 3.141592654f / 180.f;
    float cos = std::cos(rad);
    float sin = std::sin(rad);  

    Transform rotation(cos, -sin, centerX * (1 - cos) + centerY * sin,
                       sin,  cos, centerY * (1 - cos) - centerX * sin,
                       0,    0,   1);

    return combine(rotation);
}
 

With that said, seems Transformable::getTransform() does not support rotation other than z axis:

(click to show/hide)

const Transform& Transformable::getTransform() const
{
    // Recompute the combined transform if needed  
    if (m_transformNeedUpdate)
    {
        float angle  = -m_rotation * 3.141592654f / 180.f;
        float cosine = static_cast<float>(std::cos(angle));
        float sine   = static_cast<float>(std::sin(angle));
        float sxc    = m_scale.x * cosine;
        float syc    = m_scale.y * cosine;
        float sxs    = m_scale.x * sine;
        float sys    = m_scale.y * sine;
        float tx     = -m_origin.x * sxc - m_origin.y * sys + m_position.x;
        float ty     =  m_origin.x * sxs - m_origin.y * syc + m_position.y;

        m_transform = Transform( sxc, sys, tx,
                                -sxs, syc, ty,
                                 0.f, 0.f, 1.f);
        m_transformNeedUpdate = false;
    }

    return m_transform;
}
 

Was worth the shot, I need something similar in a project. Someone with math skills might make it work 

4

Window / Re: pollEvent crash after window re-create (osx)

« on: August 25, 2014, 11:47:33 pm »

Success! I cannot reproduce the problem anymore, I'll do further tests but it looks good 

It wasn't line 219 exactly but I figured you removed the autorelease.

Here's my exact change:

(click to show/hide)

Thanks a lot!

5

Window / Re: pollEvent crash after window re-create (osx)

« on: August 24, 2014, 12:41:05 am »

Random (most likely totally unrelated) URL

I have no idea if the autorelease wrapper is in cause or not. Either way I have no control over it.

Are you compiling in debug or release mode?

Compiling in debug or release mode yields to the same result.

The code has a lot of error messages and it's weird nothing happens before the crash.

There's a stack trace in the crash log but there are no error messages, just a general protection fault. On my end at least.

6

Window / Re: pollEvent crash after window re-create (osx)

« on: August 23, 2014, 05:11:18 pm »

It keeps recreating the window as soon as you press F once.

It doesn't, did you run the example?

Toggle must be declared in the is open loop

Toggle in this case is not a trigger, it designates state, thus is outside the loop.

and yes, the window create is (probably?) better off of the poll event loop

As mentioned, I did try this option to no avail and posted the simpler example for simplicity.

Out of due diligence, here's another complete example with the window re-create outside the event loop that still triggers the problem:

(click to show/hide)

#include <SFML/Graphics.hpp>

int main(int, char const**)
{
    sf::RenderWindow window(sf::VideoMode(1440, 900), "SFML window");
   
    bool quit = false;
    bool toggle = false;
   
    while (!quit)
    {
        while (window.isOpen())
        {
            sf::Event event;
            while (window.pollEvent(event))
            {
                if (event.type == sf::Event::KeyPressed)
                {
                    switch (event.key.code)
                    {
                        case sf::Keyboard::Escape:
                            window.close();
                            quit = true;
                            break;
                           
                        case sf::Keyboard::Key::F:
                            window.close();
                            break;
                           
                        default:
                            break;
                    }
                   
                }
            }
            window.clear();
            window.display();
        }
       
        if (!quit)
        {
            toggle = !toggle;
            window.create((toggle) ? sf::VideoMode(800, 600) :
                                     sf::VideoMode(1440, 900), "SFML window");
        }
    }
   
    return EXIT_SUCCESS;
}
 

7

Window / pollEvent crash after window re-create (osx)

« on: August 23, 2014, 06:52:31 am »

I get a crash on pollEvent after re-creating the window, immediately after I do a command+tab while moving the mouse or trackpad. It looks like input events are polled on a resource that has been deallocated upon re-creating the window.

Here's a small example that triggers the problem every single time on my macbook with these steps:

• Run example
• Press 'F' key to trigger a window re-create
• Press command+tab to lose window focus while moving mouse/trackpad

Example source:

(click to show/hide)

#include <SFML/Graphics.hpp>

int main(int, char const**)
{
    sf::RenderWindow window(sf::VideoMode(1440, 900), "SFML window");
   
    bool toggle = false;
   
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::KeyPressed) {
                switch (event.key.code) {
                    case sf::Keyboard::Escape:
                        window.close();
                        break;
                       
                    case sf::Keyboard::Key::F:
                        toggle = !toggle;
                        window.create((toggle) ? sf::VideoMode(800, 600) :
                                                 sf::VideoMode(1440, 900), "SFML window");
                        break;
                       
                    default:
                        break;
                }
            }
        }
        window.clear();
        window.display();
    }
   
    return EXIT_SUCCESS;
}
 

The exception as it occurs in Xcode:

(click to show/hide)

The crash log with a test outside Xcode:

(click to show/hide)

Process:         TestWindowCrash [24152]
Version:         0
Code Type:       X86-64 (Native)
Parent Process:  launchd [251]
Responsible:     TestWindowCrash [24152]
Date/Time:       2014-08-23 00:27:21.673 -0400
OS Version:      Mac OS X 10.9.4 (13E28)
Report Version:  11
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT

Application Specific Information:
objc_msgSend() selector name: respondsToSelector:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                     0x00007fff847d40a3 objc_msgSend + 35
1   com.apple.AppKit                    0x00007fff85205af6 -[NSApplication _createDockMenu:] + 137
2   com.apple.AppKit                    0x00007fff85205a2c __44-[NSApplication _copyPublicPersistentUIInfo]_block_invoke + 35
3   libdispatch.dylib                   0x00007fff8ad481bb _dispatch_call_block_and_release + 12
4   libdispatch.dylib                   0x00007fff8ad4528d _dispatch_client_callout + 8
5   libdispatch.dylib                   0x00007fff8ad4cef0 _dispatch_main_queue_callback_4CF + 333
6   com.apple.CoreFoundation            0x00007fff89d8e4f9 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
7   com.apple.CoreFoundation            0x00007fff89d49714 __CFRunLoopRun + 1636
8   com.apple.CoreFoundation            0x00007fff89d48e75 CFRunLoopRunSpecific + 309
9   com.apple.HIToolbox                 0x00007fff8db84a0d RunCurrentEventLoopInMode + 226
10  com.apple.HIToolbox                 0x00007fff8db847b7 ReceiveNextEventCommon + 479
11  com.apple.HIToolbox                 0x00007fff8db845bc _BlockUntilNextEventMatchingListInModeWithFilter + 65
12  com.apple.AppKit                    0x00007fff84fd924e _DPSNextEvent + 1434
13  com.apple.AppKit                    0x00007fff84fd889b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
14  org.sfml-dev.sfml-window            0x000000010cbe5ec3 +[SFApplication processEvent] + 147
15  org.sfml-dev.sfml-window            0x000000010cbea7ef -[SFWindowController processEvent] + 207
16  org.sfml-dev.sfml-window            0x000000010cbdfb03 sf::priv::WindowImpl::popEvent(sf::Event&, bool) + 51
17  org.sfml-dev.sfml-window            0x000000010cbdf116 sf::Window::pollEvent(sf::Event&) + 38
18  TestWindowCrash                     0x000000010cbc2ff0 main + 304 (main.cpp:28)
19  libdyld.dylib                       0x00007fff875ff5fd start + 1
 

The issue occurs even if the resolution is not changed or using different styles. I compiled SFML from source as of today. I did try to re-create the window outside the pollEvent loop but still get the crash at the next pollEvent call.

Note that doing plenty of command+tab and mouse events without window re-creation does not trigger the problem.

Am I doing something wrong here?

8

Graphics / Re: Visible border around fullscreen window (retina)

« on: August 13, 2014, 07:56:49 pm »

By 1 FPS or to 1 FPS?

By 1 FPS yes.

I put them on purpose to avoid a hard video mode switch which would result in resizing all open windows, moving items on the desktop and so on.

Thanks for the clarification.

Now, if you want to measure performance, you'll have to modify SFML internal to use a hard switch or something similar.

I won't go there. I got insight which pertains to borders in fullscreen and why it happens. I will proceed with desktop resolution in fullscreen and handle lower res in a scaled view where applicable. From there I will reassess performance.

Thanks all 

9

Graphics / Re: Visible border around fullscreen window (retina)

« on: August 13, 2014, 01:57:14 pm »

It is indeed the intended behaviour. If you ask for 800x600 you get 800x600. If you want to scale 800x600 to something else then use views.

Fair enough, answers my question.

Do you have proof?

Yes, with a single sprite that covers 2880x1800 I drop 1 FPS. As you stated, I will implement a view scaled up and see how it goes.

normally there should be an option in the video driver to either have black bars or to resize when using a nonfitting resolution?

I remember that setting back when I used a PC. The corresponding feature also affects the desktop on osx.

Thanks for your input!

10

Graphics / Visible border around fullscreen window (retina)

« on: August 13, 2014, 03:04:14 am »

I am testing high dpi resolution on a macbook pro retina. Windowed mode works great but I noticed that resolutions lower than desktop show up with a border in fullscreen. The window pixel size is accurate but does not scale to cover the full screen.

The following valid resolutions are affected:

• 2560 x 1600
• 1680 x 1050
• 1440 x 900
• 1280 x 800

Here's a small complete program to reproduce the problem provided you can test on a macbook pro retina. You will see a white rectangle that matches windows size yet does not take the whole screen.

#include <SFML/Graphics.hpp>

int main(int, char const**)
{
    sf::RenderWindow window(sf::VideoMode(1680, 1050), "SFML window", sf::Style::Fullscreen);
   
    sf::RectangleShape shape;
    shape.setSize(sf::Vector2f(1680, 1050));
   
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::KeyPressed) {
                window.close();
            }
        }

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

    return EXIT_SUCCESS;
}
 

I have compiled SFML from the latest github code and testing on osx 10.9.4. The display settings are set to default "best for display".

Is this intended behavior? is it possible to make the lower resolution scale to fullscreen? of course the fullscreen window size is fine at the native 2880x1800 but it does take hit on performance.

11

SFML projects / Re: Spine: 2D skeletal animation for games

« on: February 18, 2013, 05:45:52 am »

Very nice and polished software exactly what I need. Also backed

12

SFML projects / Re: Blokade [source and binaries now available]

« on: February 03, 2013, 09:56:48 am »

I updated the first post with version 0.9.3 with top 5 high scores support

13

System / Re: isKeyPressed does not always capture input

« on: February 01, 2013, 07:53:38 am »

if I read correctly, you used IsKeyPressed, instead of the signal emmitted by SFML, so only if on that millisecond, the key is pressed down, will it return true, this may be your problem?

I changed my code last week to check if the isKeyPressed is true on this frame but it wasn't on the last frame then I process it as "pressed". It is better but I still get the issue. I'm considering using the SFML events, for the menu navigation anyway. For the gameplay itself, isKeyPressed works great.

By chance, just to rule it out, have you tried a different keyboard?

I have not tried to plug another keyboard on my macbook. Not sure if it works.

if a sleep (or heavy processing) happens before the if statement that's checking for the window closed, that might be causing it

I read the keyboard very early in the frame main loop, I don't really see a hold up.

This is the expected behaviour with real time input. If you have long processing, use sf::Event instead.

Maybe SFML events is the way to go then. Wouldn't be that much code to change.

Thanks all for your help

14

Window / Re: SFML window crashes

« on: January 30, 2013, 05:59:31 am »

yes, try with SFML libraries "MinGW TDM GCC 4.7.1 32bit" from eXpl0it3r's nightly builds http://sfml.my-gate.net/nightly/. The ones from the official download might not work with the latest code::blocks mingw bundle.

15

General / Re: Problem starting SFML 2.0 with CodeBlocks

« on: January 29, 2013, 06:30:40 am »

I had a similar runtime crash problem and using that same nightly build fixed it too