[hlcoders] Animated Decals on Models
Hello, I have been trying to add a custom impact effect that replaces the blood decals when players are shot while they have a shield. I got it to apply the animated decal to the model fine, however there seems to be no way to only have the decal play its animation once and then die. I have tried writing a new material proxy based on the AnimatedTexture proxy, but ran into a lot of problems. First of all, there seems to be no way to remove a single decal on a model after a certain amount of time, from the proxy or otherwise. This led me to try adding a timer and various other ways of detecting whether the animation has played once, but it appears that a single proxy class is used for all materials set to use that proxy. That means that any class member variables to keep track of whether the animation has completed apply to all of the decals created in the future as well, preventing them from showing at all. The ideal solution would be a way to remove the decal from the model after it's finished with its animation, but even a way to hide it until it gets removed by the model decal limit would be sufficient. I've run out of ideas except for using a quad effect instead, but that doesn't look nearly as good. Thanks for any help, Jory _ Watch “Cause Effect,” a show about real people making a real difference. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Why doesn't Valve use the STL, anyways? I've always wondered. I really like the STL (and Boost). Is there some important consideration I missed about their usage with the Source SDK? Regards, Paul On Jan 11, 2008 3:07 PM, Yahn Bernier <[EMAIL PROTECTED]> wrote: > If the element type is a pointer: > > CUtlVector< CMyClass * > vecStuff; > > Then the underlying object will not be destructed, just the slot holding > the ptr. > > If you do: > > CUtlVector< CMyClass > vecStuff; > > Then the object gets desctructed (but you also have to worry about > implementing a copy constructor or operator =, etc. etc.) > > Safest thing in the CUtlVector< CMyClass * > case is to loop through the > objects and call delete on each entry, and then call Purge/RemoveAll to > free the memory used for the raw pointers. > > ~CUtlVector will automatically clean up the ptrs, but if you don't > delete the objects in the CUtlVector< CMyClass * > case then you'll have > a leak. > > Yahn > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > Schedel > Sent: Friday, January 11, 2008 11:50 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > Why you don't look at the code itself? In "Remove" you can see the > element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that > point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using > up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, > won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] I could be reading this wrong, but with this *The pointers for this constructor are retrieved from a class called CItemData which loads all items from a data file into a CUtlVector before the call to new CInvItem. The CInventory destructor calls delete on all m_vItems elements, before emptying the *are you saying that 2 vectors both share pointers to the same objects? J * vector. The CItemData destructor does the same for its vector of CItem*.* On Jan 11, 2008 1:55 PM, Minh <[EMAIL PROTECTED]> wrote: > ooh.. someone just got ownucted. > > just kidding :) > > - Original Message - > From: "Yahn Bernier" <[EMAIL PROTECTED]> > To: > Sent: Friday, January 11, 2008 1:26 PM > Subject: RE: [hlcoders] CUtlVector<*>... Memory management? > > > > Well, when talking about a "destructor" the colloquial term is > > "destructed". > > > > YMMV. > > > > Yahn > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Jed > > Sent: Friday, January 11, 2008 1:03 PM > > To: hlcoders@list.valvesoftware.com > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > [pendantic englishman] > > > > *eye twitch* - its "destroyed" not "destructed". > > > > [/pendantic englishman] > > > > On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: > >> If the element type is a pointer: > >> > >> CUtlVector< CMyClass * > vecStuff; > >> > >> Then the underlying object will not be destructed, just the slot > > holding > >> the ptr. > >> > >> If you do: > >> > >> CUtlVector< CMyClass > vecStuff; > >> > >> Then the object gets desctructed (but you also have to worry about > >> implementing a copy constructor or operator =, etc. etc.) > >> > >> Safest thing in the CUtlVector< CMyClass * > case is to loop through > > the > >> objects and call delete on each entry, and then call Purge/RemoveAll > > to > >> free the memory used for the raw pointers. > >> > >> ~CUtlVector will automatically clean up the ptrs, but if you don't > >> delete the objects in the CUtlVector< CMyClass * > case then you'll > > have > >> a leak. > >> > >> Yahn > >> > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > >> Schedel > >> Sent: Friday, January 11, 2008 11:50 AM > >> To: hlcoders@list.valvesoftware.com > >> Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > >> > >> Why you don't look at the code itself? In "Remove" you can see the > >> element > >> will be destroyed by the Destruct function. The Destruct function > > calls > >> the > >> Destructor of the element. > >> > >> Best regards > >> > >> Ronny Schedel > >> > >> > >> > -- > >> > [ Picked text/plain from multipart/alternative ] > >> > Am I right in assuming that if you have a vector of pointers, that > >> point > >> > to > >> > things you create with "new", you have to either call delete on each > >> > element > >> > or use PurgeAndDeleteElements()? Because that's what I've been using > >> up > >> > until recently, where it seems that trying to delete elements from a > >> > pointer > >> > vector on destruction of whatever they are members of just causes > > the > >> game > >> > to crash with a memory error. Removing the calls to delete stop the > >> crash, > >> > but unless CUtlVector automatically cleans up your memory for you, > >> won't > >> > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > >> > didn't > >> > magically look after your memory for you... was I wrong? > >> > > >> > J > >> > -- > >> > > >> > ___ > >> > To unsubscribe, edit your list preferences, or view the list > > archives, > >> > please visit: > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > > >> > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list a
Re: [hlcoders] CUtlVector<*>... Memory management?
Hi, The problem could be, that you are copying the vector directly with the pointers . e.g. *) you are copying the vector -> the pointers will be copied and not the object of your class. *) you are deleting one of the 2 vector instances -> memory will be freed -> everything is fine... atleast for now *) you are deleting the 2nd vector -> the pointers are pointing to an address that is not available anymore -> big MessageBox with errors/CRASH Heimo Jamie Femia schrieb: -- [ Picked text/plain from multipart/alternative ] That's what I thought... in that case I need to figure out why calling delete vector[element] crashes my mod! On Jan 11, 2008 8:07 PM, Yahn Bernier <[EMAIL PROTECTED]> wrote: If the element type is a pointer: CUtlVector< CMyClass * > vecStuff; Then the underlying object will not be destructed, just the slot holding the ptr. If you do: CUtlVector< CMyClass > vecStuff; Then the object gets desctructed (but you also have to worry about implementing a copy constructor or operator =, etc. etc.) Safest thing in the CUtlVector< CMyClass * > case is to loop through the objects and call delete on each entry, and then call Purge/RemoveAll to free the memory used for the raw pointers. ~CUtlVector will automatically clean up the ptrs, but if you don't delete the objects in the CUtlVector< CMyClass * > case then you'll have a leak. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronny Schedel Sent: Friday, January 11, 2008 11:50 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel -- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer vector on destruction of whatever they are members of just causes the game to crash with a memory error. Removing the calls to delete stop the crash, but unless CUtlVector automatically cleans up your memory for you, won't this just create MASSIVE memory leaks? As far as I knew, CUtlVector didn't magically look after your memory for you... was I wrong? J -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
ooh.. someone just got ownucted. just kidding :) - Original Message - From: "Yahn Bernier" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 1:26 PM Subject: RE: [hlcoders] CUtlVector<*>... Memory management? Well, when talking about a "destructor" the colloquial term is "destructed". YMMV. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Friday, January 11, 2008 1:03 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? [pendantic englishman] *eye twitch* - its "destroyed" not "destructed". [/pendantic englishman] On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: If the element type is a pointer: CUtlVector< CMyClass * > vecStuff; Then the underlying object will not be destructed, just the slot holding the ptr. If you do: CUtlVector< CMyClass > vecStuff; Then the object gets desctructed (but you also have to worry about implementing a copy constructor or operator =, etc. etc.) Safest thing in the CUtlVector< CMyClass * > case is to loop through the objects and call delete on each entry, and then call Purge/RemoveAll to free the memory used for the raw pointers. ~CUtlVector will automatically clean up the ptrs, but if you don't delete the objects in the CUtlVector< CMyClass * > case then you'll have a leak. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronny Schedel Sent: Friday, January 11, 2008 11:50 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel > -- > [ Picked text/plain from multipart/alternative ] > Am I right in assuming that if you have a vector of pointers, that point > to > things you create with "new", you have to either call delete on each > element > or use PurgeAndDeleteElements()? Because that's what I've been using up > until recently, where it seems that trying to delete elements from a > pointer > vector on destruction of whatever they are members of just causes the game > to crash with a memory error. Removing the calls to delete stop the crash, > but unless CUtlVector automatically cleans up your memory for you, won't > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > didn't > magically look after your memory for you... was I wrong? > > J > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] CUtlVector<*>... Memory management?
Well, when talking about a "destructor" the colloquial term is "destructed". YMMV. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Friday, January 11, 2008 1:03 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? [pendantic englishman] *eye twitch* - its "destroyed" not "destructed". [/pendantic englishman] On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: > If the element type is a pointer: > > CUtlVector< CMyClass * > vecStuff; > > Then the underlying object will not be destructed, just the slot holding > the ptr. > > If you do: > > CUtlVector< CMyClass > vecStuff; > > Then the object gets desctructed (but you also have to worry about > implementing a copy constructor or operator =, etc. etc.) > > Safest thing in the CUtlVector< CMyClass * > case is to loop through the > objects and call delete on each entry, and then call Purge/RemoveAll to > free the memory used for the raw pointers. > > ~CUtlVector will automatically clean up the ptrs, but if you don't > delete the objects in the CUtlVector< CMyClass * > case then you'll have > a leak. > > Yahn > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > Schedel > Sent: Friday, January 11, 2008 11:50 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > Why you don't look at the code itself? In "Remove" you can see the > element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that > point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using > up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, > won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] I can't really give a code snippet because for it to be in any kind of context you would need to see quite a bit of it. I will try and simplify it: I have a class, CItem. This class contains char arrays, integers, etc, etc holding data about a specific item.. the contents aren't that important - at no point anywhere in this class do i create any memory with new or malloc. I then have another class, CInvItem, which consists of three CItem pointers (because in this system items are combined with others randomly to generate a large armount of different items). Three CItem pointers are passed on construction, and copied to the member pointer variables. In the destructor I have delete calls for all three pointers. Then I have my CInventory class. Among other things, this contains a CUtlVector m_vItems. In the CInventory constructor I add a specific number of "slots" to the vector using AddToTail( NULL ). Any items added to the inventory by other functions use m_vItems[slot] = new CInvItem( CItem*, CItem*, CItem* ). The pointers for this constructor are retrieved from a class called CItemData which loads all items from a data file into a CUtlVector before the call to new CInvItem. The CInventory destructor calls delete on all m_vItems elements, before emptying the vector. The CItemData destructor does the same for its vector of CItem*. Now this crash only occurs when I have an item in the inventory.. and only when I load a new map using "map mapname". Using engine->ChangeLevel from within the code (related to a logical entity I have created) does not crash the game. I'm quite puzzled as to why it only crashes when I manually change the map in the console, but when I do it gives me the nice memory error popup saying that location "x" could not be "read". On 1/11/08, Ronny Schedel <[EMAIL PROTECTED]> wrote: > > > Give me some code snippet to understand clearly your problem. Don't forget > declarations, etc. Just some short code which will crash (create one > element, add to vector, remove element from vector). > > > > > -- > > [ Picked text/plain from multipart/alternative ] > > That's what I thought... in that case I need to figure out why calling > > delete vector[element] crashes my mod! > > > > On Jan 11, 2008 8:07 PM, Yahn Bernier <[EMAIL PROTECTED]> > > wrote: > > > >> If the element type is a pointer: > >> > >> CUtlVector< CMyClass * > vecStuff; > >> > >> Then the underlying object will not be destructed, just the slot > holding > >> the ptr. > >> > >> If you do: > >> > >> CUtlVector< CMyClass > vecStuff; > >> > >> Then the object gets desctructed (but you also have to worry about > >> implementing a copy constructor or operator =, etc. etc.) > >> > >> Safest thing in the CUtlVector< CMyClass * > case is to loop through > the > >> objects and call delete on each entry, and then call Purge/RemoveAll to > >> free the memory used for the raw pointers. > >> > >> ~CUtlVector will automatically clean up the ptrs, but if you don't > >> delete the objects in the CUtlVector< CMyClass * > case then you'll > have > >> a leak. > >> > >> Yahn > >> > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > >> Schedel > >> Sent: Friday, January 11, 2008 11:50 AM > >> To: hlcoders@list.valvesoftware.com > >> Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > >> > >> Why you don't look at the code itself? In "Remove" you can see the > >> element > >> will be destroyed by the Destruct function. The Destruct function calls > >> the > >> Destructor of the element. > >> > >> Best regards > >> > >> Ronny Schedel > >> > >> > >> > -- > >> > [ Picked text/plain from multipart/alternative ] > >> > Am I right in assuming that if you have a vector of pointers, that > >> point > >> > to > >> > things you create with "new", you have to either call delete on each > >> > element > >> > or use PurgeAndDeleteElements()? Because that's what I've been using > >> up > >> > until recently, where it seems that trying to delete elements from a > >> > pointer > >> > vector on destruction of whatever they are members of just causes the > >> game > >> > to crash with a memory error. Removing the calls to delete stop the > >> crash, > >> > but unless CUtlVector automatically cleans up your memory for you, > >> won't > >> > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > >> > didn't > >> > magically look after your memory for you... was I wrong? > >> > > >> > J > >> > -- > >> > > >> > ___ > >> > To unsubscribe, edit your list preferences, or view the list > archives, > >> > please visit: > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > > >> > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listin
Re: [hlcoders] CUtlVector<*>... Memory management?
[pendantic englishman] *eye twitch* - its "destroyed" not "destructed". [/pendantic englishman] On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: > If the element type is a pointer: > > CUtlVector< CMyClass * > vecStuff; > > Then the underlying object will not be destructed, just the slot holding > the ptr. > > If you do: > > CUtlVector< CMyClass > vecStuff; > > Then the object gets desctructed (but you also have to worry about > implementing a copy constructor or operator =, etc. etc.) > > Safest thing in the CUtlVector< CMyClass * > case is to loop through the > objects and call delete on each entry, and then call Purge/RemoveAll to > free the memory used for the raw pointers. > > ~CUtlVector will automatically clean up the ptrs, but if you don't > delete the objects in the CUtlVector< CMyClass * > case then you'll have > a leak. > > Yahn > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > Schedel > Sent: Friday, January 11, 2008 11:50 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > Why you don't look at the code itself? In "Remove" you can see the > element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that > point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using > up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, > won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Give me some code snippet to understand clearly your problem. Don't forget declarations, etc. Just some short code which will crash (create one element, add to vector, remove element from vector). -- [ Picked text/plain from multipart/alternative ] That's what I thought... in that case I need to figure out why calling delete vector[element] crashes my mod! On Jan 11, 2008 8:07 PM, Yahn Bernier <[EMAIL PROTECTED]> wrote: If the element type is a pointer: CUtlVector< CMyClass * > vecStuff; Then the underlying object will not be destructed, just the slot holding the ptr. If you do: CUtlVector< CMyClass > vecStuff; Then the object gets desctructed (but you also have to worry about implementing a copy constructor or operator =, etc. etc.) Safest thing in the CUtlVector< CMyClass * > case is to loop through the objects and call delete on each entry, and then call Purge/RemoveAll to free the memory used for the raw pointers. ~CUtlVector will automatically clean up the ptrs, but if you don't delete the objects in the CUtlVector< CMyClass * > case then you'll have a leak. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronny Schedel Sent: Friday, January 11, 2008 11:50 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel > -- > [ Picked text/plain from multipart/alternative ] > Am I right in assuming that if you have a vector of pointers, that point > to > things you create with "new", you have to either call delete on each > element > or use PurgeAndDeleteElements()? Because that's what I've been using up > until recently, where it seems that trying to delete elements from a > pointer > vector on destruction of whatever they are members of just causes the game > to crash with a memory error. Removing the calls to delete stop the crash, > but unless CUtlVector automatically cleans up your memory for you, won't > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > didn't > magically look after your memory for you... was I wrong? > > J > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
The murderous Memory Man is officially called STATUS_NO_MEMORY (cf. ntstatus.h), but other than that, I guess Counter-Strike taught you a lot about the internals of Windows. ;-) When a process is terminated, the Windows kernel, at least since NT 3.51, frees any and all memory belonging to the process. (Unix does that too.) However, this is often too late -- depending on how long the game runs. Suppose I load a map. My ultra-awesome constructor for some sort of in-game class creates a pointer to an overly large class for optimized resource management. During the course of this map, these special resources get loaded by this resource manager, taking up memory. Now, suppose I change maps. My stupid destructor for that in-game class forgets to free the resource manager, which, in turn, doesn't free all the resources (because it was never told to do so). If my special resources are something akin to id's MegaTextures, the application will eventually -- third map the latest -- run out of memory and the Memory Man will ring my doorbell and try to rape me with a crowbar. There is a big philosophical difference between the heap and the stack: when a stack variable goes out of scope, it is destroyed (and the memory it occupied is freed), whilst a heap variable never goes out of scope. This is pretty sweet for global objects, externally serialized objects and the victims of pointer arithmetic fetishists, but it is always considered good practice to, when the item is not needed anymore, bolt the variable -- new'd variables with delete, malloc'd variables with free. If I do this right, I never waste memory. In practice, with all the pointer passing in a game engine, it is much more troublesome, but anytime memory can be freed, it should be freed. ... unless you want the server admins to do what the Memory Man is said to do. That's a group of people aiming for lots of uptime. (D'oh! In the mean time, Jed has given a shorter description of memory handling and Yahn chimed in to inform everybody of the engine's behavior. I guess I'll send this anyway as a dire warning.) ~~ Ondra P.S. In case you're wondering, yes, this post is 99% hyperbole. Oh, there it is again. On 11.01.08 20:08 Uhr, Minh wrote: -- [ Picked text/plain from multipart/alternative ] What happens if you don't properly release the memory? Will the Memory Man come to your house and beat you to death? If the app is running under Windows and windows knows how much memory is being allocated, then couldn't we just rely on windows to take care of the memory deallocation process? Or perhaps, we don't trust Windows - Original Message - From: "Jed" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 10:58 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Well its C++ so I always thought it was a case that you *have* to properly release any memory you allocate. I usually stick a debug header at the top of all my code files so if theres any memory leaks it'll tell me where they are when the program exits. - Jed On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] That's what I'd like to know.. I'm not totally convinced that it's safe to just leave stuff in the memory.. perhaps a member of Valve staff can confirm? On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] hmm.. I've gotten way with just calling RemoveAll() on my CUTLVectors. Then when I add new elements, I believe it just overtakes the existing memory addresses of these previous elements that were in the vector. Mind you, my utlvectors typically never grow to be more than 20 elements. When Half-Life2 shuts down, does all of the memory allocations that were created during the game get deallocated automatically, so other programs can use them? - Original Message - From: "Jamie Femia" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 9:55 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? -- [ Picked text/plain from multipart/alternative ] Then why is it that when I try and delete the elements it crashes the game? lol... On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] you have to delete what you add. purging just removes the elements. On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer vector on destruction of whatever they are members of just causes the game to crash with a memory error. Removing the calls to delete stop the crash, but unless CUtlVector automatica
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] That's what I thought... in that case I need to figure out why calling delete vector[element] crashes my mod! On Jan 11, 2008 8:07 PM, Yahn Bernier <[EMAIL PROTECTED]> wrote: > If the element type is a pointer: > > CUtlVector< CMyClass * > vecStuff; > > Then the underlying object will not be destructed, just the slot holding > the ptr. > > If you do: > > CUtlVector< CMyClass > vecStuff; > > Then the object gets desctructed (but you also have to worry about > implementing a copy constructor or operator =, etc. etc.) > > Safest thing in the CUtlVector< CMyClass * > case is to loop through the > objects and call delete on each entry, and then call Purge/RemoveAll to > free the memory used for the raw pointers. > > ~CUtlVector will automatically clean up the ptrs, but if you don't > delete the objects in the CUtlVector< CMyClass * > case then you'll have > a leak. > > Yahn > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > Schedel > Sent: Friday, January 11, 2008 11:50 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > Why you don't look at the code itself? In "Remove" you can see the > element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that > point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using > up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, > won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] CUtlVector<*>... Memory management?
If the element type is a pointer: CUtlVector< CMyClass * > vecStuff; Then the underlying object will not be destructed, just the slot holding the ptr. If you do: CUtlVector< CMyClass > vecStuff; Then the object gets desctructed (but you also have to worry about implementing a copy constructor or operator =, etc. etc.) Safest thing in the CUtlVector< CMyClass * > case is to loop through the objects and call delete on each entry, and then call Purge/RemoveAll to free the memory used for the raw pointers. ~CUtlVector will automatically clean up the ptrs, but if you don't delete the objects in the CUtlVector< CMyClass * > case then you'll have a leak. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronny Schedel Sent: Friday, January 11, 2008 11:50 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel > -- > [ Picked text/plain from multipart/alternative ] > Am I right in assuming that if you have a vector of pointers, that point > to > things you create with "new", you have to either call delete on each > element > or use PurgeAndDeleteElements()? Because that's what I've been using up > until recently, where it seems that trying to delete elements from a > pointer > vector on destruction of whatever they are members of just causes the game > to crash with a memory error. Removing the calls to delete stop the crash, > but unless CUtlVector automatically cleans up your memory for you, won't > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > didn't > magically look after your memory for you... was I wrong? > > J > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Thanks for the input everyone, very helpful :) On 1/11/08, Ronny Schedel <[EMAIL PROTECTED]> wrote: > > Why you don't look at the code itself? In "Remove" you can see the element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Which is especially true for the server side of your game/mod. It's likely to be running constantly for days/weeks/months even a year and if you allocate and never release your memory your going to end up slowing and eventually crashing the server. The "let windows deal with it approach" is just plain bad programming practice. - Jed On 11/01/2008, Tom Leighton <[EMAIL PROTECTED]> wrote: > Newer versions of windows do, im sure that Windows 9x had memory issues > where it was ESSENTIAL you free'd memory you allocated. However, now > windows manages each apps memory (Virtual Memory Addressing), and it > will free any memory you allocated but didn't delete. > > The reason you should still use delete is that your program will start > to become slow/sluggish, etc. Performance reasons. > > Jed wrote: > > Well its C++ so I always thought it was a case that you *have* to > > properly release any memory you allocate. I usually stick a debug > > header at the top of all my code files so if theres any memory leaks > > it'll tell me where they are when the program exits. > > > > - Jed > > > > On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: > > > >> -- > >> [ Picked text/plain from multipart/alternative ] > >> That's what I'd like to know.. I'm not totally convinced that it's safe to > >> just leave stuff in the memory.. perhaps a member of Valve staff can > >> confirm? > >> > >> On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > >> > >> > >>> -- > >>> [ Picked text/plain from multipart/alternative ] > >>> hmm.. I've gotten way with just calling > >>> RemoveAll() on my CUTLVectors. > >>> Then when I add new elements, I believe it just overtakes the existing > >>> memory addresses of these previous elements that were in the vector. Mind > >>> you, my utlvectors typically never grow to be more than 20 elements. > >>> > >>> When Half-Life2 shuts down, does all of the memory allocations that were > >>> created during the game get deallocated automatically, so other programs > >>> can > >>> use them? > >>> > >>> > >>> - Original Message - > >>> From: "Jamie Femia" <[EMAIL PROTECTED]> > >>> To: > >>> Sent: Friday, January 11, 2008 9:55 AM > >>> Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > >>> > >>> > >>> > -- > [ Picked text/plain from multipart/alternative ] > Then why is it that when I try and delete the elements it crashes the > game? > lol... > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > > > > -- > > [ Picked text/plain from multipart/alternative ] > > you have to delete what you add. purging just removes the elements. > > > > On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > > > > > >> -- > >> [ Picked text/plain from multipart/alternative ] > >> Am I right in assuming that if you have a vector of pointers, that > >> point > >> to > >> things you create with "new", you have to either call delete on each > >> element > >> or use PurgeAndDeleteElements()? Because that's what I've been using > >> > >>> up > >>> > >> until recently, where it seems that trying to delete elements from a > >> pointer > >> vector on destruction of whatever they are members of just causes the > >> > > game > > > >> to crash with a memory error. Removing the calls to delete stop the > >> > > crash, > > > >> but unless CUtlVector automatically cleans up your memory for you, > >> won't > >> this just create MASSIVE memory leaks? As far as I knew, CUtlVector > >> didn't > >> magically look after your memory for you... was I wrong? > >> > >> J > >> -- > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list > >> > >>> archives, > >>> > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > >> > > -- > > -omega > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > >>> -- > >>> > >>> ___ > >>> To unsubscribe, edit your list preferences, or view the list archives, > >>> please visit: > >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >>> > >>> > >>> > >> -- > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftwar
Re: [hlcoders] CUtlVector<*>... Memory management?
Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel -- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer vector on destruction of whatever they are members of just causes the game to crash with a memory error. Removing the calls to delete stop the crash, but unless CUtlVector automatically cleans up your memory for you, won't this just create MASSIVE memory leaks? As far as I knew, CUtlVector didn't magically look after your memory for you... was I wrong? J -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Alpha-blended UnlitTwoTexture with overlays broken in Episode 2?
Evening...
Been following up on something posted on the MINERVA forums - getting
MINERVA to work as a mod of Episode Two rather than Episode One:
http://www.hylobatidae.org/minerva/forum/viewtopic.php?t=172
It all works remarkably well, except that the scrolling wave overlays
on the water are horribly broken. There just doesn't seem to be any
proper alpha-blending at all, and fiddling with the material file
hasn't fixed anything. Rampant Googling has just revealed someone on a
forum talking about fixing "Issues with the new source engine 2007
concerning alpha-blending on UnlitTwoTexture shaders" in their own mod
- but not how.
Any ideas? Is it an Ep2 bug, or do I need some other magical keywords
in the material? Or should I start work on some new, conventionally
animated wave textures? The generic unlit texture seems okay when used
on water, so such waves should work...
Adam
Here's my test/shorewave003a.vmt:
"UnlitTwoTexture"
{
"$basetexture" "overlays/shorewave001a"
"$texture2""test/wave3"
"$translucent" 1
"$alpha" 0.6
// "$additive" 1
"$decal" 1
// "$ignorez" 1
"Proxies"
{
"TextureScroll"
{
"texturescrollvar" "$texture2transform"
"texturescrollrate" 0.1
"texturescrollangle" 80
}
}
}
--
Adam Foster - [EMAIL PROTECTED] - http://www.hylobatidae.org/
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] woowwah weee-weee. Thanks.. this looks very convenient. - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 11:35 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > Minh wrote: >> -- >> [ Picked text/plain from multipart/alternative ] >> If you want a real quick and dirty method, I usually just open up Task >> Manager and watch the memory usage of the HL2 process.. > > Process Explorer... > > http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx > > ...beats Task Manager by a metric buttload. > > -- > Jeffrey "botman" Broome > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Minh wrote: -- [ Picked text/plain from multipart/alternative ] If you want a real quick and dirty method, I usually just open up Task Manager and watch the memory usage of the HL2 process.. Process Explorer... http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx ...beats Task Manager by a metric buttload. -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Newer versions of windows do, im sure that Windows 9x had memory issues where it was ESSENTIAL you free'd memory you allocated. However, now windows manages each apps memory (Virtual Memory Addressing), and it will free any memory you allocated but didn't delete. The reason you should still use delete is that your program will start to become slow/sluggish, etc. Performance reasons. Jed wrote: Well its C++ so I always thought it was a case that you *have* to properly release any memory you allocate. I usually stick a debug header at the top of all my code files so if theres any memory leaks it'll tell me where they are when the program exits. - Jed On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] That's what I'd like to know.. I'm not totally convinced that it's safe to just leave stuff in the memory.. perhaps a member of Valve staff can confirm? On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] hmm.. I've gotten way with just calling RemoveAll() on my CUTLVectors. Then when I add new elements, I believe it just overtakes the existing memory addresses of these previous elements that were in the vector. Mind you, my utlvectors typically never grow to be more than 20 elements. When Half-Life2 shuts down, does all of the memory allocations that were created during the game get deallocated automatically, so other programs can use them? - Original Message - From: "Jamie Femia" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 9:55 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? -- [ Picked text/plain from multipart/alternative ] Then why is it that when I try and delete the elements it crashes the game? lol... On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] you have to delete what you add. purging just removes the elements. On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer vector on destruction of whatever they are members of just causes the game to crash with a memory error. Removing the calls to delete stop the crash, but unless CUtlVector automatically cleans up your memory for you, won't this just create MASSIVE memory leaks? As far as I knew, CUtlVector didn't magically look after your memory for you... was I wrong? J -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- -omega -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] If you want a real quick and dirty method, I usually just open up Task Manager and watch the memory usage of the HL2 process.. You can observe the fluctuations as the game is being run. I was able to track down a memory leak with entities being spawned and not being deallocated properly using this method. - Original Message - From: "Jeremy" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 11:04 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > -- > [ Picked text/plain from multipart/alternative ] > I haven't tried this with HL2, so I don't know how it would play with the > HL2 memory manager, but for memory leak detection, this is the best thing > since sliced bread for C++ > > http://www.codeproject.com/KB/applications/visualleakdetector.aspx > > J > > On Jan 11, 2008 10:58 AM, Jed <[EMAIL PROTECTED]> wrote: > >> Well its C++ so I always thought it was a case that you *have* to >> properly release any memory you allocate. I usually stick a debug >> header at the top of all my code files so if theres any memory leaks >> it'll tell me where they are when the program exits. >> >> - Jed >> >> On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: >> > -- >> > [ Picked text/plain from multipart/alternative ] >> > That's what I'd like to know.. I'm not totally convinced that it's safe >> to >> > just leave stuff in the memory.. perhaps a member of Valve staff can >> > confirm? >> > >> > On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: >> > >> > > -- >> > > [ Picked text/plain from multipart/alternative ] >> > > hmm.. I've gotten way with just calling >> > > RemoveAll() on my CUTLVectors. >> > > Then when I add new elements, I believe it just overtakes the >> > > existing >> > > memory addresses of these previous elements that were in the vector. >> Mind >> > > you, my utlvectors typically never grow to be more than 20 elements. >> > > >> > > When Half-Life2 shuts down, does all of the memory allocations that >> were >> > > created during the game get deallocated automatically, so other >> programs >> > > can >> > > use them? >> > > >> > > >> > > - Original Message - >> > > From: "Jamie Femia" <[EMAIL PROTECTED]> >> > > To: >> > > Sent: Friday, January 11, 2008 9:55 AM >> > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? >> > > >> > > >> > > > -- >> > > > [ Picked text/plain from multipart/alternative ] >> > > > Then why is it that when I try and delete the elements it crashes >> the >> > > > game? >> > > > lol... >> > > > >> > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> >> wrote: >> > > > >> > > >> -- >> > > >> [ Picked text/plain from multipart/alternative ] >> > > >> you have to delete what you add. purging just removes the >> > > >> elements. >> > > >> >> > > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: >> > > >> >> > > >> > -- >> > > >> > [ Picked text/plain from multipart/alternative ] >> > > >> > Am I right in assuming that if you have a vector of pointers, >> that >> > > >> > point >> > > >> > to >> > > >> > things you create with "new", you have to either call delete on >> each >> > > >> > element >> > > >> > or use PurgeAndDeleteElements()? Because that's what I've been >> using >> > > up >> > > >> > until recently, where it seems that trying to delete elements >> from a >> > > >> > pointer >> > > >> > vector on destruction of whatever they are members of just >> > > >> > causes >> the >> > > >> game >> > > >> > to crash with a memory error. Removing the calls to delete stop >> the >> > > >> crash, >> > > >> > but unless CUtlVector automatically cleans up your memory for >> you, >> > > >> > won't >> > > >> > this just create MASSIVE memory leaks? As far as I knew, >> CUtlVector >> > > >> > didn't >> > > >> > magically look after your memory for you... was I wrong? >> > > >> > >> > > >> > J >> > > >> > -- >> > > >> > >> > > >> > ___ >> > > >> > To unsubscribe, edit your list preferences, or view the list >> > > archives, >> > > >> > please visit: >> > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > >> > >> > > >> > >> > > >> >> > > >> >> > > >> -- >> > > >> -omega >> > > >> -- >> > > >> >> > > >> ___ >> > > >> To unsubscribe, edit your list preferences, or view the list >> archives, >> > > >> please visit: >> > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > >> >> > > >> >> > > > -- >> > > > >> > > > ___ >> > > > To unsubscribe, edit your list preferences, or view the list >> archives, >> > > > please visit: >> > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >> > > >> > > -- >> > > >> > > ___ >> > > To unsubscribe, edit your list preferences, or view the list >> > > archives, >> > > please visit: >> > > htt
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] What happens if you don't properly release the memory? Will the Memory Man come to your house and beat you to death? If the app is running under Windows and windows knows how much memory is being allocated, then couldn't we just rely on windows to take care of the memory deallocation process? Or perhaps, we don't trust Windows - Original Message - From: "Jed" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 10:58 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > Well its C++ so I always thought it was a case that you *have* to > properly release any memory you allocate. I usually stick a debug > header at the top of all my code files so if theres any memory leaks > it'll tell me where they are when the program exits. > > - Jed > > On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: >> -- >> [ Picked text/plain from multipart/alternative ] >> That's what I'd like to know.. I'm not totally convinced that it's safe >> to >> just leave stuff in the memory.. perhaps a member of Valve staff can >> confirm? >> >> On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: >> >> > -- >> > [ Picked text/plain from multipart/alternative ] >> > hmm.. I've gotten way with just calling >> > RemoveAll() on my CUTLVectors. >> > Then when I add new elements, I believe it just overtakes the existing >> > memory addresses of these previous elements that were in the vector. >> > Mind >> > you, my utlvectors typically never grow to be more than 20 elements. >> > >> > When Half-Life2 shuts down, does all of the memory allocations that >> > were >> > created during the game get deallocated automatically, so other >> > programs >> > can >> > use them? >> > >> > >> > - Original Message - >> > From: "Jamie Femia" <[EMAIL PROTECTED]> >> > To: >> > Sent: Friday, January 11, 2008 9:55 AM >> > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? >> > >> > >> > > -- >> > > [ Picked text/plain from multipart/alternative ] >> > > Then why is it that when I try and delete the elements it crashes the >> > > game? >> > > lol... >> > > >> > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> >> > > wrote: >> > > >> > >> -- >> > >> [ Picked text/plain from multipart/alternative ] >> > >> you have to delete what you add. purging just removes the elements. >> > >> >> > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: >> > >> >> > >> > -- >> > >> > [ Picked text/plain from multipart/alternative ] >> > >> > Am I right in assuming that if you have a vector of pointers, that >> > >> > point >> > >> > to >> > >> > things you create with "new", you have to either call delete on >> > >> > each >> > >> > element >> > >> > or use PurgeAndDeleteElements()? Because that's what I've been >> > >> > using >> > up >> > >> > until recently, where it seems that trying to delete elements from >> > >> > a >> > >> > pointer >> > >> > vector on destruction of whatever they are members of just causes >> > >> > the >> > >> game >> > >> > to crash with a memory error. Removing the calls to delete stop >> > >> > the >> > >> crash, >> > >> > but unless CUtlVector automatically cleans up your memory for you, >> > >> > won't >> > >> > this just create MASSIVE memory leaks? As far as I knew, >> > >> > CUtlVector >> > >> > didn't >> > >> > magically look after your memory for you... was I wrong? >> > >> > >> > >> > J >> > >> > -- >> > >> > >> > >> > ___ >> > >> > To unsubscribe, edit your list preferences, or view the list >> > archives, >> > >> > please visit: >> > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> > >> > >> > >> > >> >> > >> >> > >> -- >> > >> -omega >> > >> -- >> > >> >> > >> ___ >> > >> To unsubscribe, edit your list preferences, or view the list >> > >> archives, >> > >> please visit: >> > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> >> > >> >> > > -- >> > > >> > > ___ >> > > To unsubscribe, edit your list preferences, or view the list >> > > archives, >> > > please visit: >> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > >> > >> > -- >> > >> > ___ >> > To unsubscribe, edit your list preferences, or view the list archives, >> > please visit: >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> > >> -- >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > -- ___ To unsubscr
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] I haven't tried this with HL2, so I don't know how it would play with the HL2 memory manager, but for memory leak detection, this is the best thing since sliced bread for C++ http://www.codeproject.com/KB/applications/visualleakdetector.aspx J On Jan 11, 2008 10:58 AM, Jed <[EMAIL PROTECTED]> wrote: > Well its C++ so I always thought it was a case that you *have* to > properly release any memory you allocate. I usually stick a debug > header at the top of all my code files so if theres any memory leaks > it'll tell me where they are when the program exits. > > - Jed > > On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > That's what I'd like to know.. I'm not totally convinced that it's safe > to > > just leave stuff in the memory.. perhaps a member of Valve staff can > > confirm? > > > > On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > > > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > hmm.. I've gotten way with just calling > > > RemoveAll() on my CUTLVectors. > > > Then when I add new elements, I believe it just overtakes the existing > > > memory addresses of these previous elements that were in the vector. > Mind > > > you, my utlvectors typically never grow to be more than 20 elements. > > > > > > When Half-Life2 shuts down, does all of the memory allocations that > were > > > created during the game get deallocated automatically, so other > programs > > > can > > > use them? > > > > > > > > > - Original Message - > > > From: "Jamie Femia" <[EMAIL PROTECTED]> > > > To: > > > Sent: Friday, January 11, 2008 9:55 AM > > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > > > > > > > -- > > > > [ Picked text/plain from multipart/alternative ] > > > > Then why is it that when I try and delete the elements it crashes > the > > > > game? > > > > lol... > > > > > > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> > wrote: > > > > > > > >> -- > > > >> [ Picked text/plain from multipart/alternative ] > > > >> you have to delete what you add. purging just removes the elements. > > > >> > > > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > > > >> > > > >> > -- > > > >> > [ Picked text/plain from multipart/alternative ] > > > >> > Am I right in assuming that if you have a vector of pointers, > that > > > >> > point > > > >> > to > > > >> > things you create with "new", you have to either call delete on > each > > > >> > element > > > >> > or use PurgeAndDeleteElements()? Because that's what I've been > using > > > up > > > >> > until recently, where it seems that trying to delete elements > from a > > > >> > pointer > > > >> > vector on destruction of whatever they are members of just causes > the > > > >> game > > > >> > to crash with a memory error. Removing the calls to delete stop > the > > > >> crash, > > > >> > but unless CUtlVector automatically cleans up your memory for > you, > > > >> > won't > > > >> > this just create MASSIVE memory leaks? As far as I knew, > CUtlVector > > > >> > didn't > > > >> > magically look after your memory for you... was I wrong? > > > >> > > > > >> > J > > > >> > -- > > > >> > > > > >> > ___ > > > >> > To unsubscribe, edit your list preferences, or view the list > > > archives, > > > >> > please visit: > > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > >> > > > > >> > > > > >> > > > >> > > > >> -- > > > >> -omega > > > >> -- > > > >> > > > >> ___ > > > >> To unsubscribe, edit your list preferences, or view the list > archives, > > > >> please visit: > > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > >> > > > >> > > > > -- > > > > > > > > ___ > > > > To unsubscribe, edit your list preferences, or view the list > archives, > > > > please visit: > > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > > -- > > > > > > ___ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Well its C++ so I always thought it was a case that you *have* to properly release any memory you allocate. I usually stick a debug header at the top of all my code files so if theres any memory leaks it'll tell me where they are when the program exits. - Jed On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > That's what I'd like to know.. I'm not totally convinced that it's safe to > just leave stuff in the memory.. perhaps a member of Valve staff can > confirm? > > On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > > > -- > > [ Picked text/plain from multipart/alternative ] > > hmm.. I've gotten way with just calling > > RemoveAll() on my CUTLVectors. > > Then when I add new elements, I believe it just overtakes the existing > > memory addresses of these previous elements that were in the vector. Mind > > you, my utlvectors typically never grow to be more than 20 elements. > > > > When Half-Life2 shuts down, does all of the memory allocations that were > > created during the game get deallocated automatically, so other programs > > can > > use them? > > > > > > - Original Message - > > From: "Jamie Femia" <[EMAIL PROTECTED]> > > To: > > Sent: Friday, January 11, 2008 9:55 AM > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > Then why is it that when I try and delete the elements it crashes the > > > game? > > > lol... > > > > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > > > > > >> -- > > >> [ Picked text/plain from multipart/alternative ] > > >> you have to delete what you add. purging just removes the elements. > > >> > > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > > >> > > >> > -- > > >> > [ Picked text/plain from multipart/alternative ] > > >> > Am I right in assuming that if you have a vector of pointers, that > > >> > point > > >> > to > > >> > things you create with "new", you have to either call delete on each > > >> > element > > >> > or use PurgeAndDeleteElements()? Because that's what I've been using > > up > > >> > until recently, where it seems that trying to delete elements from a > > >> > pointer > > >> > vector on destruction of whatever they are members of just causes the > > >> game > > >> > to crash with a memory error. Removing the calls to delete stop the > > >> crash, > > >> > but unless CUtlVector automatically cleans up your memory for you, > > >> > won't > > >> > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > >> > didn't > > >> > magically look after your memory for you... was I wrong? > > >> > > > >> > J > > >> > -- > > >> > > > >> > ___ > > >> > To unsubscribe, edit your list preferences, or view the list > > archives, > > >> > please visit: > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > > >> > > > >> > > >> > > >> -- > > >> -omega > > >> -- > > >> > > >> ___ > > >> To unsubscribe, edit your list preferences, or view the list archives, > > >> please visit: > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > >> > > > -- > > > > > > ___ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Minh wrote: When Half-Life2 shuts down, does all of the memory allocations that were created during the game get deallocated automatically, so other programs can use them? Yes. Anytime a Windoze app shuts down, the OS will reclaim any memory that was allocated and never freed. -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Windows cleans up after an application that leaks memory, but yea you don't want to purposely leave memory leaks. I'd venture a guess that it's not the vector thats causing the crash but something else. Memory corruption, double deletion, etc. If you are deleting and then calling a function where it tries to delete again it will crash, and vice versa. I would treat it like an std::vector, just remove the elements and do the deletions yourself. On Jan 11, 2008 10:42 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > That's what I'd like to know.. I'm not totally convinced that it's safe to > just leave stuff in the memory.. perhaps a member of Valve staff can > confirm? > > On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > > > -- > > [ Picked text/plain from multipart/alternative ] > > hmm.. I've gotten way with just calling > > RemoveAll() on my CUTLVectors. > > Then when I add new elements, I believe it just overtakes the existing > > memory addresses of these previous elements that were in the vector. > Mind > > you, my utlvectors typically never grow to be more than 20 elements. > > > > When Half-Life2 shuts down, does all of the memory allocations that were > > created during the game get deallocated automatically, so other programs > > can > > use them? > > > > > > - Original Message - > > From: "Jamie Femia" <[EMAIL PROTECTED]> > > To: > > Sent: Friday, January 11, 2008 9:55 AM > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > Then why is it that when I try and delete the elements it crashes the > > > game? > > > lol... > > > > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > > > > > >> -- > > >> [ Picked text/plain from multipart/alternative ] > > >> you have to delete what you add. purging just removes the elements. > > >> > > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > > >> > > >> > -- > > >> > [ Picked text/plain from multipart/alternative ] > > >> > Am I right in assuming that if you have a vector of pointers, that > > >> > point > > >> > to > > >> > things you create with "new", you have to either call delete on > each > > >> > element > > >> > or use PurgeAndDeleteElements()? Because that's what I've been > using > > up > > >> > until recently, where it seems that trying to delete elements from > a > > >> > pointer > > >> > vector on destruction of whatever they are members of just causes > the > > >> game > > >> > to crash with a memory error. Removing the calls to delete stop the > > >> crash, > > >> > but unless CUtlVector automatically cleans up your memory for you, > > >> > won't > > >> > this just create MASSIVE memory leaks? As far as I knew, > CUtlVector > > >> > didn't > > >> > magically look after your memory for you... was I wrong? > > >> > > > >> > J > > >> > -- > > >> > > > >> > ___ > > >> > To unsubscribe, edit your list preferences, or view the list > > archives, > > >> > please visit: > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > > >> > > > >> > > >> > > >> -- > > >> -omega > > >> -- > > >> > > >> ___ > > >> To unsubscribe, edit your list preferences, or view the list > archives, > > >> please visit: > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > >> > > > -- > > > > > > ___ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] That's what I'd like to know.. I'm not totally convinced that it's safe to just leave stuff in the memory.. perhaps a member of Valve staff can confirm? On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > hmm.. I've gotten way with just calling > RemoveAll() on my CUTLVectors. > Then when I add new elements, I believe it just overtakes the existing > memory addresses of these previous elements that were in the vector. Mind > you, my utlvectors typically never grow to be more than 20 elements. > > When Half-Life2 shuts down, does all of the memory allocations that were > created during the game get deallocated automatically, so other programs > can > use them? > > > - Original Message - > From: "Jamie Femia" <[EMAIL PROTECTED]> > To: > Sent: Friday, January 11, 2008 9:55 AM > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Then why is it that when I try and delete the elements it crashes the > > game? > > lol... > > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > > > >> -- > >> [ Picked text/plain from multipart/alternative ] > >> you have to delete what you add. purging just removes the elements. > >> > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > >> > >> > -- > >> > [ Picked text/plain from multipart/alternative ] > >> > Am I right in assuming that if you have a vector of pointers, that > >> > point > >> > to > >> > things you create with "new", you have to either call delete on each > >> > element > >> > or use PurgeAndDeleteElements()? Because that's what I've been using > up > >> > until recently, where it seems that trying to delete elements from a > >> > pointer > >> > vector on destruction of whatever they are members of just causes the > >> game > >> > to crash with a memory error. Removing the calls to delete stop the > >> crash, > >> > but unless CUtlVector automatically cleans up your memory for you, > >> > won't > >> > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > >> > didn't > >> > magically look after your memory for you... was I wrong? > >> > > >> > J > >> > -- > >> > > >> > ___ > >> > To unsubscribe, edit your list preferences, or view the list > archives, > >> > please visit: > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > > >> > > >> > >> > >> -- > >> -omega > >> -- > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] hmm.. I've gotten way with just calling RemoveAll() on my CUTLVectors. Then when I add new elements, I believe it just overtakes the existing memory addresses of these previous elements that were in the vector. Mind you, my utlvectors typically never grow to be more than 20 elements. When Half-Life2 shuts down, does all of the memory allocations that were created during the game get deallocated automatically, so other programs can use them? - Original Message - From: "Jamie Femia" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 9:55 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > -- > [ Picked text/plain from multipart/alternative ] > Then why is it that when I try and delete the elements it crashes the > game? > lol... > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > >> -- >> [ Picked text/plain from multipart/alternative ] >> you have to delete what you add. purging just removes the elements. >> >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: >> >> > -- >> > [ Picked text/plain from multipart/alternative ] >> > Am I right in assuming that if you have a vector of pointers, that >> > point >> > to >> > things you create with "new", you have to either call delete on each >> > element >> > or use PurgeAndDeleteElements()? Because that's what I've been using up >> > until recently, where it seems that trying to delete elements from a >> > pointer >> > vector on destruction of whatever they are members of just causes the >> game >> > to crash with a memory error. Removing the calls to delete stop the >> crash, >> > but unless CUtlVector automatically cleans up your memory for you, >> > won't >> > this just create MASSIVE memory leaks? As far as I knew, CUtlVector >> > didn't >> > magically look after your memory for you... was I wrong? >> > >> > J >> > -- >> > >> > ___ >> > To unsubscribe, edit your list preferences, or view the list archives, >> > please visit: >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> > >> >> >> -- >> -omega >> -- >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Then why is it that when I try and delete the elements it crashes the game? lol... On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > you have to delete what you add. purging just removes the elements. > > On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > -- > -omega > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] you have to delete what you add. purging just removes the elements. On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > Am I right in assuming that if you have a vector of pointers, that point > to > things you create with "new", you have to either call delete on each > element > or use PurgeAndDeleteElements()? Because that's what I've been using up > until recently, where it seems that trying to delete elements from a > pointer > vector on destruction of whatever they are members of just causes the game > to crash with a memory error. Removing the calls to delete stop the crash, > but unless CUtlVector automatically cleans up your memory for you, won't > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > didn't > magically look after your memory for you... was I wrong? > > J > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- -omega -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer vector on destruction of whatever they are members of just causes the game to crash with a memory error. Removing the calls to delete stop the crash, but unless CUtlVector automatically cleans up your memory for you, won't this just create MASSIVE memory leaks? As far as I knew, CUtlVector didn't magically look after your memory for you... was I wrong? J -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Any Source 2007 code update?
Hope fully it will come fast. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] character studio biped?
Just use cannonfodders SMD export. Weve been using our custom biped rigs with custom qcs for ages, it works a charm and is not that hard btw. > And make sure if your using CS Biped that your exporter supports > exporting them first... > > - Jed > > On 11/01/2008, Minh <[EMAIL PROTECTED]> wrote: >> -- >> [ Picked text/plain from multipart/alternative ] >> Yea, you can use CS Biped.. Just make sure you name the bones the same >> way >> they're named in the XSI Skeleton *IF* you plan on using any of the >> existing >> .qc sample files included in the SDK. >> >> ie. When you export your .smds, the .smd bone names should look like. >> >> "ValveBiped.Bip01_Pelvis" >> "ValveBiped.Bip01_Spine" >> etc... >> >> It's just MUCH easier if you follow the Valve naming convention as it >> allows >> you to use a lot of their existing .qc files as templates to create your >> own >> .qc file. If you are really good though, you can write .qc files from >> scratch (which is VERY difficult) >> >> >> - Original Message - >> From: "bobby smith" <[EMAIL PROTECTED]> >> To: >> Sent: Thursday, January 10, 2008 4:22 PM >> Subject: [hlcoders] character studio biped? >> >> >> -- >> [ Picked text/plain from multipart/alternative ] >> From what I understand Character Studio bipeds are usable in Source, >> however >> there is no documentation. On the Valve Dev Wiki it says that the xsi >> bipeds are very similar due to the team switching to XSI. Is it as >> simple >> as following the Valve bone naming condition and creating custom >> animations? >> Does anyone have some insight on this? >> >> >> - >> Looking for last minute shopping deals? Find them fast with Yahoo! >> Search. >> -- >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> -- >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] character studio biped?
And make sure if your using CS Biped that your exporter supports exporting them first... - Jed On 11/01/2008, Minh <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > Yea, you can use CS Biped.. Just make sure you name the bones the same way > they're named in the XSI Skeleton *IF* you plan on using any of the existing > .qc sample files included in the SDK. > > ie. When you export your .smds, the .smd bone names should look like. > > "ValveBiped.Bip01_Pelvis" > "ValveBiped.Bip01_Spine" > etc... > > It's just MUCH easier if you follow the Valve naming convention as it allows > you to use a lot of their existing .qc files as templates to create your own > .qc file. If you are really good though, you can write .qc files from > scratch (which is VERY difficult) > > > - Original Message - > From: "bobby smith" <[EMAIL PROTECTED]> > To: > Sent: Thursday, January 10, 2008 4:22 PM > Subject: [hlcoders] character studio biped? > > > -- > [ Picked text/plain from multipart/alternative ] > From what I understand Character Studio bipeds are usable in Source, however > there is no documentation. On the Valve Dev Wiki it says that the xsi > bipeds are very similar due to the team switching to XSI. Is it as simple > as following the Valve bone naming condition and creating custom animations? > Does anyone have some insight on this? > > > - > Looking for last minute shopping deals? Find them fast with Yahoo! Search. > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
