![]() |
G_Alloc()
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()? |
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. |
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.
|
And what is wrong with having to dealloc the mem? Btw, that isn't what raven did that is old q3 code (G_Alloc)
|
well if you wanted G_Alloc() to be able to dealloc mem you'd have to do the same thing anyway :S
|
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 07:47 AM. |
Powered by vBulletin®
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
LFNetwork, LLC ©2002-2011 - All rights reserved.