Unloadable Resources

[JayArby]

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.

[Laurent]

Code: [Select]

myImage = sf::Image();

[Groogy]

Well if you tell them to load a new image for instance I think the old memory is free'd and replaced with the new data.

Also you can control when the memory is free'd using:

Code: [Select]


sf::Image *image = new Image();
/* Do stuff with image */
delete image;


[Fred_FS]

SFML hasn't got any resource manager. Hence a resource could not be destroyed or unloaded.
I would probably hate the SFML, if there were functions like:

Code: [Select]

image.Destroy()
The image would exist further on, but there would not be any valid image information. So have fun with runtime errors .
If you want to unload an image, you have to use an image manager which loads and unloads images. In this manner you make sure that an image is deleted from memory and not usable anymore.

[JayArby]

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.

[JayArby]

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();"

[Fred_FS]

The possibility of having empty objects, means not, that empty objects are good.
A sf:Image is supposed to contain image information. So you should load your image as soon as possible(to prevent errors). And if you don't need the image anymore, you should destroy the variable(e.g. removing it from a list) and not just remove the image information.
In my opinion it is a design problem. You should not create variables and if you don't need them anymore just reset them(and risk to use them although you mustn't).

But if you need it, just use pointers. These will do exactly what you want to. So why not?

And of course it would be pretty easy to add such a function, but - in my opinion - the user is not supposed to do that. And you shouldn't implement functions which are not recommendable to use

[Laurent]

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();"

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.

[Tank]

There's no clean solution to this, I think. What'd be nice is if sf::Image had no constructor but a static Create() method that creates an object for you and also initializes it (by width, height and color).

To load images, you'd use an image loader. AFAIR Laurent had something like that on the roadmap, i.e. moving LoadFromFile() away from sf::Image and provide an external interface to load from different file formats.

That way you won't have uninitialized (or invalid) sf::Image objects anymore.

[Laurent]

AFAIR Laurent had something like that on the roadmap, i.e. moving LoadFromFile() away from sf::Image and provide an external interface to load from different file formats.

Really? :lol:
I remember talking about image formats plugins, but no change in the public API of sf::Image.

That way you won't have uninitialized (or invalid) sf::Image objects anymore.

I wouldn't call them "uninitialized" or "invalid", but "empty". they are perfectly valid, it's just that they contain no pixel data.
Avoiding them is not possible anyway, unless I use exceptions.

[Nexus]

What'd be nice is if sf::Image had no constructor but a static Create() method that creates an object for you and also initializes it (by width, height and color).

And what do you want to return?

• sf::Image? Possibly an unnecessary expensive copy. Move-semantics would help, but SFML doesn't use C++0x.
• sf::Image*? Possibly an unnecessary heap allocation and certainly unnecessary manual memory management.

[Laurent]

sf::Image? Possibly an unnecessary expensive copy. Move-semantics would help, but SFML doesn't use C++0x.

If I add sf::Image::Swap you can use the following trick:

Code: [Select]

sf::Image image;
sf::Image::Load("...").Swap(image);
Not very sexy, I admit

[Nexus]

Yes, but then you can as well write this

Code: [Select]

sf::Image image;
image.Load("...");

[Laurent]

True

What'd be nice is if sf::Image had no constructor but a static Create() method that creates an object for you and also initializes it (by width, height and color).

The problem here is "no constructor". It would make the class hardly usable. Imagine the following situation:

Code: [Select]

class Game
{
public:
    Game()
        : tileset(?????)
    {
    }

    void LoadMap(const std::string& tileset)
    {
        // too late for loading the image...
    }

private:
    sf::Image tileset;
};

[Tank]

I wouldn't call them "uninitialized" or "invalid", but "empty".

Then sf::Image::Unload() or sf::Image::Clear() would just be fine. To be honest I can't really think of situations where it's really needed, but for consistency I'd say it's okay.

And what do you want to return?

Code: [Select]

bool Load( const std::string& filename, sf::Image& image );

I remember talking about image formats plugins, but no change in the public API of sf::Image.

Sorry, that's what I meant. Can't reach the old roadmap anymore, but of course it would also work with the current implementation. If writing plug-ins means to provide an external function that drops an sf::Image, there doesn't need to be changed anything in SFML, at all. That's why I thought the API would change slightly.