Unallocated Block
by Avid Gamer · in Torque Game Engine · 09/07/2007 (4:49 am) · 7 replies
Maybe I'm using this completely wrong, please let me know.
I have a small issue.
If i do the following:
Everything works as expected, until the engine closes. It then Asserts with "Block not allocated".
I never allocate mPath anywhere, so its true, the block is not allocated. I also, however, never try to free it. I'm curious as to where the engine auto frees things transfered in pack and unpack?
As a side note, everything works (and no Assert) if i change unpack to:
I have read many, many books on C++, and have devoted many hours to learning the topic. However, I consider myself a beginer. Any enlightenment would be awesome.
I have a small issue.
If i do the following:
...in packUpdate if(stream->writeFlag(mPath.size())) stream->write(sizeof(Vector<Point3F>),&mPath); ...in unpackUpdate if(stream->readFlag()) stream->read(sizeof(Vector<Point3F>),&mPath);
Everything works as expected, until the engine closes. It then Asserts with "Block not allocated".
I never allocate mPath anywhere, so its true, the block is not allocated. I also, however, never try to free it. I'm curious as to where the engine auto frees things transfered in pack and unpack?
As a side note, everything works (and no Assert) if i change unpack to:
if(stream->readFlag())
{
Vector<Point3F> *path = new Vector<Point3F>;
stream->read(sizeof(Vector<Point3F>),(Vector<Point3F>*)path);
mPath = *path;
}I have read many, many books on C++, and have devoted many hours to learning the topic. However, I consider myself a beginer. Any enlightenment would be awesome.
About the author
I'm enthusiastic about learning new things and love to make things work.
#2
I've never ever written (to a stream) a Vector of Point3F's like that and I was under the impression it wasn't valid since the write method wasn't overloaded for Vectors.
09/10/2007 (2:06 am)
Are you sure the second example will work practically and not just run?I've never ever written (to a stream) a Vector of Point3F's like that and I was under the impression it wasn't valid since the write method wasn't overloaded for Vectors.
#3
That is not going to write your vector to the stream. For starters, Vector is a dynamically sized array, and sizeof is handled at compile time. That'll write the first x bytes of mPath to the stream, where x is however large a Vector is (probably around 12 bytes or some such).
What you might want to try is
That second stream->write might have to be replaced with stream->mathWrite.
In unpack update you'd have
Again, you might have to replace the second stream->read with stream->mathRead.
What your code is doing is writing the pointer to the stream instead of the actual data. This is guaranteed to crash if the client and server are not the same process, and if the server deletes the data will crash even if you are running in single player. Your second approach has the same problem, and also has a memory leak because you don't delete the Vector you new'd.
09/10/2007 (2:27 am)
if(stream->writeFlag(mPath.size())) stream->write(sizeof(Vector<Point3F>),&mPath);
That is not going to write your vector to the stream. For starters, Vector is a dynamically sized array, and sizeof is handled at compile time. That'll write the first x bytes of mPath to the stream, where x is however large a Vector
What you might want to try is
stream->write(mPath.size()); for(U32 i = 0; i < mPath.size(); i++) stream->write(&mPath[i]);
That second stream->write might have to be replaced with stream->mathWrite.
In unpack update you'd have
mPath.clear();
U32 arraySize;
Point3F pt;
stream->read(&arraySize);
for(U32 i = 0; i < arraySize, i++)
{
stream->read(&pt);
mPath.push_back(pt);
}Again, you might have to replace the second stream->read with stream->mathRead.
What your code is doing is writing the pointer to the stream instead of the actual data. This is guaranteed to crash if the client and server are not the same process, and if the server deletes the data will crash even if you are running in single player. Your second approach has the same problem, and also has a memory leak because you don't delete the Vector you new'd.
#4
I had it doing the stream->write(mPath.size()); and the for loop before hand, however the size of the array gets large at times and i would see a huge decrease in speed. So is my best option to just create a client side only version or what needs to be drawn?
Thankyou for your feedback.
09/10/2007 (2:37 am)
Thankyou. Basically what your saying is that because im trasnfering addressess and since server/client are on the same computer it works. I had it doing the stream->write(mPath.size()); and the for loop before hand, however the size of the array gets large at times and i would see a huge decrease in speed. So is my best option to just create a client side only version or what needs to be drawn?
Thankyou for your feedback.
#5
1) Make sure it's all current data. If you're forgetting to clear the vector when necessary then you're resending old worthless data.
2) Don't send the same set of data twice. Maybe track what points have been sent and what haven't, and only send updates.
3) Do everything client side and cut data transfer out of the equation entirely.
4) Cap the amount of data which can be sent. For example, PathCamera will only hold up to twenty positions on it's path. If you add another position after the twentieth, it'll delete the first.
5) Combinations of the above.
6) Anything else you can think of.
For extra fun, try them all! Call it a "learning experience".
09/10/2007 (2:47 am)
There are a variety of ways you can deal with too much data.1) Make sure it's all current data. If you're forgetting to clear the vector when necessary then you're resending old worthless data.
2) Don't send the same set of data twice. Maybe track what points have been sent and what haven't, and only send updates.
3) Do everything client side and cut data transfer out of the equation entirely.
4) Cap the amount of data which can be sent. For example, PathCamera will only hold up to twenty positions on it's path. If you add another position after the twentieth, it'll delete the first.
5) Combinations of the above.
6) Anything else you can think of.
For extra fun, try them all! Call it a "learning experience".
#6
Thankyou much for your help :)
09/10/2007 (2:50 am)
Hehe thanks. I've done most of those. Clearing the vector, client side only, same data is never sent twice, only thing i have yet to try is cap the amount. I think that will be the best solution. Thankyou much for your help :)
#7
This was my last ditch effort at making the performance acceptable before i ditched the idea. When i did the pointer thing, the change was so huge that i thought i must be doing something wrong. With the number cap it works perfectly.
Again, thank you very much :)
09/10/2007 (4:26 am)
Huge difference. Thankyou so much. This was my last ditch effort at making the performance acceptable before i ditched the idea. When i did the pointer thing, the change was so huge that i thought i must be doing something wrong. With the number cap it works perfectly.
Again, thank you very much :)
Torque 3D Owner Avid Gamer
Any response would be great.