Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Opinions wanted - SpriteManager

This thread is locked; no one can reply to it. rss feed Print
 1   2   3   4 
Opinions wanted - SpriteManager
Arthur Kalliokoski
Second in Command
February 2005
avatar

@Stas B: Your tone seems to be one of exasperation to somebody who has failed to understand your explanation many, many times already. Has Itachihro failed to comprehend that many times? Or maybe you're surrounded by drooling idiots at work?

They all watch too much MSNBC... they get ideas.

Thomas Fjellstrom
Member #476
June 2000
avatar

Your solution didn't cover his use case as far as I can recall.

Stas B. said:

You can argue otherwise and try to demonstrate that what I'm saying is simply false, but you can't just brush off my criticism, imply that I'm just biased and narrow-minded and expect me to be pollite to you

Assuming you were polite to begin with.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Stas B.
Member #9,615
March 2008

@Stas B: Your tone seems to be one of exasperation to somebody who has failed to understand your explanation many, many times already. Has Itachihro failed to comprehend that many times? Or maybe you're surrounded by drooling idiots at work?

Assuming you were polite to begin with.

I was talking about purely technical things and said nothing offensive untill OP started accusing me.

Quote:

Your solution didn't cover his use case as far as I can recall.

Not sure what you mean. "My" solution (a pretty standard solution, actually) allows you to get a resource by string and to refresh resources (without unnecessary reloading) without using smart pointers or having to keep a list of resource instances externally in places where it doesn't belong. His resource manager just doesn't manage resources. ???

Arthur Kalliokoski
Second in Command
February 2005
avatar

Your first post starts off with:

Stas B. said:

Why all those shared_ptrs? The SpriteManager should be solely responsible for creating and destroying sprites, so they're pointless.

It sounds like you're entirely certain of what he's trying to do here, as if you'd written the exact same thing correctly already.

They all watch too much MSNBC... they get ideas.

Stas B.
Member #9,615
March 2008

It sounds like you're entirely certain of what he's trying to do here, as if you'd written the exact same thing correctly already.

It's a resource manager, for God's sake. I know what resource managers are supposed to do. They're supposed to manage resources. It's the job of a resource manager to destroy a resource. The point of shared_ptrs is to destroy things implicitly when it's unclear who is responsible for that. It makes no sense to artificially offload the responsibility to a shared_ptr and in the process force the clients of the resource class to keep their own shared_ptrs to make sure the resources don't get destroyed prematurely. How are we even arguing about this? Why would a Level class have to keep a list of enemy sprite instances?

In any case, anyone who finds that quote offensive needs to man the hell up.

Arthur Kalliokoski
Second in Command
February 2005
avatar

You're doing it again. ::)

They all watch too much MSNBC... they get ideas.

Stas B.
Member #9,615
March 2008

Okay. I'm stumped. What are you trying to say? That maybe OP is a special person with a special game that needs a resource manager unlike any other game? That was pretty unlikely and turned out to not be the case. What is your point?

Thomas Fjellstrom
Member #476
June 2000
avatar

Stas B. said:

I was talking about purely technical things and said nothing offensive untill OP started accusing me.

You tend to sound all "Mr. Know It all". It rubs off on even your helpful posts. Then you jump pretty quickly into being all condescending and offensive.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Karadoc ~~
Member #2,749
September 2002
avatar

I also hold the view that Stas B. is being a bit too aggressive in expressing his opinion. To me it looks like Stas B. launched in statements such as "/You are misusing smart pointers./" and "/If by that you mean that Level objects have a list of shared_ptrs to all their resources, that's really stupid./" without making an honest attempt to understand Itachihro's goals.

