Messages

16

General / Re: Fixing OS X 10.10 CMake "built for unsupported file format" Errors

« on: November 03, 2014, 08:33:24 pm »

https://github.com/SFML/SFML - Download ZIP. Extract.

Went ahead and redownloaded it. Double click to unzip. Wouldn't you know it, it worked! That was a first, never had a zip problem like that before. Wonder what could cause the symlink problem from a zip?

Thanks a lot for your posts and my apologies about jumping the gun, solution wise.

Another question: if /Users/x/Documents/SFML-master/SFML-master/extlibs/libs-osx/Frameworks/freetype.framework/freetype is a symlink to freetype.framework/Versions/A/freetype, why would linking directly to freetype.framework/Versions/A/freetype cause any harm?

17

General / Re: Fixing OS X 10.10 CMake "built for unsupported file format" Errors

« on: November 03, 2014, 08:17:53 pm »

Nothing seems to be broken when I successfully make this way. My project compiles and runs fine after this. Everywhere I see this problem brought up, no one has an answer for it. I read somewhere one person recommended that for similar errors, you specify deeper in the framework like in my post above. Lo and behold, it worked.

I went ahead and ran make with everything vanilla and these are the errors:

ignoring file /Users/x/Documents/SFML-master/SFML-master/extlibs/libs-osx/Frameworks/freetype.framework/freetype, file was built for unsupported file format ( 0x56 0x65 0x72 0x73 0x69 0x6F 0x6E 0x73 0x2F 0x43 0x75 0x72 0x72 0x65 0x6E 0x74 ) which is not the architecture being linked (i386): /Users/x/Documents/SFML-master/SFML-master/extlibs/libs-osx/Frameworks/freetype.framework/freetype
Undefined symbols for architecture i386:

That is with architecture i386;x86_64 specified. If I remove it, it says:

ignoring file /Users/x/Documents/SFML-master/SFML-master/extlibs/libs-osx/Frameworks/freetype.framework/freetype, file was built for unsupported file format ( 0x56 0x65 0x72 0x73 0x69 0x6F 0x6E 0x73 0x2F 0x43 0x75 0x72 0x72 0x65 0x6E 0x74 ) which is not the architecture being linked (x86_64): /Users/x/Documents/SFML-master/SFML-master/extlibs/libs-osx/Frameworks/freetype.framework/freetype
Undefined symbols for architecture x86_64:

Sndfile will throw an error just like that as well. Using my solution, everything compiles and runs fine.

18

General / Fixing OS X 10.10 CMake "built for unsupported file format" Errors

« on: November 03, 2014, 03:48:39 pm »

Hi, I just wanted to share how I fixed a problem with SFML 2.1 (from repo) and CMake with OS X 10.10 (Yosemite).

If you run make, you may encounter an error with freetype and/or sndfile that says something along the lines of "built for unsupported file format, which is not the architecture being linked".

To fix the error, go to the CMake entries for freetype and sndfile. Their paths will end with:

/extlibs/libs-osx/Frameworks/freetype.framework
/extlibs/libs-osx/Frameworks/sndfile.framework

Change these entries to:

/extlibs/libs-osx/Frameworks/freetype.framework/Versions/A/freetype
/extlibs/libs-osx/Frameworks/sndfile.framework/Versions/A/sndfile

And everything should make just fine.

19

Window / Re: A Concern About Joystick Axises

« on: September 09, 2014, 05:57:04 pm »

Thanks. Hopefully it's not too large of a problem.

20

Window / Re: A Concern About Joystick Axises

« on: September 05, 2014, 09:19:21 pm »

Sorry about the necro-bump, but I was curious if there is any updates on this? I still have the problem.

While rewriting portions of my engine, I changed around Init() order, so I just open the window before handling Input initialization. But, I figure the parent post will still be a problem if someone uses SFML & a gamepad w/o a window.

21

Window / Re: A Concern About Joystick Axises

« on: June 15, 2014, 01:57:32 am »

Windows 7.

22

