I gave you enough of an example to see exactly what was needed. It was enough or you wouldn't have been able to point out the issue. I made a subjective decision on that, and it was the right decision. Don't ask for a complete code listing when I gave you enough. Ask for a complete code listing when I don't.I never requested a full listing for your current code, I simply said "Also for further post", which obviously doesn't include this one. I gave you this advice since I saw that you're new to this forum and most of the new comers don't even think about providing complete examples and me having to answer in every other post "please provide a complete and minimal example that reproduces the error" gets quite annoying too. Prevention is better than reaction. ;)
1. Tell me my code is using bad practices for SFML, but choose not to link me to anything I can actually learn from, and
2. Failed to answer the question I specifically asked for. Which is, what is the interaction between images, textures, and sprites.sf::Image is a representation of an image and lives on the RAM.
Am I expected to keep the images around as well, or do the underlying textures share the images?sf::Image and sf::Texture are both representation of images (i.e. pure memory), thus you actually only need sf::Texture to display something on the screen.
How and when are they released?The SFML objects use all RAII (google it), thus they get released as soon as they leave the scope.
and the documentation for SFML is hard for me to find.You mean what you're looking for is hard to find in the doc right?
If your critique was of the general quality of the C++ code, I would ask you to be quiet. It's tetris.Don't post stuff nobody should ever see or comment upon. ;)
I really want your input, but you didn't really give it. It certainly wasn't enough to help the next person who finds this thread, or to keep me from running into other problems because I don't have the proper mental model for how these things interact with each other in SFML (and I mostly mean from a memory standpoint).Read, learn, experiment. :)
Hey I can also make nice listings
I was typing on my phone and didn't want to write an complete essay on my touch keyboard. So I apologize that I didn't add tons of examples.
I'm aware that ranks and all don't really matter, but it's just very sad to see people join a new forum, totally unaware of their surroundings, what the rules are, how people talk to each other, etc. and the within in the first few posts just show their hate/annoyance towards members that have been around for quite a bit and help quite a few people. I personally try always to be most respectful to anyone when I join a new community. It preserves the atmosphere and you as newbie gain some respect in return.
- Don't pass the window as pointer, pass it as reference. Also instead of passing by value (e.g. std::string), pass them as const reference.
- Don't use arrays, specially if you have to pass it around. If you (for some reason) don't want to use std::vector then at least use std::array (TR1/C++11). The problem with a pure array is, that you never really know it's size and thus you'll have to use many hard coded numbers or other not so nice hacks.
-Don't create a additional sprite object just to initialize it, if you're only purpose is to copy that object to another place later on. E.g. just use setTexture() to set the texture instead of sp(bt).
You mean what you're looking for is hard to find in the doc right?
The doc is easy to find, here.
The SFML objects use all RAII (google it), thus they get released as soon as they leave the scope.
Don't post stuff nobody should ever see or comment upon.
Does all of this mean I'm responsible for the lifetime of the texture? I can't assume that it's going to be cleaned up after there are no more references to it? I don't mean the representation on the video card, I mean the object itself.What? ???
So, even though the constructor for sprite takes a *reference*, it's assumed that reference is to heap memory, or the sprite is not going to last past the current scope?No it can be on the stack, but it (the texture) has to exist when you call window.draw(sprite).
fyi, I've been using C++ since before a standard *existed*.
So, even though the constructor for sprite takes a *reference*, it's assumed that reference is to heap memory, or the sprite is not going to last past the current scope?
Well good luck with your attitude then, I don't like it, but who am I and why would you care?
The question after the claim just boggles my mind.
FWIW, I don't like the idea that these texture objects destroy the data on the vid card when they go out of scope, I think it's counter intuitive and makes it non-obvious when something is getting removedSFML is a simple library, not a complex engine. There's no hidden/automatic ownership, if a sf::Texture instance is destroyed then the corresponding texture data is destroyed. That's the most obvious behaviour that can be implemented.
It's also unusual to destroy a resource while it's in use by another object.Yep, so don't do it ;)
In my head the texture object is just a handle, hence the initial expectation that it would not completely disappear when the object gets cleaned up, especially since you chose to separate textures from sprites.Even if it was a handle, if the only thing that refers to it (the sf::Texture instance) is destroyed, it must be destroyed too. Otherwise it would be lost in the nature and could be considered a leak.
You don't delete a file, you close the handle. You don't delete the DB, you close the connection. All of these are external resources whose lifetimes are controlled by an external entity. Much like an OGL texture. It makes perfect sense to me.In my opinion these comparisons are irrelevant. Files and databases are persistent external objects that applications use; textures are resources that you create, manage and destroy during the lifetime of the application. Nobody else will use them from another program, and nothing must remain when your program ends.
If you spent half the time you spent disliking the design you could already have a sprite that uses reference countingDesign discussions are important, it helps to improve the library (even when I disagree). Implementing your own stuff is always possible but it doesn't help the community ;)
I think that things are overcomplicated in your head; or at least biased by your personal background
Of couse I could use shared ownership between user and sf::Sprite, but that would involve to manipulate sf::Texture instances through pointers and to allocate them on the heap. That would be a pretty bad design for C++; it would be ok for garbage collected languages.
It's fairly trivial to roll up your own sprite/texture type that behave the way you think is more natural from the existing system. On the other hand, it's nearly impossible to do the reverse from a system where the behavior you prefer is enforced.
*As you can see there is slight problem with shared pointers: they are not guaranteed to be in pre 0x standard abiding compiler, boost is too big dependancy, not everyone needs them.
If you spent half the time you spent disliking the design you could already have a sprite that uses reference counting:
Can we please stop with the implications that I'm not a C++ developer? I've been using C++ for something like 18+ years now. It doesn't really add to the conversation, all it does is make it easy to dismiss anything I say, and that isn't fair to me.Ok, I'm sorry. I didn't want to imply anything, I just had the feeling that your point of view was somehow biased by your background, which can be an important consideration when talking about design decisions. No offense.
I see no reason why you couldn't add a small blurb about that onto your code documentation to make it more explicitOf course! I never said I wouldn't. In fact it's already explicitly mentioned in Sprite::setTexture:
The texture argument refers to a texture that must exist as long as the sprite uses it. Indeed, the sprite doesn't store its own copy of the texture, but rather keeps a pointer to the one that you passed to this function. If the source texture is destroyed and the sprite tries to use it, the behaviour is undefined
Of course! I never said I wouldn't. In fact it's already explicitly mentioned in Sprite::setTexture:
That's not enough or we wouldn't be seeing even more posts about this exact issue.It's in Sprite::setTexture and in the "sprite/texture" tutorial. Where else should it be? Certainly not in the general documentation of sf::Texture, since this issue is related to the link between sprites and textures. There's no problem if you use a texture alone.
It's in Sprite::setTexture and in the "sprite/texture" tutorial.
Mentioning that the texture is destroyed when its sf::Texture instance is destroyed... well... if it's not obvious then I don't know what's going on in your brain. Then I should do the same with all classes, saying that their destructor destroys the underlying stuff?
Give me the name of the link on either of those pages that goes to the 'sprite/texture' tutorial. I mean that seriously, I specifically looked on that page as soon as I realized the sprites, textures, and images interacted in a manner that was unexpected for me.As I told you in the first post where I mention the tutorial:
And it is emphasized too in the 2.0 tutorial that is not online yet.In case you didn't notice, SFML 2.0 has not been released yet and none of the graphics tutorials are online ;)
Despite what you and some of the other seem to want to imply, I did look through the documentation before posting, and that includes the tutorialsI never implied that you didn't read the documentation, I simply answered to you saying that "this behaviour should be mentioned".
I understand what's going on underneath, maybe that's part of the problem tooI think we agree on this point, you make too many assumptions. Clear your mind, forget that this is about OpenGL textures. You have an object, and after it is destroyed it can no longer be used. I don't feel like I need to explain that in the doc and/or tutorials.
you may think I'm an assholeI don't, I really appreciate your feedback, documentation and design discussions are really valuable to me. And I didn't mean to insult you (I don't think I did, but sorry if you felt insulted by me).
I'm unsure as to why the other posters cannot follow from your example. It's one thing to disagree, even heatedly. It's another to constantly insult the other party.You're the one who started to insult people; you also take every comment extremely personal, but then don't stop at nothing and call other people to have a "personality quirk". The way you're acting is very immature and thus I had a very hard time believing that you've actually been working with C++ for a bit.
Exploiter cited RAII. RAII is about resource cleanup, not resource destruction, and they are not always the same thing. I understand what's going on underneath, maybe that's part of the problem too.No RAII is about the lifetime of resources.
Resource Acquisition Is Initialization (RAII) is a programming idiom used in several object-oriented languages like C++, D and Ada. The technique was invented by Bjarne Stroustrup to deal with resource allocation and deallocation in C++. In this language, the only code that can be guaranteed to be executed after an exception is thrown are the destructors of objects residing on the stack. Resource management therefore needs to be tied to the lifespan of suitable objects in order to gain automatic allocation and reclamation. They are acquired during initialization, when there is no chance of them being used before they are available, and released with the destruction of the same objects, which is guaranteed to take place even in case of errors.
To me, the OGL driver owns that texture, and anything you do in userspace will be nothing more than requests using a handle. Given that, and the fact that your APi allows me to hand a single texture to multiple sprites, and I have to ask why you think I should assume that texture is getting destroyed on the vid card when the sf::Texture object is destroyed. Why is that a better assumption?As you say it yourself, this is only the way you think and it's not what one would usually expect.
So if I summarize this whole thread, the actual problem is that the tutorial is not online yet...
I think we agree on this point, you make too many assumptions.
Mentioning that the texture is destroyed when its sf::Texture instance is destroyed... well... if it's not obvious then I don't know what's going on in your brain. Then I should do the same with all classes, saying that their destructor destroys the underlying stuff?
You're the one who started to insult people; you also take every comment extremely personal, but then don't stop at nothing and call other people to have a "personality quirk". The way you're acting is very immature and thus I had a very hard time believing that you've actually been working with C++ for a bit.
No RAII is about the lifetime of resources.
As you say it yourself, this is only the way you think and it's not what one would usually expect.
Tell me, when and how would the texture then get destroyed? Because if the design was intended as you say, the OGL driver would be reference counting on its own, which it isn't. So we would still have to do this after all by hands and thus the OGL driver is not directly the owner.
And your documentation isn't enough. The evidence for that is clear, but I'm going to shut my mouth about it. It's apparent you would rather spend your time answering the same question every day than to admit that the documentation should probably be improved. It's your time to spend.I'm the first to admit when the documentation is not complete, and I'm happy to improve it and reduce the amount of dumb questions on the forum. Really.
when there are no more references from sf::texture objects.Every texture is unique, copy of texture will get own resources assigned to it, there is no reference counting in texture.
But how can you say that my documentation is not enough, since the most important piece of documentation, namely the sprite/texture tutorial, is not online yet? Or, if you imply that the tutorial won't be enough no matter what it contains, what else do you suggest?
And you're right about assumptions. I should have answered from the start what I always answer: "don't assume, read the doc"
And your documentation isn't enough. The evidence for that is clear, but I'm going to shut my mouth about it. It's apparent you would rather spend your time answering the same question every day than to admit that the documentation should probably be improved. It's your time to spend.I'm actually not seeing any evidence at all.
That's not enough or we wouldn't be seeing even more posts about this exact issue.
The sprite/texture tutorial isn't online, so from my perspective it doesn't exist. When I say your documentation isn't enough, I mean the documentation you have online right now is not enough.
Documentation that exists, but is not accessible, may as well not exist.
You need more, what you have up now is not enoughOk, now I think you're an asshole ;)
What is needed is a magical way to force people to read the documentation.
Seriously, what's the point of complaining about the incomplete tutorials? It's pretty obvious that I'm still writing them (the graphics section is empty), SFML 2.0 is a development version and has not been released yet. So don't say it's not enough, I know that.
QuoteWhat is needed is a magical way to force people to read the documentation.
If you say so. Personally, I thought I did pore over the documentation, but I'm guessing I didn't because otherwise why would you tell me I didn't? Far be it for me to tell you what I did.
You know, I was going to complain about that link, I *have* been reading those documents. But then I realized the sprite page did describe the issue I was running into. I read it the first time I read over the page, but on subsequent visits I didn't hit the 'more' link and so missed it (and had forgotten the warning about keeping the texture alive, although I did remember that they were kept separate which caused unnecessary fears on my part).
I'm complaining about the expectation that reading the documentation is enough when the documentation is incomplete. I had to read the source. And that's fine, I'm a developer, not a big deal, but I don't like being told to read documentation when it's obviously incomplete.
but no one in this thread has been 'pushed back on' more than me.
Personal? I think you misunderstand Cire, my point is that you have no business telling me what I did.
The evidence I was speaking of was the other posts I saw pop up about roughly the same issue. Am I mistaken? Then tell me I'm mistaken, and be done with it.
The reason I chose not to butt into this was to see if it calmed down on it's own, given it's not I will give you one effective but blunt advice:
Shut Up!