Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - JayArby

Pages: [1] 2 3 ... 5
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!  8)

13
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
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? ;)

Pages: [1] 2 3 ... 5
anything