Jump to content
  • Advertisement

CableGuy

Member
  • Content count

    533
  • Joined

  • Last visited

Community Reputation

1335 Excellent

About CableGuy

  • Rank
    Advanced Member

Personal Information

  • Role
    Programmer
  • Interests
    Programming
  1. CableGuy

    Personal Update

    Glad you are feeling better and hope to read your posts sooner than later
  2. I have a question regarding the implementation of AbstractDelegate. AbstractDelegate has a member called v which is a vector of events but to me it seems the vector would always be of size 1 (or 0) because for each new connection the Delegate class creates a new instance of ConcreteDelegate. So is there actually a reason to store a vector of events in AbstractDelegate or am I missing something?   Thanks.   BTW, Great article.
  3. CableGuy

    Memory management of resources

    @haegarr I think your concept of a resource pool is too much for my needs. It seems to me that the resource pool purpose is to reduce the dynamic allocations using new / delete but for now that isn't an issue. And besides, even when using the resource pool I'll still have to manage the memory manually but instead of calling delete on the pointer, I will need to tell the resource pool that the memory is not used anymore.   I'm considering going with an intrusive reference counting approach. It seems to me to have the most convenient usage with not too much overhead...
  4. CableGuy

    Memory management of resources

    Thank you guys for the responses   @imoogiBG - If I understand you correctly, you are basically using intrusive reference counting inside your resource classes?   @haegarr: I agree with the sole responsibility principle but I still can't see how you would solve the problem I described. Given a resource that wasn't loaded using the resource loader but was manually created how would you go about and manage its memory? or are you saying that every memory allocation would go through the resource pool?
  5. Hi,   I know this question had probably been asked a few times and I did search the forums but couldn't find what I'm after.   My question concerns memory allocation (of resources in a game) and how to avoid having to manage them manually.   At first, my little game framework had (almost) everything wrapped in std::shared_ptr.  I think this has impacted performance (AFAIR I did profile it) and also leads to bad design. Recently I removed every use of std::shared_ptr in favor of raw pointers and started to actually think about ownership of memory to define who has the responsibility to free the resources. I have a class called ResourcePool which given a type of a resource, it allocated it and is the owner of the resource and therefore responsible to free its memory. But what if for instance, I would like to clone a resource (because I'm going to change it and don't want everything which uses this resource to be affected).  The cloned resource wasn't created using the ResourcePool (The resource pool can create resource only from files) and therefore won't be freed by it which leaves the responsibility to the user. I can think of three solutions to the problem: 1. Use shared_ptr (or probably my own intrusive reference counting) but that's what I was try to avoid in the first place. 2. Leave it to the user, but in the long run is cumbersome and would cause memory leaks if not carefully taken care of 3. Add the resource to the ResourcePool (or other class) which will become the owner of the resource and therefore will free it.   I hope I was clear enough and would like to hear what other designs have you guys used to avoid having to manually manage memory in your game   Thanks
  6. Can't you initialize your Lua states before hand and store them in an array, one for each thread? Also you might want to look here, some of the libraries allow concurrent execution of Lua code
  7. CableGuy

    Profile

  8. CableGuy

    Video!

    Nice, really liked the retro art style.
  • 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!