Messages

151

General discussions / Please update the SFML OS X tutorial for C++11

« on: January 25, 2013, 03:24:48 am »

I was following the tutorial for making SFML with C++11 support, but I kept getting linker errors with anything that used anything from the standard library. The one thing I had to add that wasn't in the tutorial was setting CMAKE_C_FLAGS to be stdlib=libc++ too (not just CMAKE_CXX_FLAGS).

This is exactly how I had to do it:

export CMAKE_OSX_ARCHITECTURES=i386;x86_64

cd <sfml folder>

mkdir build

cd build

cmake -G "Unix Makefiles" -DCMAKE_CXX_COMPILER=/usr/bin/clang++ \
-DCMAKE_C_COMPILER=/usr/bin/clang -DSFML_BUILD_FRAMEWORKS=ON \
-DSFML_INSTALL_XCODE4_TEMPLATES=ON \
-DCMAKE_CXX_FLAGS="-stdlib=libc++" -DCMAKE_C_FLAGS="-stdlib=libc++" ../

make -j8

sudo make install
 

Notice the -DCMAKE_C_FLAGS="-stdlib=libc++" at the end. Without it, I kept getting the following errors when making an Xcode project that used clang & libc++ for C++11 support:

Undefined symbols for architecture x86_64:
  "sf::RenderWindow::RenderWindow(sf::VideoMode, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int, sf::ContextSettings const&)", referenced from:
      _main in main.o
  "sf::Font::loadFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _main in main.o
  "sf::Image::loadFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _main in main.o
  "sf::Music::openFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _main in main.o
  "sf::String::String(char const*, std::__1::locale const&)", referenced from:
      _main in main.o
  "sf::Texture::loadFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, sf::Rect<int> 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)
 

Hopefully I'm not crazy...

