Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implemented support for mipmap generation #973
Looks good overall.
While hasMipmap() is not really necessary, it might be convenient for the user if their architecture requires them to be able to tell if mipmaps need to be regenerated or not. If we don't track this state, they will have to themselves, and I assume it is simpler for us to do directly in
From what I can tell (you can see this in the comment which I forgot to change when I removed GLU), the only reason for the manual management in that example was because we wanted to use GLU to generate the mipmap. Since GLU got removed, and we can even generate the mipmap ourselves now, there is no point to manually manage texture creation. And besides... this is a better example of interoperability between SFML and OpenGL if you ask me.
Well... it depends on what we tell users who don't bother calling
What makes it even worse is that the current mipmap implementation doesn't even work unless the FBO implementation is available in the first place, so the case where it would actually make sense (the default implementation) doesn't even happen in practice.
It does get invalidated. I just omitted the additional texture saving etc. that is present in
Not sure. In most scenarios, users will know exactly when to regenerate mipmaps without tracking a state (after the call to load or update, or every frame). I'd really prefer to go with the minimal API first, and add this kind of function (which is pure convenience) later if really needed.
I thought about it again and reached the same conclusion. I even knew that you would answer that
So far, we have always enforced the call to
Sorry, I missed that in the diff.
And don't forget my last point, I guess I added it after you read my post: