Messages

1

General / Re: OSX Mavericks - isKeyPressed is broken.

« on: December 27, 2013, 05:41:06 am »

I actually looked into SDL2 (and other frameworks) to see if I could figure out what was different in the keyboard access. I couldn't find anywhere else that used this ultra low level stuff, which is a double-edged sword. I think you're right that it'll result in more precision, but it also means some uncharted territory.

Anyway, using some sample code from https://developer.apple.com/library/Mac/samplecode/HID_Dumper/Introduction/Intro.html#//apple_ref/doc/uid/DTS40008869, I was able to get a bunch of dumped information for each IOHIDElement inside the device. I ran it in both states and compared the output, but I wasn't able to see anything different other than memory addresses (which vary between every run). There still might be something that I'm missing, though.

Dumping the information on the IOHIDDevice requires a bit more work to get it put into SFML, but I'm going to see what (if anything) I can figure out on that front over the next few days.

2

General / Re: OSX Mavericks segfault on isKeyPressed

« on: December 10, 2013, 08:00:52 pm »

Sadly, it looks like my hope was premature. It wasn't crashing, but I didn't actually test any of the keyboard functionality. It turns out it's still completely broken and not reading any keypresses.

After some debugging, I've determined that the relevant code is from /src/SFML/Window/OSX/HIDInputManager.mm:

Code: [Select]

bool HIDInputManager::isPressed(IOHIDElements& elements)
{
    if (!m_isValid) {
        sf::err() << "HIDInputManager is invalid." << std::endl;
        return false;
    }

    // state = true if at least one corresponding HID button is pressed
    bool state = false;

    for (IOHIDElements::iterator it = elements.begin(); it != elements.end();) {

        IOHIDValueRef value = 0;

        IOHIDDeviceRef device = IOHIDElementGetDevice(*it);
        IOHIDDeviceGetValue(device, *it, &value);

        if (!value) {

            sf::err() << "here." << std::endl;

            // This means some kind of error / disconnection so we remove this
            // element from our buttons

            CFRelease(*it);
            it = elements.erase(it);

        } else if (IOHIDValueGetIntegerValue(value) == 1) {

            sf::err() << "there." << std::endl;

            // This means the button is pressed
            state = true;
            break; // Stop here

        } else {

            sf::err() << "else." << std::endl;

            // This means the button is released
            ++it;
        }

    }

    return state;
}

