Messages

61

General / Building SFML 2.0

« on: November 15, 2011, 08:55:46 pm »

I am trying to build SFML 2.0. I have put all the files into a Code::Blocks project. The entire project builds, but it will not link. I get a lot of undefined references to __imp___glewSomethingOrOther.

I am linking all the third party libraries, including libglew.a. I have googled this problem a thousand times but I cannot figure out what libs I am missing. Can anyone help me with this problem?

62

D / DSFML compile error: Undefined Symbol

« on: October 25, 2011, 10:59:44 pm »

Hi,

I can't seem to compile any code with DSFML. I get "symbol undefined" errors for each DSFML symbol I use. It would appear I am missing some libs, but I am already linking all the csfml libs and the dsfml libs. Are there any other libs I need to link, or is this something else?

I running Windows XP SP3, for the record, and I am using dmd 1.0 with tango.

63

Feature requests / Unloadable Resources

« on: April 27, 2011, 10:59:04 pm »

so...I presume the answer to my feature request is 'no'?

64

Feature requests / Unloadable Resources

« on: April 20, 2011, 06:05:11 am »

Maybe "uninitialized" is the wrong word. "Empty" is a better word. It doesn't imply that the data wasn't initialized.

Example:


fstream myfile; // <- empty object

...

myfile.close(); // <- empty object

65

Feature requests / Unloadable Resources

« on: April 18, 2011, 01:39:11 am »

Sounds like a lot of you are coming from the Java viewpoint, especially with those static factory methods.

In Java, all objects are pointers and null pointers are basically empty objects. In C++, it is completely normal to have stack allocated objects that are invalid until initialized. It's no different from Java in substance, because rather than testing for a null pointer, you convert the object to bool or call some method to test it, like file.isOpen();

Again, I'm fine with the Java way or the C++ way, but mixing them doesn't seem like a good idea.

It makes sense.
However I'm not sure it is really necessary; maybe you should give us an example of a situation where unloading an image while keeping the instance alive is really useful.

Well, here is my personal example: a static Image object is used to display a thumbnail view of the currently selected image in a list of image files. When no image is selected, there is no reason to keep the image in memory. So I want to unload the image so that the thumbnail display will automatically know, on checking the image, that nothing needs to be displayed. So I had to use pointers. No big deal, but it just doesn't seem like the Image class was really meant to be used like that. It would have been more elegant to use a stack allocated object.

66

Feature requests / Unloadable Resources

« on: April 14, 2011, 08:19:45 pm »

Laurent has a good point, but it seems like a clumsy workaround to me.

It is pretty easy to add "Unload" methods to resource objects. As I said, I have already done it myself. I don't see why we should use "image = sf::Image();" rather than the more obvious form, "image.Unload();"

67

Feature requests / Unloadable Resources

« on: April 14, 2011, 08:15:50 pm »

yes, but there seem to be two conflicting philosophies in SFML. If I declare an object like this:

sf::Image myImage;

I have an empty, uninitialized object. So it IS possible to have dead objects.
But after something has been loaded, you can never free the object again. It's like an odd combination of the Java philosophy with the C++ philosophy. If you are going to ensure that the programmer cannot have empty objects, then the above constructor should be disabled.

Either allow empty objects, or disallow them--don't allow only part of the time.

68

Feature requests / Unloadable Resources

« on: April 14, 2011, 05:00:43 pm »

I think resources, such as Images, should be unloadable.

myImage.Destroy();

or something like that. Otherwise, you basically have to leave unneeded garbage in memory, use pointers, or else make sure that all resources go out of scope at exactly the right time, which means stack allocated static global objects are no good.

I already added unload functions to some resources on my computer, but it would be nice if SFML would come with this functionality. I can't understand why it doesn't.

My general rule is, if you are able to have empty objects at any time, then they should provide a public function to reset them. It doesn't make sense (to me) to allow construction of uninitialized objects but never allow the resource to be freed after initialization.