Assert Fatal
by Howard Dortch · in Torque Game Engine · 04/25/2005 (8:11 am) · 5 replies
I was getting a program failure when I switched to camera mode after setting visibility to 800 and fog to 800. I rebuilt the engine in debug mode and ran. At the end of the mission lighting phase before the playgui got called I get this assert failure in GDI32.dll previous call was TerrainRender :: renderBlock(.
void* FrameAllocator::alloc(const U32 allocSize)
{
AssertFatal(smBuffer != NULL, "Error, no buffer!");
CRASH -> AssertFatal(smWaterMark + allocSize <= smHighWaterMark, "Error alloc too large, increase frame size!");
Data is :
smWaterMark = 0x002e3234
smHighWaterMark = 0x00300000
allocSize = 0x000282d0
Looks like allocSize + smWaterMark overflows the buffer.
Can anyone tell me what causes it and how to fix it?
My normal settings for fog is 300 and vis is 500 and I never had the error so I'm assuming the polycount for landscape exceeded the buffer size.
I was trying to fly up in the air and take a screen cap of the mission is how I found it.
void* FrameAllocator::alloc(const U32 allocSize)
{
AssertFatal(smBuffer != NULL, "Error, no buffer!");
CRASH -> AssertFatal(smWaterMark + allocSize <= smHighWaterMark, "Error alloc too large, increase frame size!");
Data is :
smWaterMark = 0x002e3234
smHighWaterMark = 0x00300000
allocSize = 0x000282d0
Looks like allocSize + smWaterMark overflows the buffer.
Can anyone tell me what causes it and how to fix it?
My normal settings for fog is 300 and vis is 500 and I never had the error so I'm assuming the polycount for landscape exceeded the buffer size.
I was trying to fly up in the air and take a screen cap of the mission is how I found it.
#2
- Brett
04/25/2005 (9:03 am)
First off, what are the values of the variables. I'm thinking those are the addresses of them? Secondly, what you see isn't in GDI32.dll, it's in the engine. The frame allocater, as I found out recently, is a memory pool that gets allocated temporarily, and in big chunks, then released when you're done. I guess the thing to look for is to troll back through the code and see how the values got set and to what.- Brett
#3
AssertFatal(smWaterMark + allocSize <= smHighWaterMark, "Error alloc too large, increase frame size!");
and hover the mouse over allocSize in VC 6 and it gives me values as low as 0x00000200, if thats an address we are all in trouble.
In Main.cc I changed this FrameAllocator::init(3 << 20); to FrameAllocator::init(6 << 20); as suggested and the frame rate went to 6.3 fps, I changed it to 4 and same thing. Seems 3 is a sweetspot probably video card limitation.
Step thru the code and I got odd numbers for land allocation and backtracked to the mission file I had the terrain square size set to 2 which is the reason the engine puked. Lots of polys trying to be rendered due to far clip plane set out so far.
I wanted more contour on the land since the square size at 8 gives me sharp edges and just looks ugly. So I guess I'll set the square to 8 for the pic for my map then reset to 2 for the game and be mindfull of the far clip distance.
Thanks for the help guys.....
04/25/2005 (9:22 am)
I set a breakpoint at AssertFatal(smWaterMark + allocSize <= smHighWaterMark, "Error alloc too large, increase frame size!");
and hover the mouse over allocSize in VC 6 and it gives me values as low as 0x00000200, if thats an address we are all in trouble.
In Main.cc I changed this FrameAllocator::init(3 << 20); to FrameAllocator::init(6 << 20); as suggested and the frame rate went to 6.3 fps, I changed it to 4 and same thing. Seems 3 is a sweetspot probably video card limitation.
Step thru the code and I got odd numbers for land allocation and backtracked to the mission file I had the terrain square size set to 2 which is the reason the engine puked. Lots of polys trying to be rendered due to far clip plane set out so far.
I wanted more contour on the land since the square size at 8 gives me sharp edges and just looks ugly. So I guess I'll set the square to 8 for the pic for my map then reset to 2 for the game and be mindfull of the far clip distance.
Thanks for the help guys.....
#4
TGE terrain uses exponentially more geometry as more "surface area" is rendered. Turning down the square size to 2, especially with a high view distance, is well-nigh suicidal in this regard - much like using only 4k x 4k textures in your game and wondering why a Voodoo2 doesn't run it well, or even at all.
You could try increasing the tesselation quality of the terrain, although such a change would involve intimate knowledge of the internals of the terrain code. :(
04/25/2005 (3:13 pm)
The FrameAllocator is just a big buffer of memory which can be portioned out, then reset, allowing rapid allocation of many small memory structures. It does not relate to the GPU or to anything else. It is fixed size to avoid costly reallocations (nevermind how one would update all the pointers if one did reallocate).TGE terrain uses exponentially more geometry as more "surface area" is rendered. Turning down the square size to 2, especially with a high view distance, is well-nigh suicidal in this regard - much like using only 4k x 4k textures in your game and wondering why a Voodoo2 doesn't run it well, or even at all.
You could try increasing the tesselation quality of the terrain, although such a change would involve intimate knowledge of the internals of the terrain code. :(
#5
As I said in my post I changed it for the pic, changed it back for the game and all is well. To get the nice look of a smothe terrain close up was a priority, the zone or mission area is rather small to contain the effect I was after. Now that I know where the boundry is, I can make a calculator for far clip for future reference. Thanks for your reply.
04/25/2005 (5:08 pm)
Yup big buffer, pre allocated, dole out chunks is the way to do that. Setting it to a larger size to render the exponentially increasing geometry (without crashing) dumps a ton of data on this meager vid card hence the reference to it's limits.As I said in my post I changed it for the pic, changed it back for the game and all is well. To get the nice look of a smothe terrain close up was a priority, the zone or mission area is rather small to contain the effect I was after. Now that I know where the boundry is, I can make a calculator for far clip for future reference. Thanks for your reply.
Torque Owner Mike Kuklinski