As you can see, I'm just throwing some debugging lines, since the documentation on Apple's side of this seems to be all but non-existent (or I'm just inept at finding it), which makes it really hard for me to come in completely fresh and get any useful information.

However, with this setup, on the first run (and any subsequent ones that work), I get hundreds of "else" printouts on startup (as expected, since it's in the main loop). Once it enters the broken state, the keyboard no longer works at all until a reboot, and upon startup I get exactly seven "here" printouts.

EDIT: Well, the seven "here" printouts corresponds to the 7 places I call sf::Keyboard::isKeyPressed() in my main loop. Each one corresponds to the first time I call isKeyPressed for a given key. If I have if ( sf::Keyboard::isKeyPressed(sf::Keyboard::Q) ) {} twice, for example, it'll only give me the error printout once. I was thinking the IOHIDDeviceRef was a keyboard, so I was a little confused about why there were a bunch of them, but it looks like it's actually a key.

Also, for the record, the mouse seems to behave just fine. sf::Mouse::isButtonPressed() hasn't ever acted up.

3

General / Re: OSX Mavericks segfault on isKeyPressed

« on: December 10, 2013, 04:00:03 pm »

I think I may have hit upon the solution.

When I rebuilt from the latest, I didn't realize that it wasn't making the dylibs. I thought that the SFML_BUILD_FRAMEWORKS would do both the frameworks AND the dylibs, but that was apparently wrong. So, when I was doing the make and make install, it wasn't actually updating what I was building against. I noticed this and switched my build script back over to frameworks, and it looks like the latest patch works.

Because it was randomly dying in the past, I'm not 100% certain that it's cleared up, but it was in a broken state and now isn't, so that's a pretty good indication.

4

General / OSX Mavericks - isKeyPressed is broken.

« on: December 09, 2013, 08:28:15 pm »

I've seen this mentioned a couple places, but nowhere with a resolution, or even more information.

I have a fairly basic framework that I just started putting together. At this point, it has sprite rendering and some input recognition and that's about it. Out of the blue, it will start segfaulting as soon as it's run, even without changing any code from a functional build. However, once it segfaults once, ANY program that I build with SFML using isKeyPressed will segfault until a reboot. The error log is at http://pastebin.com/6BM96ULt.

I'd paste the whole framework, but the problem is I have a hard time trimming everything out and finding the truly minimal case, since it requires a reboot each time. If we're at a standstill otherwise, I'll spend a couple hours going through that, though.

And, for the record, when I say any program, I truly mean any program. The following causes an isKeyPressed segfault upon launching:

Code: [Select]

#include <SFML/Graphics.hpp>

int main(int argc, char const** argv)
{
    sf::RenderWindow __window;
    __window.create(sf::VideoMode(800, 600), "Crash Test");

    while (__window.isOpen())
    {
        sf::Event event;
        while (__window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed) __window.close();
        }

        if ( sf::Keyboard::isKeyPressed(sf::Keyboard::Q) ) {
            // CRASH
        }
    }
   
    return EXIT_SUCCESS;
}
Any help or information would be greatly appreciated. I haven't found any frameworks I like as much as SFML, but I'm quite close to dropping it and trying another option at this point.

EDIT: Oh, and for what it's worth, I'm using clang from the command line. Also, I've tried it with both the frameworks and the dylibs.

EDIT 2: Not sure why I didn't think of it before, but just to be sure I tested building with gcc, and the same thing occurs.

EDIT 3: Just rebuilt SFML from the latest on github, thinking I might have had an outdated copy without the fix at https://github.com/SFML/SFML/commit/d77f2419383619506fba36b7d6ab93f96e86127f (even though I'm on a laptop with a connected keyboard and mouse). However, it still occurs in the exact same way.

5

Feature requests / Adding optional background color to sf::Text

« on: April 20, 2012, 12:26:16 pm »

I posted it as a question here, but from the response I got it seems like I should post it here.

Many other libraries give you the option of rendering text with a background color. Any chance we could get that in SFML?

6

Graphics / Re: sf::Text Background Color

« on: April 20, 2012, 12:21:04 pm »

sf::Text don't have a background color. At all. It only renders the characters. What you can do is put a rectangular shape under the text.

That's rather unfortunate. I can think of a lot of scenarios where a background color would be desirable, and it seems like a pretty common option in many other libraries.

7

Graphics / sf::Text Background Color

« on: April 20, 2012, 04:13:32 am »

Is there any way to set a background color for an sf::Text object? I can't seem to find one in the documentation, but I may just be blind. If there's not, any recommendations on how to best fake it out? I'm tinkering with a pretty-console roguelike (see Brogue for an example), and being able to set background colors on a string/character basis is sort of important.

I recognize that I could use a sprite sheet with the characters, but that just feels kludgey, especially when scaling comes in to play. I trust the font system to handle resizing much better than naive resizing of a sprite.

8

General / [SFML 2.0] Collision

« on: February 21, 2012, 08:00:42 pm »

* GetPixel() is still on Image class. If you use textures, first copy the texture to a image using CopyToImage()

Most of the differences are easy changes if you read the docs, but this one concerns me a bit. The documentation specifically says that CopyToImage is slow (and it makes sense that it would be), so using this in a collision detection system seems like it might be a bad idea.

What the tutorial code is working with is an sf::Sprite object. Is there any way to directly access the pixel data from there? I can see a way using the GetTexture and GetTextureRect to work backwards, and then use sf::Texture's Pixels member to do the pixel-based comparison, but this seems kludgy.