What kind of array thing?
BlitzMax Forums/BlitzMax Programming/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. |
| ||
| 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. |
   |