TGEA 1.7.0 error: Error alloc too large, increase frame size
by Jack Stone · in Torque Game Engine Advanced · 06/15/2008 (5:19 pm) · 4 replies
I'm working on porting 2 different projects to 1.7.0. The first one went over fine, however I ran into the following problem while porting the second project.
Whenever I try to run a mission, I encounter an assert in line 78 of frameallocator.h:
"smWaterMark + _allocSize <= smHighWaterMark, "Error alloc too large, increase frame size!"
I did a search, and apparently this has something to do with the view distance being set too high, and too much terrain being processed. I don't think this is the case with my problem however, because I get this bug on every single one of my missions, including the simple testbed mission, even with the terrain blocks removed! (In fact I removed everything from the simple testbed mission except the player drop point, the sun, and the sky, and still got the assert).
When debugging, I noticed that the smWaterMark variable is zero, which is obviously what triggers the assert. (And also why increasing the TORQUE_FRAME_SIZE from 6 << 20 doesn't work)
However I can't figure out why that smWatermark variable is 0, and why I didn't get this error with my other project.
I would assume it's because I haven't initialised something properly, that 1.7.0 needs? I tried comparing the two log files, from the working and non-working projects, and couldn't see any relevant differences at all.
The last line before the assert is just something about "collision detail 1 (Collision-1) bounds exceed that of shape.", which I have got a few of in both projects, and it never caused a problem before.
I would appreciate any advice,
Jack
Whenever I try to run a mission, I encounter an assert in line 78 of frameallocator.h:
"smWaterMark + _allocSize <= smHighWaterMark, "Error alloc too large, increase frame size!"
I did a search, and apparently this has something to do with the view distance being set too high, and too much terrain being processed. I don't think this is the case with my problem however, because I get this bug on every single one of my missions, including the simple testbed mission, even with the terrain blocks removed! (In fact I removed everything from the simple testbed mission except the player drop point, the sun, and the sky, and still got the assert).
When debugging, I noticed that the smWaterMark variable is zero, which is obviously what triggers the assert. (And also why increasing the TORQUE_FRAME_SIZE from 6 << 20 doesn't work)
However I can't figure out why that smWatermark variable is 0, and why I didn't get this error with my other project.
I would assume it's because I haven't initialised something properly, that 1.7.0 needs? I tried comparing the two log files, from the working and non-working projects, and couldn't see any relevant differences at all.
The last line before the assert is just something about "collision detail 1 (Collision-1) bounds exceed that of shape.", which I have got a few of in both projects, and it never caused a problem before.
I would appreciate any advice,
Jack
#2
Thanks for your advice.
Btw, I'm a little unclear about the "16 << 20" syntax. What is the "<<" operator doing? Does that mean the number on the left cannot be greater than 20?
06/16/2008 (3:28 pm)
I changed the TORQUE_FRAME_SIZE to 20 << 20, and it seemed to solve the problem. I think the reason it wasn't working before is because I didn't do a full rebuild after I changed that variable. Thanks for your advice.
Btw, I'm a little unclear about the "16 << 20" syntax. What is the "<<" operator doing? Does that mean the number on the left cannot be greater than 20?
#3
06/16/2008 (4:04 pm)
"<<" is the bit shift operator. It takes the number on the left and shifts its bits to the "left" a number of times equal to the number on the right. It is an extremely quick way to multiply a number by anything evenly divisible by 2.
#4
06/16/2008 (6:48 pm)
Thanks Mark, that makes sense now. I had heard of bit shifting, but I'd never seen it in code before.
Torque Owner Stefan Lundmark
Try this:
Should work just fine. Play around with the leftmost value if you want higher.