Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualMarkS

Posted 25 December 2012 - 03:38 PM

Why do the textures need to be in a manager?

Because most tile-based games use a small subset of textures, but those textures are drawn hundreds of times per level. If I load the same texture for each tile that needs it, the memory demands of this engine will be astronomical. By putting the resources in a manager, only one instance of a texture is loaded and it can then be accessed by any tile and/or sprite that needs it.

 

 

Don't pass the "managers", pass the constructed objects. A tile isn't aware of managers, just construct the tile with the appropriate texture and/or shader. It can pass these to any inner objects that store them.
 
Another way is to avoid storing these on a per tile basis. A tile might have a reference to a "tile type", which might contain information about whether the tile is passable, etc. You can store the graphical representation of the tile here too. Note that mixing your rendering objects into your game objects can complicate some designs (though it can simplify some games too, YMMV).
 
A final note, prefer values to pointers, and prefer smart pointers to raw pointers.
 
I'm using boost's smart_ptr. I just didn't want to write "boost::smart_ptr" over and over in the example.
 
If I pass the constructed object, wouldn't that defeat the purpose of having a resource manager? I could just as easily load the texture and shader each time I load a mesh, but the point is to reduce or eliminate redundant resource allocation.
 
Also, I am not storing the resources on a per tile basis. The resources are stored in the lowest level class, tile_level, as resource pools and accessed by the higher-level classes. Maybe I am misunderstanding you?

#3MarkS

Posted 25 December 2012 - 03:36 PM

Why do the textures need to be in a manager?

Because most tile-based games use a small subset of textures, but those textures are drawn hundreds of times per level. If I load the same texture for each tile that needs it, the memory demands of this engine will be astronomical. By putting the resources in a manager, only one instance of a texture is loaded and it can then be accessed by any tile and/or sprite that needs it.

 

 

Don't pass the "managers", pass the constructed objects. A tile isn't aware of managers, just construct the tile with the appropriate texture and/or shader. It can pass these to any inner objects that store them.
 
Another way is to avoid storing these on a per tile basis. A tile might have a reference to a "tile type", which might contain information about whether the tile is passable, etc. You can store the graphical representation of the tile here too. Note that mixing your rendering objects into your game objects can complicate some designs (though it can simplify some games too, YMMV).
 
A final note, prefer values to pointers, and prefer smart pointers to raw pointers.
 
I'm using boost's smart_ptr. I just didn't want to write "boost::smart_ptr" over and over in the example.
 
If I pass the constructed object, wouldn't that defeat the purpose of having a resource manager? I could just as easily load the texture and shader each time I load a mesh, but the point is to reduce or eliminate redundant resource allocation.
 
Also, I am not storing the resources on a per tile basis. The resources are stored lowest level class, tile_level, as resource pools and accessed by the higher-level classes. Maybe I am misunderstanding you?

#2MarkS

Posted 25 December 2012 - 03:36 PM

Why do the textures need to be in a manager?

Because most tile-based games use a small subset of textures, but those textures are drawn hundreds of times per level. If I load the same texture for each tile that needs it, the memory demands of this engine will be astronomical. By putting the resources in a manager, only one instance of a texture is loaded and it can then be accessed by any tile and/or sprite that needs it.

 

 

Don't pass the "managers", pass the constructed objects. A tile isn't aware of managers, just construct the tile with the appropriate texture and/or shader. It can pass these to any inner objects that store them.
 
Another way is to avoid storing these on a per tile basis. A tile might have a reference to a "tile type", which might contain information about whether the tile is passable, etc. You can store the graphical representation of the tile here too. Note that mixing your rendering objects into your game objects can complicate some designs (though it can simplify some games too, YMMV).
 
A final note, prefer values to pointers, and prefer smart pointers to raw pointers.

 
I'm using boost's smart_ptr. I just didn't want to write "boost::smart_ptr" over and over in the example.
 
If I pass the constructed object, wouldn't that defeat the purpose of having a resource manager? I could just as easily load the texture and shader each time I load a mesh, but the point is to reduce or eliminate redundant resource allocation.
 
Also, I am not storing the resources on a per tile basis. The resources are stored lowest level class, tile_level, as resource pools and accessed by the higher-level classes. Maybe I am misunderstanding you?

#1MarkS

Posted 25 December 2012 - 03:30 PM

Why do the textures need to be in a manager?

Because most tile-based games use a small subset of textures, but those textures are drawn hundreds of times per level. If I load the same texture for each tile that needs it, the memory demands of this engine will be astronomical. By putting the resources in a manager, only one instance of a texture is loaded and it can then be accessed by any tile and/or sprite that needs it.


PARTNERS