Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


irbaboon

Member Since 07 Oct 2011
Offline Last Active Mar 30 2015 11:44 AM

Posts I've Made

In Topic: Game programming is hard

12 March 2015 - 06:42 PM

life advice by frob

 

Sadly posts cannot be upvoted here, but here you go: +1 

 

It's always nice when someone makes a lengthy post about an interesting subject.


In Topic: Obligatory first post

09 March 2015 - 07:01 AM

I don't understand. 7+ years and you haven't really done anything?

Well, to be fair, I've seen worse... http://www.gamedev.net/user/56140-phil67rpg/

 

Welcome to the forums though, I'm not here to be rude. :)


In Topic: Resource Manager Design

21 January 2015 - 05:03 AM

-snip-

 

Thanks a lot for your explanation! It really cleared up a lot of confusion.

I'll definitely start applying this in my library. Seems like it'll clean up quite a bit.

 

Thanks for actually writing such a long post to explain it to me. :)


In Topic: Resource Manager Design

21 January 2015 - 04:40 AM

 


Nono, I don't store the frames parameter in Resource.

This map is defined in Resource:

std::map m_parameters;

Then each class that derive from Resource, needs to implement an initialise() function which has to at least do one thing to work with the ResourceManager: set the "class" to the class name. Read my other reply again.



Either way; I disagree that it's wasteful, because it's not like you'll have thousands of resources loaded at once. Even then, it's not that bad. We're talking some kilobytes in total.

I'll agree there probably is a better way to do it though.

 

Ok, replying to this goes somewhat off topic, but this is very timely for me.

 

So you do store the parameters as name-value pairs like I suggested. It's a map. I guess that the Parameter class stores some union of admissible parameter types? Anyway, if you don't cache the values to some C++ types, each time you request a parameter from a resource you will need to make O(logN) lookup of the map, performing string comparisons. This may be neglible in some simple 2D game with a few resources, but I would not use it for rendering complex 3D scenes with hundreds of resources (with multitude of parameters) accessed each frame.

 

Storing the names may not take more than a few kilobytes, but usually such degeneracy suggests that the design could be improved.

 

 

These parameters aren't really meant to be accessed every frame though. It's mostly just to help build up the object.

I agree there are better ways though.


In Topic: Resource Manager Design

20 January 2015 - 04:29 PM

 


Is there anything with this design that could really make things break later on?

I hear so much bad about going this way, but I feel it's just perfect.

 

If I understand correctly, the resources derive from a base class that stores parameters as some name-value pairs.

 

I have also been thinking a lot how to associate parameters with resources so that they could be easily read from/written to files and perhaps used to automatically generate in-game menus for editing. However, storing the name literals is wasteful. For example, probably most "sprites" contain "frames" parameter. Each resource then stores this same literal for nothing. Also, searching parameters by name is slow, so the values should be cached in actual variables for run-time use.

 

Nono, I don't store the frames parameter in Resource.

This map is defined in Resource: 

std::map<std::string, Parameter> m_parameters;

Then each class that derive from Resource, needs to implement an initialise() function which has to at least do one thing to work with the ResourceManager: set the "class" to the class name. Read my other reply again.

 

Either way; I disagree that it's wasteful, because it's not like you'll have thousands of resources loaded at once. Even then, it's not that bad. We're talking some kilobytes in total.

I'll agree there probably is a better way to do it though.

 

 

 


I know this is controversial, but to be honest, that just makes it a lot more complicated than it needs to be.
It is probably because I'm still a novice, but I just feel adding tons of small classes do nothing more than make everything messy.

 

[...]

 
Sorry for being stubborn, but I need some serious convincing to see the faults of this.

The Sprite class, as an example, defines how a sprite is represented when being loaded into working memory, i.e. it manages sprite typical data for runtime purposes. So far so good. Now you add the possibility to load the data from a XML fragment, so that the Sprite class can construct its own instances. Okay, but we need to generate Sprite instances at runtime as well, so give it another factory method for this, too. If I have that, I could generate sprites by code and save them for later reload, so having a save method would be nice. Well, I want to support reading from and writing to files, but reading from and writing to memory would make networking more convenient, so methods for that are fine as well. Hmm, now that levels get bigger, I want to support binary data files as well as XML files. Oh wait, now that my Sprite class has this new fantastic feature, but existing files have not, I need to support a second generation of routines, and, since I want to support older engines, perhaps also saving routines. Now just putting in the render routines for OpenGL 3 for older machines and those for OpenGL 4 would complete it mostly. Support for mouse picking, because of the editor I'm planning, is a must of course. A bit of collision detection, and ...

 

Although exaggerated, the story above is what happens in reality. To defeat this from the very beginning, the single responsibility principle was defined. Sure, at the moment you say "I have only 3 responsibilities in my manager class, that is still maintainable", and you're right. However, this changes with time, and it always changes in the wrong direction if you not defeat it explicitly.

 

Notice that this does not mean that there is not something like a manager. However, such a manager would be a facade class, where clients find a concentrated API, but the work is done behind the facade by dedicated objects then, just controlled by the manager.

 

In the end, SRP simplifies the ability to exchange parts (for example the implementation of the resource cache), and to develop and test aspects separated (for example the versioning of resources on mass storage), and to still understand a piece of software after half a year or when being developed by another person, and to re-use it in another context as well. Its advantage is found in the mid to long run.

 

 

This is probably going to sound stupid, but I'm going to ask specific questions so I can get some confusion cleared up:

 

1. Are you saying the ResourceManager should call a ResourceLoader? If so, is ResourceLoader split into "XMLResourceLoader" and "BinaryResourceLoader"?

Again; if so, why not just have a "loadXML()" and "loadBinary()" functions inside ResourceLoader? Is that what the bad thing is?

 

2. Should ResourceManager have all the ResourceContainers (which then contain Resource objects)?

Should ResourceManager even call ResourceLoader?

 

3. Do you mean that the Sprite class should not have functions to write/read buffers? If so, do you mean there should be a SpriteSerializer class?

 

Also, this post was a bit longer, but I realised at least one of your points while writing it. I'm still curious what your reply is though.


PARTNERS