Jump to content
  • Advertisement
Sign in to follow this  
Heelp

How to automate texture deleting?

This topic is 829 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Guys, stupid question. Every time I create a texture, I need to call destroyTexture( texture_name ) with SDL 2.0.

 

Is there a way that I can add all the textures to some kind of array and then to somehow automatically destroy them all, so I don't write destroyTexture 100 times.

Share this post


Link to post
Share on other sites
Advertisement
What about just
for (auto texture_name : my_container_of_texture_names)
   destroyTexture(texture_name);
my_container_of_texture_names.clear();
?

Share this post


Link to post
Share on other sites

I don't know what you've written here, but maybe I will create a vector, then push_back all the textures in that vector and then clear the whole vector.

But thanks for the answer.

 

Second question: I have 10-20 textures, for every enemy, and i'm wondering, is it better to load all the textures in one place/function ( loadMedia() for example ), or load every texture in its own enemy class, depending on the enemy?

Edited by Heelp

Share this post


Link to post
Share on other sites

I don't know what you've written here, but maybe I will create a vector, then push_back all the textures in that vector and then clear the whole vector.
But thanks for the answer.


No, that is not enough if you need to call something like destroyTexture. I have simply written a ranged for-loop which iterates over all elements in a container (for example an std::vector) and calls destroyTexture on that element and then empties the container.

Share this post


Link to post
Share on other sites

Second question: I have 10-20 textures, for every enemy, and i'm wondering, is it better to load all the textures in one place/function ( loadMedia() for example ), or load every texture in its own enemy class, depending on the enemy?

 

Definately load them in one place. Enemies should only reference a texture and neigther own nor even load it themselves. A texture should just be an attribute and not functionality of an enemy class, so it could look something like this:

class Enemy
{
public:

    SDL_Texture* pTexture; // I'm not familiar with SDL so thats just pseudo-code
}

where you set pTexture when creating an enemy. There are lots of things that you can do to improve upon this design, but it should be a good starting ground.

Share this post


Link to post
Share on other sites

Juliean, straight answer! Thanks.

 

Bitmaster, I created a std::vector called textures and every time I want a texture, I write: textures.push_back( loadTexture(something.jpg) );

And then when it comes time for destroying - 'for' looop from 0 to textures.size(), is it ok?

Edited by Heelp

Share this post


Link to post
Share on other sites

textures.push_back( loadTexture(something.jpg) );

 

Have you considered what happens when the same texture is requested twice? It might be worth checking if it already exists before loading another copy. 

Share this post


Link to post
Share on other sites
Edit: Unfortunately several posts were added while I was typing this up. When I say "That's certainly one way to go" I was referring to #6, not a map. A map would be rather pointless here.

That's certainly one way to go but you could also take this opportunity to look at some different syntax which offers some minor benefits.

When you do
for (std::size_t i = 0; i < container.size(); ++i)
you are making the compilers job unnecessarily complicated and force it to generate sub-par code. You can do better with
for (std::size_t i = 0, length = container.size(); i < length; ++i)
because now the compiler use the aliasing rules to its advantage. It's still better to use iterators like
for (auto it = container.begin(), last = container.end(); it != last; ++it)
because that turns into something much simpler after the optimizer got its hands on it. When you go
for (const auto& element : container)
you do pretty much that while being less verbose.

While talking about these things for the destruction of a couple of textures is obviously of limited use the basic problem (iterating over some kind of container) is something we do a lot in games. And shaving off a few cycles in inner loops can mean the difference between a smooth display or not. Especially if this also makes loops more readable. Edited by BitMaster

Share this post


Link to post
Share on other sites

First: Bitmaster, basically what you mean is that in my code the 'for' loop calls textures.size() every time ''i'' is incremented, so I better assign a variable 'length' to it, this way I call the size() function only once and cut some operations. It's a small detail, but important, thanks for the quick answer.

 

 

Next: guys I have two classes, class App and class Tile.

 

All my textures are in class App. But in class Tile I have a draw() function.(because I want to draw 8x8 board with tiles, of course )

 

And that  draw() function requires a texture, so I need to get the texture from class App and use it in the draw() function in class Tile.

 

So I wrote a getter for the textures in the class App.

 

and in the class Tile: I wrote this: 

Line 21: void Tile::draw( App app )
{
    renderObject( tilebox, app.getTexture( TEXTURE_EMPTYSQUARE ), app.getRenderer() );
}

and it says: \tile.h|21|error: 'App' has not been declared|

 

but the weird thing is that I wrote #include "app.h" and it still can't find it, and this works in Java, why doesn't it work in C++?

Edited by Heelp

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!