Window / Re: A Concern About Joystick Axises

« on: June 14, 2014, 05:42:33 pm »

Can anyone reproduce this on their end with their gamepad axises?

23

Window / A Concern About Joystick Axises

« on: June 12, 2014, 08:03:15 pm »

Hi.

I have a tiny concern that I want to put forward, just to clear up if I am screwing something up or I found a quirk.

I have a Playstation 2 -> USB converter and your standard dual shock plugged into it.

In a game I am programming, I have an InputManager written which loads binds and the like and handles all input. The InputManager is initialized before anything happens in the engine. So, since there is no window created yet, I need to call sf::Joystick::update() to update the joystick first. Here is where I found a problem.

In my gamepad, it detect all axises (using hasAxis()) as available, although my pad uses only 4 of them. The axises that are "unavailable" have a constant position value of either -100 or 100. No big deal, I just check to see if those values are constant when setting up binds and disallow use of those axises. With that workaround, everything works fine. Now, here is where I have run into a quirk.

Axis::U is one axis that is unavailable to me. So, if I call sf::Joystick::update(), that axis should give back a value of either 100 or -100 on getAxisPosition(). Except, this axis returns the value of Axis::R UNTIL I create a window and update the joystick again.

Here is the test code that demonstrates. It may or may not work for you, depending on which axis does this for you.

int main() {

        // no window, so update joystick.
        sf::Joystick::update();

        // U is "(un)available" on my pad, so check value. value will be the same as Axis::R, which is a problem.
        std::cout << "Axis U Value:" << sf::Joystick::getAxisPosition(0, sf::Joystick::Axis::U) << std::endl;

        // now, we'll open a window --
        sf::RenderWindow window;
        window.create(sf::VideoMode(640, 480), "A Window", sf::Style::Close);

        // -- and reupdate the joystick. If I don't reupdate, the value will be the same as above.
        sf::Joystick::update();

        // value is now -100, since it's technically not available to me.
        std::cout << "Axis U Value:" << sf::Joystick::getAxisPosition(0, sf::Joystick::Axis::U) << std::endl;

        bool done = false;

        while (!done) {

                if (sf::Keyboard::isKeyPressed(sf::Keyboard::Key::Escape))
                        done = true;

        }

}

It is my understanding that once I call the first sf::Joystick::update(), the joystick should be ready to go, but it isn't.

EDIT: This is the build I am using: https://github.com/SFML/SFML/tree/265c411c39f498f95a03517818167b47b754c440

24

General discussions / Re: The new SFML team

« on: April 22, 2014, 04:02:10 pm »

Congrats, good stuff! Looking forward to see what you guys have up your sleeve!

25

General / Re: Graphic is bugging because of sf::Clock

« on: October 19, 2013, 07:18:04 pm »

Might be a good idea to implement a time step to ensure that you are checking your collision/ticking at a set rate. If you collision checks fluctuate based on a clock, then the check resolution is going to vary.

26

General discussions / Re: AW: Re: Unofficial Nightly Builds

« on: October 19, 2013, 07:15:35 pm »

Can you upload visual studio 2013 build ?

I will!

Awesome. As always, thanks.

27

General discussions / Re: Unofficial Nightly Builds

« on: July 14, 2013, 06:47:48 pm »

Awesome, thank you! Glad to see you're doing this, it's much appreciated.

28

Graphics / Re: SFML 2.0 - Movement lag issue

« on: May 13, 2013, 08:58:53 pm »

In my experience with SFML, on board laptop graphics have poor implementations (drivers?) of OpenGL. I always had lagging/jittering/performance problems on those compared to a desktop with a dedicated card.

29

General / Re: problem running sfml and vs 2012 .exe on different computer

« on: May 09, 2013, 05:06:35 pm »

Also, make sure that any sfml .dll files are in the same directory as the executable.

30

General discussions / Re: Debian/Ubuntu packages for SFML

« on: May 07, 2013, 04:04:17 pm »

I was just thinking about Linux development lately, so this is great to hear. Thanks!