Hi Mark -
perhaps there is a bug with the sizeof operator as it returned 4 and 8 for the sizes of my example object objects. It did not return the true data size. The first code example is actually runnable. That is why the Print sizeof(cube), etc are in the example program.
Also, when I created the arrays of objects in my example, if I didn't 'new' the colourargb and vert3 objects, no matter what element within the array I modified, it effected all array elements, indicating references, and not values.
So, as I mentioned, you could do mem copys, but I chose not to, as the sizeof operator was not working as I expected and each vert3 and colourargb was a reference.
This would have still have to be:
We still have :
mallocs : 18 mem
to bank copies : 16 memcopy
from bank copies: 16 memcopy
This still jumps up quite a bit when you get to 1000.
Also the is the requirement to increment a variable for the pointer offset. The amount of data being copied is still the same too, just less operations.
Yes, you can encapsulate it in an object, but there is no automatic way to do this, and so it must be manually written for each object type.
By suggesting the use of a "->" operator for these 'c' style types, I meant no relationship to C or C++ - it was merely a means to identify these types differently in code. Someone perusing some bmax code could see that a->x or b[10]->y referenced 'c' style objects, where as d.k or l[12].g referenced a blitz style object, and so they are different syntactically and semantically.
There is going to be a lot of unneccassary memory allocation and copying going on, that is my concern. The use of external physics engines is another example where passing arrays of vertices (or other data) is such a common exercise. Being this is per frame, it means potentially 100's of kbs to in excess of MBs of data per second. With the availability of a C style structure, there will be no need for any of this.
Blitz already has a number of advanced features - direct use of OpenGl, 'extern' to interface to external libraries. This is beyond a lot of average users, so I think there is a real need to provide the 'C' style structure for completeness.
Cheers,
Stu
perhaps there is a bug with the sizeof operator as it returned 4 and 8 for the sizes of my example object objects. It did not return the true data size. The first code example is actually runnable. That is why the Print sizeof(cube), etc are in the example program.
Also, when I created the arrays of objects in my example, if I didn't 'new' the colourargb and vert3 objects, no matter what element within the array I modified, it effected all array elements, indicating references, and not values.
So, as I mentioned, you could do mem copys, but I chose not to, as the sizeof operator was not working as I expected and each vert3 and colourargb was a reference.
This would have still have to be:
' ... all code to create and initialize the cube object, including all it's vert3 and colourargb components Local buf:byte ptr=MemAlloc(320) MemCopy buf,name.ToCString(),name.length MemCopy buf+blah1,varptr(mycube.verts[0].x), 32 blah1 :+ 32 MemCopy buf+blah1,varptr(mycube.verts[0].colour), 4 blah1 :+ 4 MemCopy buf+blah1,varptr(mycube.verts[1].x), 32 blah1 :+ 32 MemCopy buf+blah1,varptr(mycube.verts[1].colour), 4 blah1 :+ 4 ... etc
We still have :
mallocs : 18 mem
to bank copies : 16 memcopy
from bank copies: 16 memcopy
This still jumps up quite a bit when you get to 1000.
Also the is the requirement to increment a variable for the pointer offset. The amount of data being copied is still the same too, just less operations.
Yes, you can encapsulate it in an object, but there is no automatic way to do this, and so it must be manually written for each object type.
By suggesting the use of a "->" operator for these 'c' style types, I meant no relationship to C or C++ - it was merely a means to identify these types differently in code. Someone perusing some bmax code could see that a->x or b[10]->y referenced 'c' style objects, where as d.k or l[12].g referenced a blitz style object, and so they are different syntactically and semantically.
There is going to be a lot of unneccassary memory allocation and copying going on, that is my concern. The use of external physics engines is another example where passing arrays of vertices (or other data) is such a common exercise. Being this is per frame, it means potentially 100's of kbs to in excess of MBs of data per second. With the availability of a C style structure, there will be no need for any of this.
Blitz already has a number of advanced features - direct use of OpenGl, 'extern' to interface to external libraries. This is beyond a lot of average users, so I think there is a real need to provide the 'C' style structure for completeness.
Cheers,
Stu