Even C++08 should have std::vector :

std::vector<int> vector_array(512 , (int)0);
vector_array[blah]...;
vector_array.clear();

And yes, a derived class object inherits all the objects that the parent holds, according to its access modifier :

I don't see what you're trying to do though. Those arrays you declared as class members are allocated on whatever the medium was that their class was created on, be it the heap or the stack.

Then don't allocate it? Use a pointer, and only allocate it if you need it. new and delete, new[] and delete[], malloc and free.

Unless you have a good reason not to use it, a vector is exactly what you asked for. Array semantics. Preallocation. Easy to free. Lives on the stack. Uses memory on the heap. You fully admit you're using C++ but you don't want to use the STL. Sigh.

Your only other option is manual dynamic memory allocation and deallocation, or not to derive from a class that holds data it won't use, which makes sense.

Base classes should typically only be an interface. The more state they carry, the heavier they get to use properly.

How does it rely on them being arrays? Syntax, memory layout, something else?

It didn't come in until C++11 but std::array gives you all the memory management of C++ but allows you to get a raw data pointer for compatibility.

Is this code from ZeldaClassic? Maybe you could post a link to a file you think is particularly 'bad' and people could give you some more concrete solutions.

Pete

True but if you store that pointer somewhere it might become invalid if the vector resizes. Though in this case if I understand correctly the vectors wouldn't be resized.

A little of both.

The arrays are used for script stacks, and I don't want to use a vector for the sprite stacks, but not elsewhere. The syntax and structure should be uniform.

Isn't vector access (C++03) slower, too? I certainly want to avood adding even more impediments into the system.

It's for ZC, specifically ZScript stacks for sprited objects.

I wish it was just one file. It's spread out everwhere, but I can give you a few commits if you're curious.

https://github.com/ArmageddonGames/ZeldaClassic/commit/484edc9dca24fc71f3c61855680dce3ca3376fe9

https://github.com/ArmageddonGames/ZeldaClassic/commit/b3304481efe45122e73c9eaa0b1f0a3780eb5d1e

https://github.com/ArmageddonGames/ZeldaClassic/commit/0bc2d4e76e878f40979c4090db2e5944d882a5cb

That one is notable, as it has pointer conversion of the stacks in it. The majority of my commits from the last week are on this subject, and sadly, I'm the only one working on this aspect of the programme at present.

I want to finish all new script types by the end of the month, to get a build out with them for people to play with during the holidays, so, time is also a factor.

Anyway, I think that until I'm ready to convert all of the stacks, and the global registers to vectors, that making new classes for decoration and particles is the best solution for RAM conservation.

It wouldn't be a bad idea for them to be separate anyway. That particles are also sprites also causes an issue with sprite counts, which I want to avoid. The solutions for that are:

(1) Increase maximum sprite count universally from 255 to 65280 (!!).
(2) Somehow make a lot of exceptions for particles when determining counts.
(3) Don't make particles derive from sprite class objects.

The third choice is cleaner, all-around.

P.S. Full backward-compatibility is the most important priority when we add new features, so bear in mind that we can't change how stuff used to work, unless any refactoring ensures that it still (non-mechanically) works in precisely the same manner.

All quests and scripts made in earlier versions still must work properly, without being edited or changed, in the new versions of ZC. It's part of the programme standard.

I don't... why haven't you done it already?

If you truly want "Speed", then you shouldn't be allocating anyway. You get one fixed chunk of memory (an array) and only use the indices you want. You also increase speed by sorting your indices so that the full and empty sets are at opposite ends with no overlap. The CPU branch predictor goes from "always true" to "always false" a total of ONE time. A single mispredict.

"But it uses more RAM!"

And?

"But I care about RAM."

1. Optimize for one thing. You cannot have your cake and eat it too.

2. Have you done actual math, to see if having PARTICLE_MAX entries will use up "too much"? Have you even defined "too much" for your target platform, or are you simply going on feelings of "this feels like a waste"?

Because if your program CAN swell to say, 32MB, and runs on people's machines... then why do you care if it ever takes LESS than that? Oh, sure, you get it down to 24MB by carefully allocating only the needed assets... and then you change to a big level and it goes back to 32MB. If it CAN swell to a large size, then the user NEEDS that much RAM regardless. They can't play 90% of the game and then just give up on the final boss because your careful allocation strategy saved RAM until the boss was loaded in and then it needed PARTICLE_MAX number of particles flying around.

You're making a game, not a windows service. You have the user's undivided attention. You're not running 300 of them in the background at a time on a server. They want the game to run, and run well. That's it. The NUMBERS like "ram usage" don't matter at all as long as the user experience is actually solid.

It seems like your focusing on "tuning" your project like it's a hotrod and every little ounce of tweaking improves it. It's not a hotrod. It's a burger joint and people only care if the burgers get delivered in a timely matter and at a reasonable cost. A good burger that costs 30 cents less than it did before, won't gain a single extra sale. People want good burgers, not 30 extra cents lying around in their pockets.

So because games take incredible amount of hours to make, optimize for production efficency. Getting the game out the door with features people care about. People aren't downloading a memory allocator, or particle system. They're downloading a game.

particles definitely should NOT inherit from sprite.

a particle is a dumb effect. It does not need to know about scripts or sprites, or anything else. At most it's a list of positions and velocities away from a central point with a shared image.

But how big are they? In bytes, I mean.

And why that specific number? Why 65280? That's not even a power of two. Why not 2048? Or 4096?

DEAR GOSH, NO. NEVER. NEVER. NNEEEVVVEr.

Just others said. Particles should be a ROOT object. They're special because they're dumb, and there's TONS of them, so it's worth making a distinction from normal objects.

You should have a fixed array of MAX_PARTICLES. All "alive" or "used" particles are kept at the front. So if it's half filled, the front half is used. When a random particle is "deleted" you SWAP IT with the last living particle ($current_number_of_particles), and then decrement $current_number_of_particles. So now what was the last living particle is now a "deleted" one, and you've "resized" your array with a single decrement.

Also,

2 GB of RAM is still a huge amount.

[65536 particles] * [128 bytes] equals ... 8 MB. A whopping 8 MB of RAM.

There are printer drivers using more RAM on 32-bit XP machines.

If you have those particles inside an object class (and don't even use all the methods/data from that class), then yeah, you might end up with huge classes being repeated.

Also, ADDING a new element is as simple as incrementing the index and resetting all the data in that element. ZERO operating system memory allocations. ZERO system calls. ZERO context switches to kernel mode for the kernel driver (SLOW!). All you're doing is setting some values (a simple bit copy, if you're smart with your struct). It's orders-of-a-magnitude faster.

And best of all? When you pack them in an array you can operate on more than one at a time--which you should be. Cache line size of almost every CPU in the last two decades is 64 bytes. That's the minimum amount of RAM it can read at a time and if you change one byte, it still has to FLUSH every other byte in that cache line.

It's called "data oriented design" and every console game does it. If it works for Gamecubes and Xbox (originals), it'll work on a 2 GB RAM XP machine.

Note that each particle has its own lifespan. When a particle needs be removed in the middle of the array, displacing every particle after it one step up would be expensive. An alternative is to pick the last particle of the array, put it in the slot that you want to free, and then decrement the array's "top counter".
This does un-sort the array over time, though, so hopefully the rendering engine doesn't need particles to stay ordered the same way.