Also, thanks for SFML! I'm really looking forward to 2.0's official release (and then I'm really looking forward to 2.x when OpenGL ES 2.0 is supported!)

152

General discussions / Re: A new logo for SFML

« on: January 25, 2013, 12:49:45 am »

The gears in the gear logo make me think of a solid engine that works.

I agree that it's a bit generic, but I'm not sure that's a bad thing. Most logos I can think of have nothing to do with their products. It's hard to do anything with "multimedia" that isn't already being done, doesn't look tacky, or is extremely obscure for regular users (like FFmpeg's zig-zag).

In fact, I almost like the generic-ness because I feel like it implies I can create many types of programs that SFML is useful for. There's windowing and graphics and networking and audio and threading and controller stuff all in SFML.

I don't necessarily have anything against a multimedia-focused logo, but I think that gears logo is the most solid candidate I've seen in this thread. It would be cool to explore different logo options if someone has the time & talent to do that, but I certainly don't

So +1 for the gears from me.

153

General discussions / Re: A new logo for SFML

« on: January 21, 2013, 08:12:00 pm »

Am I the only one that thinks the hovering icons (in every logo) are clutterish (and ironic with the "simple" in SFML) and detract from the overall attempt of the logo?

Well 'simple' doesn't imply content/feature less and that's what the icons are representing quite literary.

I didn't mean "simple" as in content/feature-less, but as in clean, easy to use interface (i.e. it is simple/easy to use SFML and it makes your life/the rest of your code code simple if you use SFML). I just feel like the icons, ironically, have the opposite effect on the logo.

154

General discussions / Re: A new logo for SFML

« on: January 21, 2013, 05:50:43 pm »

Am I the only one that thinks the hovering icons (in every logo) are clutterish (and ironic with the "simple" in SFML) and detract from the overall attempt of the logo?

155

General discussions / Re: Let's Create an sf::Pig!

« on: December 21, 2012, 10:57:13 pm »

I tried compiling this but I keep getting "Undefined reference to sf::Pig::runAround" and other errors 

156

General discussions / Re: Linking dependencies

« on: October 14, 2012, 05:10:42 am »

Such a change would indeed require the end-user to link to all the deps himself, but in my opinion telling/teaching them the right way is better than going for an easy approach with accepting that fatal bugs might happen.

I'd like this, personally. Is it possible for it to be a CMAKE option? To me that would be a win-win.

157

General discussions / Re: SFML API ugliness

« on: July 17, 2012, 03:52:33 am »

Laurent started this thread to have a proper place to discuss it.

Ah, I see. Thanks for pointing that out.

158

General discussions / Re: SFML API ugliness

« on: July 17, 2012, 03:05:58 am »

And someone with so much experience shouldn't be afraid to share its opinion about the design of an API. I'm sure it is more than relevant, and could help a lot. So why don't you tell us?

It concerns me that you are so hung up on my opinion of it.

People are "hung up" about it because you created a thread about it...

If you don't want to discuss it, there's no need to create a thread. Creating a thread titled "SFML API ugliness" means you want to discuss SFML API ugliness, no?

[edit]

Sorry, I thought BHXSpecter forked and created this thread to avoid hijacking the other thread. I missed Laurent's post saying he created the fork.

159

Feature requests / Re: Few suggestions

« on: June 23, 2012, 06:46:53 pm »

Correct me if I'm wrong, but even with C++11 I don't think sf::Vector2 would be allowed in a union, because it initializes its members in its default constructor (and thus the constructor is not trivial and sf::Vector2 is not a POD type).

I could be wrong on this, as I've only read part of the standard on this and haven't invested too much time in thoroughly understanding it.

160

Feature requests / Re: Few suggestions

« on: June 22, 2012, 08:45:04 am »

One of the problems with using Vector2 in the events (instead of two fields x and y) is the use of unions. IIRC, Vector2 does not have a trivial default constructor, and so cannot be in a union.

161

General discussions / Re: SFML Xcode Weirdness

« on: June 03, 2012, 07:29:03 am »

Well, it's a total shot in the dark here without any more information, but does the app bundle the SFML framework? If not, and if it's not installed on his machine, it'll crash since it won't be able to load the SFML framework.

You can have him run the app from the command line and see what is printed out. Have him:

cd ApplicaitonName.app/Contents/MacOS
./ApplicaitonName

And tell you what's printed out.

162

General discussions / Re: SFML 2.0 RC

« on: May 29, 2012, 04:28:38 am »

No flip function for the Sprite class? 

I'm pretty sure you can scale by negative amounts to flip. So sprite.setScale(1.0f, -1.0f) would be a flip along the x-axis.

163

General discussions / Re: SFML 2.0 RC

« on: May 07, 2012, 03:48:02 pm »

I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?

Why woud one need such a feature?

It could be easier for creating custom convex shapes. That is, you could take a rectangle as a starting shape, and then slightly transform the points (so it's not a rectangle, but still a convex shape), rather than starting from scratch.

I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape.

So you're the kind of programmer that would make a Square class inherit from Rectangle?
What you suggest is not possible. ConvexShape is less constrained than RectangleShape, so the latter would inherit functions that would be able to break its contract.

Don't forget I said I wouldn't do this in its current form Doing so right now would certainly violate LSP. I suppose I'm thinking of a more component-based design for the shapes, where shape classes are created through composition of various attributes/capabilities. And I figure with a design like this, implementing it with inheritance would require a little less typing (plus allow polymorphic behavior, if done carefully, though I don't know if that's a worthwhile goal).

But I'm ok with the shapes API for now. It's not like these little details are going to stop me or anyone else from making a game. I'm just thinking out loud.

164

General discussions / Re: SFML 2.0 RC

« on: May 06, 2012, 11:24:10 pm »

The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.

You got the point: if you want to manipulate your rectangle as a convex polygon (change every point individually and eventually get a non-rectangle), use sf::ConvexShape. If you want to manipulate your rectangle as a rectangle (change size and position, and let SFML ensure that it will always be a rectangle), then use sf::RectangleShape.

I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?

I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape. But I don't think it should inherit from ConvexShape in its current form, and I haven't given enough thought to this to propose any kind of clean alternative. I don't think it's a show-stopper though, so I'm not too concerned with it.

165

Feature requests / Re: Cursor icon

« on: May 02, 2012, 04:33:18 am »

It's not really quite that simple though, because then you get into the issue of whether or not cursors should be animated, and how you should handle multiple cursor images (for example, changing the image based on what the mouse is hovering over), etc. Each game seems to use the cursor differently, and I don't think there's a clean way to solve all these problems, and just implementing a naive solution is just a waste of time as users of SFML can easily implement it in just a few lines of code.