Messages

1

General / Re: Qt Creator + SFML on OSX Mavericks w/ clang

« on: May 17, 2014, 11:03:51 pm »

I'll just try specifying the compilers in CMake as shown in the tutorial and see if that works.

2

General / Re: Qt Creator + SFML on OSX Mavericks w/ clang

« on: May 17, 2014, 11:02:20 pm »

Well ultimately I want to link with the Qt framework, so I'll probably stick with whatever it was compiled with. Do you know specifically what settings are in conflict?

3

General / Re: Qt Creator + SFML on OSX Mavericks w/ clang

« on: May 17, 2014, 09:05:55 pm »

Ah, or are you saying that SFML is by default configured to compile for Xcode with the C++11 compiler and Qt Creator isn't?

4

General / Re: Qt Creator + SFML on OSX Mavericks w/ clang

« on: May 17, 2014, 09:03:59 pm »

Okay, I will try compiling as directed in that tutorial. However, the problem is still not clear to me; are you saying that Qt Creator is using the wrong compiler? If so, shouldn't I be able to simply change the compiler it is using?

5

General / Qt Creator + SFML on OSX Mavericks w/ clang

« on: May 17, 2014, 03:37:07 am »

I am no expert with linking, so I may be doing something stupid, but anyways, I have a strange problem and cannot for the life of me make sense of it.

I am using Qt Creator on OSX Mavericks, compiling with clang. I am NOT using the Qt framework in my project; just using the IDE.

Most of SFML works as expected; however, for some strange reason, I cannot use Image::loadFromFile or Texture::loadFromFile or I get linking errors (Undefined symbols for architecture x86_64). I have compiled and recompiled SFML and tried everything I can think of. I can compile SFML apps via command line, but not within Qt Creator. Does anyone know what the issue might be?

The compiler output is:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -headerpad_max_install_names -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.6 -o test.app/Contents/MacOS/test main.o   -L/usr/local/lib -lsfml-audio-d -lsfml-graphics-d -lsfml-network-d -lsfml-window-d -lsfml-system-d
Undefined symbols for architecture x86_64:
  "sf::Image::loadFromFile(std::string const&)", referenced from:
      _main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [test.app/Contents/MacOS/test] Error 1
21:30:14: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project test (kit: Desktop Qt 5.2.1 clang 64bit)
When executing step 'Make'

This is frustrating me. Thanks people.

6

Feature requests / Re: Virtual Destructors?

« on: June 05, 2013, 07:26:47 pm »

Sorry, I used the wrong term. I didn't mean encapsulation; I meant aggregation.

7

Feature requests / Re: Virtual Destructors?

« on: June 01, 2013, 09:16:12 pm »

Well I thought I had explained the point of it: it's essentially encapsulation. The virtual destructor is to avoid memory leaks, as pointed out.

8

Feature requests / Re: Virtual Destructors?

« on: June 01, 2013, 09:01:04 pm »

You're right, there's really no polymorphism, but that isn't the point. It's really just a way to add features to the type. In a language like ruby, you could do this without inheritance. In C++, that isn't possible without wrapping the class. If you are a purist about it, this a "wrong" usage of inheritance. But in practical terms, it works and it makes sense and I don't see any disadvantage in it.

9

Feature requests / Re: Virtual Destructors?

« on: May 31, 2013, 11:13:56 pm »

It makes a lot more sense to inherit from a Texture than to "contain" it and then duplicate its entire API. Seriously, the destructors should just be virtual. How much of a performance hit could it possibly be? And this is not trying to anticipate every possible situation--it's trying to anticipate the most basic, common of requirements.

10

Graphics / Re: event on a clic on a Shape

« on: May 31, 2013, 11:10:53 pm »

FYI, after a convex shape (or anything else) is drawn on the screen, SFML (or the window or anything else) is not aware that there is a shape there. This is something you would have to write the framework for. SFML just deals with the multimedia aspects of your application; it does not provide the whole structure that would be required for what you are suggesting.

11

Feature requests / Re: Multiple layer support for sprite sheets

« on: May 05, 2013, 11:20:26 pm »

You probably shouldn't be using a RenderTexture for that--just draw the layers directly to the RenderWindow. You can write a class for layered spritesheets (I have written such a class); that's really too high-level a feature for SFML.

12

SFML website / Re: New website

« on: May 05, 2013, 10:38:29 pm »

The new site looks great! 

13

Feature requests / Re: An overload for sf::RectangleShape::setSize that takes 2 float argument

« on: April 13, 2013, 09:21:12 pm »

In final code, I almost always end up using a Vector2f anyway, but if I am hacking something together and want to do a quick test, the constructors/set methods that take plain floats are definitely very handy. I do find myself constantly passing two floats to a given constructor (still) and then realizing my error and going back to create a temporary Vector2f. I'm with iride-it would definitely be nice to see 2-float-constructors come back.

(and if you write the one constructor to call the other one, there isn't really any "duplication".)

14

General discussions / Re: SFML bindings (information for the new website)

« on: April 13, 2013, 09:00:34 pm »

I don't think anyone mentioned Jebbs's D binding, which appears to be very nearly complete:
http://en.sfml-dev.org/forums/index.php?topic=11011.0

15

Feature requests / Re: Semaphores or Conditional Locks

« on: April 13, 2013, 06:37:56 am »

SFML is a Simple library and certainly not a concurrency library

What is sf::Thread for, then?