Hey guys, one of the things I've been doing as part of my property project is to try and decrease the memory footprint. It's not easy - the engine is already very optimal in most aspects. To squeeze out every last byte, I've been replacing a lot of internal variables with smaller types. This in turn results in smaller limits, albeit still academic.
One easy example is frames. Strictly speaking, OpenBOR does not actually have "frames" the way you think of them. There's just a set of arrayed properties on the animation strcture that taken together make up what is visually a frame on the screen. Previously the controlling integer values for each of those arrayed properties was a standard int, meaning they could range from -2,147,483,648 to 2,147,483,647. Standard practice for some good reasons, but in our case wasteful and leads to shortcut hacks I've been cleaning up. They are now a unsigned short int, making the range 0 to 65,535. Enough to put every single frame of a SFIII character in one animation and still have 64,000 or so left over. I think you'll be OK.
The important part is that it costs 2 bytes instead of 4. That's nothing alone, but multiplied by every animation for every entity it starts to make a difference. Doing the same thing for certain properties that exist per frame, or multiple per frame, really adds up. Bigger the module, the more it helps. Thus far I've taken one of my own projects from 83MB to 77MB.
Anyway, as I go, I'm putting these new (and old) limits on a single wiki page just so you can see them.
DC
One easy example is frames. Strictly speaking, OpenBOR does not actually have "frames" the way you think of them. There's just a set of arrayed properties on the animation strcture that taken together make up what is visually a frame on the screen. Previously the controlling integer values for each of those arrayed properties was a standard int, meaning they could range from -2,147,483,648 to 2,147,483,647. Standard practice for some good reasons, but in our case wasteful and leads to shortcut hacks I've been cleaning up. They are now a unsigned short int, making the range 0 to 65,535. Enough to put every single frame of a SFIII character in one animation and still have 64,000 or so left over. I think you'll be OK.
The important part is that it costs 2 bytes instead of 4. That's nothing alone, but multiplied by every animation for every entity it starts to make a difference. Doing the same thing for certain properties that exist per frame, or multiple per frame, really adds up. Bigger the module, the more it helps. Thus far I've taken one of my own projects from 83MB to 77MB.
Anyway, as I go, I'm putting these new (and old) limits on a single wiki page just so you can see them.
DC
