Overview

Dynamic Memory Allocator

Table of Contents

This project is abandoned and its default file will likely not work with the most recent version of StarCraft II. Whether this project is out of date or its author has marked it as abandoned, this project is no longer maintained.

@nestharus: I meant the static arrays. I'm surprised they're only using 8% of global memory though. That's pretty good. In terms of the allocation sizes, I meant that with the default settings, you couldn't allocate i.e. more than 64 waves at once. You would have to change the settings. This could be a pain if you don't know how many waves you'll need at a time. You would have to assume the worst and reserve more memory for your static array of waves. How did you check memory consumption, btw?

@MaskedPoptart: Go
huh? where am I reserving a ton of memory? You read/write directly to those arrays, and referencing them is 1 int. Also, it's fine for both small/large allocation sizes. This also makes it possible to do linked list, queue, dequeue, and etc.

So please, point out where I am reserving all of this memory =P. From my understanding, the data table (which is the only thing that hogs up memory) doesn't go towards the memory limit.

Unless of course you mean the memory blocks themselves. Moving it to a data table would slow everything drastically, it's better to portion out the memory you want to be able to dynamically allocate. Most memory you should be using for a map should be running off of this ; ). The rest would be simple pointers to the arrays in this (and you can have arrays of arrays of arrays of dif types, yes, it's awesome) or static array sizes that you definitely know will always be of those sizes =p.

Also, with the default settings, this only uses up 1% of code and 8% of global memory. That means you can use the other 92% of global memory for pointers ;o (unless ofc you need more memory, then u can just change the constants).

@tordecybombo: Go
It creates blocks of memory (arrays) and allows you to take portions of those arrays. It essentially works the same way as regular memory in that regard =).

Think of it like those custom malloc libs for c that reserve all the memory the program will ever use and only allows the program to use that reserved memory (for speed). In this case, I did it that way because that was the only way it could be done.

@Sixen: Go
Thank you : ). I think so too ; p. I started writing a linked list and realized I could store it as an int and pass all masses of data around as single ints as well. A pointer can point to arrays of arrays of arrays of all dif types, so you can create dynamic struct types, class types, and so on on the fly =o. I was really ecstatic about that =).

Also, this is a major improvement to the dynamic memory allocation featured in 3rd party languages for Galaxy (thus far). They purely used the data table, making all read/write operations extremely slow ;o.

This looks useful, but you're greatly limiting the amount of memory available for regular use (on the stack), since you're reserving a huge chunk of it. This is also only useful for relatively small allocation sizes, and you have to know approximately how many array elements you'll need for each type. Pretty cool concept, though. Good work.