Regardless of whether or not Itachihro's approach is unconventional (and I'm not saying that it is unconventional), I don't think he is 'misusing' smart pointers. He's just using smart pointers for something which may or may not require them. In fact, in general I think it's not a bad idea to use smart pointers for pretty much everything - so that the programmer doesn't have to remember to delete everything at the end if its usefulness, and so that it is safe to throw an exception anywhere in the code without crashing a memory leak. (Note: this doesn't necessarily mean using shared_ptr. The goals I described could be achieved by using std::unique_ptr inside the sprite manger, and so on. But Stas B. said 'misusing smart pointers', not 'misusing shared_ptr'...)

As for the system being 'stupid'.. again, I think it's rude and narrow minded to call a system stupid without first making an attempt to understand its purpose.

It is possible to offer suggestions and criticism without calling someone stupid or wrong. If the code does what it is intended to do, then it isn't really 'wrong' anyway. (It might not be ideal or efficient, but if it does its job correctly then it is not wrong...)

-----------

Stas B.
Member #9,615
March 2008

I also hold the view that Stas B. is being a bit too aggressive in expressing his opinion.

And I hold the view that the people criticizing me in this thread don't see the forest for the trees.

Quote:

without making an honest attempt to understand Itachihro's goals.

His goals were obvious and he confirmed them to be the usual goals of a resource manager.

Quote:

In fact, in general I think it's not a bad idea to use smart pointers for pretty much everything

And I think, if you're going to call yourself a programmer, you might as well think about what you're doing and the about the purpose of the tools you're using instead of sticking to some silly "always do" or "never do" rules and doing things blindly. In this case, his plain and simple abuse of smart pointers lead to a ridiculous requirement for the clients of his class to store their own lists of shared_ptrs to make sure the resources don't die unexpectedly.

Quote:

As for the system being 'stupid'.. again, I think it's rude and narrow minded to call a system stupid without first making an attempt to understand its purpose.

The purpose of his resource manager is exactly the purpose of any other resource manager and is exactly what I thought it is. His way of doing it is stupid in my book but I stick to a purely technical discussion until somebody decides to make it personal.

Quote:

If the code does what it is intended to do, then it isn't really 'wrong' anyway.

By this logic, all code that works is equally good. This is not necessarily true in the long run.

This is very much like that sh*tstorm we had here a few months ago with the guy who decided that in his unique game, vectors are actually lines and vector operations need to be redefined for his special line-vectors. I told him what he did was stupid and he responded exactly the same way as OP did and the exact same people were there to criticize me. This place just reeks with crazy.

Karadoc ~~
Member #2,749
September 2002
avatar

Stas B. said:

His goals were obvious and he confirmed them to be the usual goals of a resource manager.

You say it's obvious, but apparently you still don't understand it.

Itachihro said:

All my SpriteManager is supposed to do is create valid sprites and ensure they and their copies are valid while in use (my implementation frees sprites the moment noone uses them anymore, but I could easily swap the implementation, for example to set a timeout before the sprites are released). That's all. The rest is handled by the classes using the SpriteManager.

So for example, maybe his game will have some graphics for the terrain or something, and maybe the main menu will use some of those same graphics, and maybe the next level will use some of those same graphics... and so on. With Itachihro's sprite manager, he can just request the spirits in the same way each time, and all these other classes which may or may not share graphics won't have to worry about when or how the spirits are actually loaded or destroyed - they'll just know that the sprites will be ready and valid when they need them. There doesn't need to be a separate copy of the sprite for each class that uses the sprite, and all of the tracking of which sprites are still needed and which are not needed is done by the shared_ptr.

Stas B. said:

Your resources die when the last shared_ptr pointing to them dies, since SpriteManager holds a weak_ptr internally. If, for instance, you have a few zombies in the level and they all die, their resources will be released. If later in the level you spawn some new zombies, the resources will be reloaded from disk. That's probably not a good thing.

Well something has to keep track of when to free the sprites. In Itachihro's system, each level tells the sprite manager which sprites the level needs, and the sprite manager is in charge of simply making sure those sprites get loaded. -- Maybe they are already loaded, maybe they aren't -- the sprite manager takes care of that, and the level doesn't have to worry about it.

In your example about not needing the zombie sprite for awhile, and then needing it again; when do you think the zombie sprites should be deleted? When the level ends? What if they're used again in the menus, or in the next level, or somewhere else? Who should decide when the sprite gets deleted?

Stas B. said:

By this logic, all code that works is equally good. This is not necessarily true in the long run.

By this logic my arse. Reread what I said again:

If the code does what it is intended to do, then it isn't really 'wrong' anyway. (It might not be ideal or efficient, but if it does its job correctly then it is not wrong...)

...

-----------

Ashteth
Member #3,310
March 2003
avatar

I also think that the use of shared pointers is excessive. The following is a counter example of how my non-trivial Allegro game manages shared resources. The scope of the game is such that I cannot afford to load all resources at once and that I cannot know which resources will need to be loaded until runtime.

You will note that my API doesn't attempt to prohibit the programmer from doing stupid things. If you're using C++, you can't possibly eliminate the opportunity to do stupid things. Instead be a smart programmer and know the meaning of the command you issue.

My game doesn't use a single smart pointer. I tend to use Hungarian notation to denote who is responsible for the pointer. A variable that starts with 'q' is a pointer that the owning class is responsible for deleting. A variable that starts with 'p' is a shallow pointer that can simply be discarded. Using this method combined with careful documentation, I no longer have a problem with pointers.

I don't really care if you use my example or your shared pointer method. Do whatever works for you. Just be sure you know what you're doing.

#SelectExpand
1// Bitmap resource manager class singleton. 2// There are also managers for sound and other resources. 3class a2dBmpM 4{ 5 // string / bitmap lookup table. 6 map<string, ALLEGRO_BITMAP*> m_qBitmap 7 8 // string / reference count lookup table. 9 map<string, int> m_refCount 10 11 // Free all resources no matter what. 12 void freeRes(void); 13 14 // Free bitmap with given unique identifier regardless of reference count. 15 void freeRes(const string&); 16 17 // Free all all resources that are no longer in use (decremented to zero). 18 void freeResDecremented(void); 19 20 // Bitmaps tend to be loaded elsewhere 21 // and assigned to the manager. 22 // In this way, subbitmaps and generated 23 // bitmaps can also be added. If no 24 // string identifier is passed, a unique string is generated. 25 void addBmp(ALLEGRO_BITMAP*, const string& = ""); 26 27 // Get bitmap by unique string identifier. 28 ALLEGRO_BITMAP* getBmp(const string&); 29}; 30 31// A base class for renderable scene objects. 32class a2dSceneObj 33{ 34 // All scene objects have a static trash class. 35 // The static trash class contains a list of all bitmaps, sounds 36 // and other resources the scene object is using. 37 static a2dTrash m_cTrash; 38 39 // When the static decrementRes() method on the scene object is called, 40 // it decrements the reference count of all the resources in the appropriate 41 // manager. 42 static void decrementRes(void); 43 44 // Free all resources this class is in use. If other classes are sharinng 45 // resources then that is their problem. 46 static void freeRes(void); 47};

Stas B.
Member #9,615
March 2008

So for example, maybe his game will have some graphics for the terrain or something, and maybe the main menu will use some of those same graphics, and maybe the next level will use some of those same graphics... and so on.

The shared_ptrs do nothing to help you avoid unnecessary reloading of resources. There's many different ways to solve this problem and none of them involve shared_ptrs. ::)

Quote:

Well something has to keep track of when to free the sprites.

The level should know nothing about what sprties entities need, but more importantly, the level knows nothing about whether the current sprites are needed in the next one. In OPs system, resources will be reloaded every time.

Quote:

when do you think the zombie sprites should be deleted? When the level ends? What if they're used again in the menus, or in the next level, or somewhere else? Who should decide when the sprite gets deleted?

When the programmer decides that it's time for the resource to die.

Thomas Fjellstrom
Member #476
June 2000
avatar

Stas B. said:

The level should know nothing about what sprties entities need, but more importantly, the level knows nothing about whether the current sprites are needed in the next one. In OPs system, resources will be reloaded every time.

Except that from what he said, it does the exact opposite. In fact, it keeps resources loaded from one level to the next that both levels share.

Quote:

When the programmer decides that it's time for the resource to die.

Then why bother with a resource manager at all?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Stas B.
Member #9,615
March 2008

Except that from what he said, it does the exact opposite. In fact, it keeps resources loaded from one level to the next that both levels share.

This pointless discussion has been dragging on for so long that I don't even remember how he was planning to achieve that. Simply having a bunch of shared_ptrs that get destroyed along with the level obviously won't cut it. It doesn't even matter. My original point was that there are simple ways to do that without using smart pointes and forcing levels to keep track of entity resources. ::)

Quote:

Then why bother with a resource manager at all?

Because resources aren't going to figure out for themselves when they're no longer needed. If you're going to use shared_ptr lists to control when resources are refreshed, you might as well just specify that explicitly with a function call.

Thomas Fjellstrom
Member #476
June 2000
avatar

Stas B. said:

you might as well just specify that explicitly with a function call.

So again, why bother with a resource manager and fancy classes at all? Just do manual memory management. That gives you ultimate control.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Stas B.
Member #9,615
March 2008

So again, why bother with a resource manager and fancy classes at all? Just do manual memory management. That gives you ultimate control.

Not sure if troll or just stupid. ???
Resource managers aren't magical. They don't know which resources will be needed in the future. You're going to have to control that somehow. The way OP chose to do it is with misplaced lists of shared_ptrs. Another way looks roughly like this:

#SelectExpand
1void onLevelLoad() 2{ 3 resourceManager.beginRefresh(); 4 5 for(each resource in map) 6 { 7 resourceManager.load(resource); 8 } 9 10 for(each entity in map) 11 { 12 create entity; // Entity does its own calls to resourceManager.load 13 } 14 15 resourecManger.endRefresh(); 16}

</code>

Itachihro
Member #12,001
May 2010

Stas B. said:

And I think, if you're going to call yourself a programmer, you might as well think about what you're doing and the about the purpose of the tools you're using instead of sticking to some silly "always do" or "never do" rules and doing things blindly. In this case, his plain and simple abuse of smart pointers lead to a ridiculous requirement for the clients of his class to store their own lists of shared_ptrs to make sure the resources don't die unexpectedly.

This is like the third time I told you that no shared_ptr is exposed by the interface. That's the whole reason the Sprite class exists. Now of course you need to keep the sprites alive. Which I am doing. Not by keeping a list of sprites btw. I still don't see why using a reference counting pointer class for... reference counting pointers is abuse. I also still don't quite understand exactly what your problem with using reference counting for resource management is - except that it does enforce a particular way to use these resources, which is true for any method - but I get the point that you think that's clearly evil. I don't. Not yet anyways, maybe when I'm done with this game I will think so too, but for now I will - I believe I said this earlier - continue working on this.

Stas B. said:

The level should know nothing about what sprties entities need, but more importantly, the level knows nothing about whether the current sprites are needed in the next one. In OPs system, resources will be reloaded every time.

Not if I am just loading the next level before destroying the previous one. At the present, it doesn't seem like any of my levels would require such an amount of resources that this would actually pose a problem. I'm actually thinking of keeping the previous 2-3 levels around in case the player returns to them.

Anyways, this thread has been derailed a long time (in internet time) ago. Let's stop here- I didn't think that a bit over 100 lines of code could be reason for such controversy.

Thomas Fjellstrom
Member #476
June 2000
avatar

Stas B. said:

Resource managers aren't magical. They don't know which resources will be needed in the future. You're going to have to control that somehow. The way OP chose to do it is with misplaced lists of shared_ptrs.

Again you're doing that whole "I'm right, you're wrong, and I'm smarter than everyone else" thing. It really makes it hard to take you seriously.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Stas B.
Member #9,615
March 2008

"I'm right, you're wrong, and I'm smarter than everyone else"

Yeah, well, and it ends up being true half of the time. :P
Not everything is a matter of opinion and not all opinions are equally valid.

Thomas Fjellstrom
Member #476
June 2000
avatar

Stas B. said:

Yeah, well, and it ends up being true half of the time.

::) Have you ever wondered why people don't like you?

Quote:

Not everything is a matter of opinion and not all opinions are equally valid.

In a lot of cases, like this one, it is.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Stas B.
Member #9,615
March 2008

Have you ever wondered why people don't like you?

Not really. ???

Quote:

In a lot of cases, like this one, it is.

No. I'm right. You're wrong. Trufax.

Thomas Fjellstrom
Member #476
June 2000
avatar

Ah good. So now you admit that no one need take you seriously anymore.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Stas B.
Member #9,615
March 2008

I don't care if you take me seriously. You guys are crazy. ???

Thomas Fjellstrom
Member #476
June 2000
avatar

Heh. I'm not talking about myself. I stopped taking anything you said seriously after your first couple of posts. I mean the rest of the people here. surely you don't mean that everyone here is crazy.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

 1   2   3   4 


Go to: