LucasForums (
-   JA Coding (
-   -   G_Alloc() (

razorace 09-19-2006 02:48 AM

As part of the my CoOp work, I've come across a problem with G_Alloc running out of space. Well, I looked at the actual function and it seems a bit inefficent. It only allocates in 32 char chunks and never allows for deallocation.

Does anyone know of a more efficent way to do G_Alloc()?

ensiform 09-19-2006 03:04 PM

I would try using trap_TrueMalloc and trap_TrueFree, best methods that I know of. And can be used from all of the modules.

trap_TrueMalloc example:

g_sess is clientSession * and trueMalloc wants the first arg to be a void **, second arg is the size you wish to alloc.

trap_TrueMalloc( (void **)&g_sess, g_maxclients.integer * sizeof( clientSession_t ) );

trap_TrueFree example:

argument is the pointer you are freeing from truemalloc and again wants **

trap_TrueFree( (void **)&g_sess );

you really do not need (void **) but gcc likes to be picky about those kinds of things.

razorace 09-19-2006 03:53 PM

I suppose I could do that, but then I'd have to worry about properly deallociating the data. I suspect that Raven did it this way to simplify the process (not requiring dealloc) and to statically allociate the "dynamic" memory.

ensiform 09-19-2006 04:30 PM

And what is wrong with having to dealloc the mem? Btw, that isn't what raven did that is old q3 code (G_Alloc)

dumbledore 09-19-2006 04:43 PM

well if you wanted G_Alloc() to be able to dealloc mem you'd have to do the same thing anyway :S

razorace 09-19-2006 06:56 PM

Well, crap. Poke holes in my logic then. :)

Actually I was interested to see if it was really nessicary to only allociate in the temp buffer in 32 char chunks. It seems silly to me since it's just a big array buffer anyway.

All times are GMT -4. The time now is 01:31 PM.

Powered by vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.
LFNetwork, LLC ©2002-2015 - All rights reserved.