What kind of array thing?

Hi folks.

I need to store some data structures in memory, ie a sequence of `objects`. Let's say each has 10 fields/variables of different kinds/sizes. I need these to all be stored in sequence, ie 10 fields followed by 10 fields followed by 10 fields etc. I don't want any kind of additional pointers or indirect referencing. The memory used to store one object has to immediately be followed by the memory used to store the next object. I don't want a `pointer to an instance of the type` being stored anywhere. Yet, as I said, all the fields have to be different kinds - bytes, int's, floats, etc. How can I do this and then be able to reference the individual fields efficiently?

If I define a custom type containing these fields, and then define an array of instances of that type, will that store a whole bunch of pointers to instances, or will it only store the instances in sequence?

Strings, Arrays and any other types of Object in BlitzMAX are all references (ie. pointers, but with nicer syntax).

I believe that array elements are stored sequentially, but if you define an array of a custom type, the array elements will be pointers to the instances.

For example:

Local items:Object[3]

items[0]=New TList
items[1]=New TList
items[2]=New TList

Print Int(Varptr items[0])
Print Int(Varptr items[1])
Print Int(Varptr items[2])

You can see that the array elements are stored sequentially, and occupy 4 bytes each, not the size of a TList object.

Hmm ok. So I might have to either treat all of the fields as bytes and in an array of bytes, and `combine` them after reading them or `split` them before writing.

Or maybe I can make it so all my fields are floats or something. Or have a separate array for each data type - probably a good idea.

This is for a particle engine - the memory accesses need to be really fast and minimal.

I really don't think you need to worry about the cost of dereferencing a pointer. It is absolutely minimal in comparison to the costs of whatever else your program might be doing. Have a look at the code for some of the BlitzMAX functions, and you'll see how much goes on for even some of the simple calls.

Actually it does matter when you're thinking about processing several million particles.

How many of these particles are actually going to be visible in any one frame though?

7000-10000 in maximum until BM will break with default 2D drivers ... so I don't think you will have to fear this kind of "performance problem" if you are not going to create your own rendering engine / driver

I will be using direct OpenGL. Not necessarily all of the particles will be drawn but all of those that are off-screen still need to continue their full physics interactions at all times.

I think I will probably have to settle for a slightly less `realistic` simulation. I think that so long as it mostly `looks like` it is behaving correctly that would be good enough.

I've never had any intrest in them, but you could use a bank. You'd have to keep up with how many of each data type you have, but you can store anything in a bank.

I'm pretty sure it works like an array of bytes. So if you wanted the 4th short from the start of the bank you'd do bank.peekshort(7).

Hmm. Well, the thing I don't like about using banks is that you have to either call a function or pass the number of the bank to call every time. It's faster to use array access on a real array.

If you're using OpenGL directly, I think you'd be better off using C to do what you want.