4.1 bug on building in debug (vc2003)
by Phil Carlisle · in Torque Game Engine Advanced · 11/10/2006 (11:10 am) · 6 replies
I built the engine and ran it as debug (build with VC2003) and when the Orc is due to come into the scene, there is an Assert with a failure in:
allocVertexBuffer.
Tracing through it, it seems that sgShadowProjector::sgClear() the call to sgShadowBuffer.set is somehow
causing a buffer allocation to fail. It APPEARS as though the only parameter that could cause the fail, is the 0 for numverts??
Basically, that call to clear is allocating a buffer of 0 verts. Which is a bit wasteful?
Console log doesnt give any clearer picture. Error is
Scene WelcomeScene open
Static Camera
Mapping string: MissionStart to index: 11
Mapping string: SyncClock to index: 12
Mapping string: SetGameGUI to index: 13
*** Initial Control Object
Activating DirectInput...
keyboard0 input device acquired.
Mapping string: Tarkof to index: 14
Fatal: (d:\torque-projects\tse_ms4_1\engine\gfx\d3d\gfxd3ddevice.h @ 23) D
I
Failed to allocate VB
Anyway, here is the call stack.
TSE_DEBUG.exe!Platform::debugBreak() Line 15 + 0x8 C++
TSE_DEBUG.exe!PlatformAssert::process(PlatformAssert::Type assertType=Fatal, const char * filename=0x00d10280, unsigned int lineNumber=23, const char * message=0x0012dc40) Line 89 C++
TSE_DEBUG.exe!PlatformAssert::processAssert(PlatformAssert::Type assertType=Fatal, const char * filename=0x00d10280, unsigned int lineNumber=23, const char * message=0x0012dc40) Line 109 + 0x23 C++
TSE_DEBUG.exe!D3DAssert(HRESULT hr=-2005530516, const char * info=0x00d107f4) Line 23 + 0x26 C++
> TSE_DEBUG.exe!GFXD3DDevice::allocVertexBuffer(unsigned int numVerts=0, unsigned int vertFlags=18, unsigned int vertSize=24, GFXBufferType bufferType=GFXBufferTypeStatic) Line 1493 + 0x5f C++
TSE_DEBUG.exe!GFXVertexBufferHandleBase::set(GFXDevice * theDevice=0x0191ff50, unsigned int numVerts=0, unsigned int flags=18, unsigned int vertexSize=24, GFXBufferType type=GFXBufferTypeStatic) Line 14 + 0x1d C++
TSE_DEBUG.exe!GFXVertexBufferHandle::set(GFXDevice * theDevice=0x0191ff50, unsigned int numVerts=0, GFXBufferType t=GFXBufferTypeStatic) Line 99 C++
TSE_DEBUG.exe!sgShadowProjector::sgClear() Line 147 C++
TSE_DEBUG.exe!sgShadowProjector::sgSetupShadowType() Line 185 C++
TSE_DEBUG.exe!sgShadowProjector::sgRender(float camdist=6.2529731) Line 574 C++
TSE_DEBUG.exe!sgObjectShadows::sgRender(SceneObject * parentobject=0x07ad6588, TSShapeInstance * shapeinstance=0x07ad6f78, float camdist=6.2529731) Line 307 + 0x11 C++
TSE_DEBUG.exe!ShapeBase::renderShadow(SceneState * state=0x03330af4, RenderInst * ri=0x08f149ac) Line 2435 C++
TSE_DEBUG.exe!RenderObjectMgr::render() Line 17 + 0x23 C++
TSE_DEBUG.exe!RenderInstManager::render() Line 285 + 0x2a C++
TSE_DEBUG.exe!SceneState::renderCurrentImages() Line 144 C++
TSE_DEBUG.exe!SceneGraph::traverseSceneTree(SceneState * pState=0x03330af4) Line 364 C++
TSE_DEBUG.exe!SceneGraph::renderScene(const unsigned int objectMask=4294967295) Line 190 C++
TSE_DEBUG.exe!GameRenderWorld() Line 1026 C++
TSE_DEBUG.exe!GameTSCtrl::renderWorld(const RectI & updateRect={...}) Line 42 C++
allocVertexBuffer.
Tracing through it, it seems that sgShadowProjector::sgClear() the call to sgShadowBuffer.set is somehow
causing a buffer allocation to fail. It APPEARS as though the only parameter that could cause the fail, is the 0 for numverts??
Basically, that call to clear is allocating a buffer of 0 verts. Which is a bit wasteful?
Console log doesnt give any clearer picture. Error is
Scene WelcomeScene open
Static Camera
Mapping string: MissionStart to index: 11
Mapping string: SyncClock to index: 12
Mapping string: SetGameGUI to index: 13
*** Initial Control Object
Activating DirectInput...
keyboard0 input device acquired.
Mapping string: Tarkof to index: 14
Fatal: (d:\torque-projects\tse_ms4_1\engine\gfx\d3d\gfxd3ddevice.h @ 23) D
I
Failed to allocate VB
Anyway, here is the call stack.
TSE_DEBUG.exe!Platform::debugBreak() Line 15 + 0x8 C++
TSE_DEBUG.exe!PlatformAssert::process(PlatformAssert::Type assertType=Fatal, const char * filename=0x00d10280, unsigned int lineNumber=23, const char * message=0x0012dc40) Line 89 C++
TSE_DEBUG.exe!PlatformAssert::processAssert(PlatformAssert::Type assertType=Fatal, const char * filename=0x00d10280, unsigned int lineNumber=23, const char * message=0x0012dc40) Line 109 + 0x23 C++
TSE_DEBUG.exe!D3DAssert(HRESULT hr=-2005530516, const char * info=0x00d107f4) Line 23 + 0x26 C++
> TSE_DEBUG.exe!GFXD3DDevice::allocVertexBuffer(unsigned int numVerts=0, unsigned int vertFlags=18, unsigned int vertSize=24, GFXBufferType bufferType=GFXBufferTypeStatic) Line 1493 + 0x5f C++
TSE_DEBUG.exe!GFXVertexBufferHandleBase::set(GFXDevice * theDevice=0x0191ff50, unsigned int numVerts=0, unsigned int flags=18, unsigned int vertexSize=24, GFXBufferType type=GFXBufferTypeStatic) Line 14 + 0x1d C++
TSE_DEBUG.exe!GFXVertexBufferHandle
TSE_DEBUG.exe!sgShadowProjector::sgClear() Line 147 C++
TSE_DEBUG.exe!sgShadowProjector::sgSetupShadowType() Line 185 C++
TSE_DEBUG.exe!sgShadowProjector::sgRender(float camdist=6.2529731) Line 574 C++
TSE_DEBUG.exe!sgObjectShadows::sgRender(SceneObject * parentobject=0x07ad6588, TSShapeInstance * shapeinstance=0x07ad6f78, float camdist=6.2529731) Line 307 + 0x11 C++
TSE_DEBUG.exe!ShapeBase::renderShadow(SceneState * state=0x03330af4, RenderInst * ri=0x08f149ac) Line 2435 C++
TSE_DEBUG.exe!RenderObjectMgr::render() Line 17 + 0x23 C++
TSE_DEBUG.exe!RenderInstManager::render() Line 285 + 0x2a C++
TSE_DEBUG.exe!SceneState::renderCurrentImages() Line 144 C++
TSE_DEBUG.exe!SceneGraph::traverseSceneTree(SceneState * pState=0x03330af4) Line 364 C++
TSE_DEBUG.exe!SceneGraph::renderScene(const unsigned int objectMask=4294967295) Line 190 C++
TSE_DEBUG.exe!GameRenderWorld() Line 1026 C++
TSE_DEBUG.exe!GameTSCtrl::renderWorld(const RectI & updateRect={...}) Line 42 C++
About the author
Recent Threads
#2
If you change the code on line 23 in gfxD3DDevice.h from
It will call the ascii versions of the error strings and instead of getting the error message as "D I" it willl give you the whole message.
Todd
edit - Oh, and I'm getting the same assert, so it is doubly confirmed. :)
11/17/2006 (1:47 pm)
On a related note,If you change the code on line 23 in gfxD3DDevice.h from
dSprintf( buf, 256, "%s\n%s\n%s", DXGetErrorString9( hr ), DXGetErrorDescription9( hr ), info );to
dSprintf( buf, 256, "%s\n%s\n%s", DXGetErrorString9A( hr ), DXGetErrorDescription9A( hr ), info );
It will call the ascii versions of the error strings and instead of getting the error message as "D I" it willl give you the whole message.
Todd
edit - Oh, and I'm getting the same assert, so it is doubly confirmed. :)
#3
I think this bug is pretty easy to fix...but there is a second bug in the same code.
First, this assert is caused by line 144 in sgObjectBasedProjector.cc:
Loooking through the code, I believe that all we need to do here is comment out this line.
However, once I made that change, the code hit another (unrelated) assert.
The second assert is hit when we try to set the sgShadowTexture as the active render target. The debug code verifies that the sgShadowTexture is not currently a sampler texture and the code fails the assert.
This one was slightly more tricky to track down. I'll try to explain it well....
The problem happens in sgRender if sgShadowPolys is empty.
Here is the sequence of events in sgRender:
1) sgShadowTexture is set as a texture sampler (Note: this marks the texture for that stage as dirty but does not set the texture for that stage yet. So, the current texture for that stage is still NULL. The texture will actually be set when the drawprimitive call happens.)
2) sgShadowPolys is empty, so drawPrimitive() never gets called, so the textures for the stages never get set.
3) the texture stage is set to NULL. (However, since the sgShadowTexture was never actually set, the current texture stage is still NULL, so this call does nothing!)
4) We attempt to set the sgShadowTexture as the active texture in a future call, however, since the drawprimitive call never happened, the sgShadowTexture is still in the GFX "pending textures list" (which is called mNewTexture). Thus, it fails the assert.
I hope this was clear.
I'm not really sure how I should fix this, but I am guessing that if sgShadowPolys is empty, we should be doing an early out before any of this stuff happens.
Thanks
Todd
-edit for clarity
11/17/2006 (2:42 pm)
Ok,I think this bug is pretty easy to fix...but there is a second bug in the same code.
First, this assert is caused by line 144 in sgObjectBasedProjector.cc:
sgShadowBuffer.set(GFX, 0, GFXBufferTypeStatic);
Loooking through the code, I believe that all we need to do here is comment out this line.
However, once I made that change, the code hit another (unrelated) assert.
The second assert is hit when we try to set the sgShadowTexture as the active render target. The debug code verifies that the sgShadowTexture is not currently a sampler texture and the code fails the assert.
This one was slightly more tricky to track down. I'll try to explain it well....
The problem happens in sgRender if sgShadowPolys is empty.
Here is the sequence of events in sgRender:
1) sgShadowTexture is set as a texture sampler (Note: this marks the texture for that stage as dirty but does not set the texture for that stage yet. So, the current texture for that stage is still NULL. The texture will actually be set when the drawprimitive call happens.)
2) sgShadowPolys is empty, so drawPrimitive() never gets called, so the textures for the stages never get set.
3) the texture stage is set to NULL. (However, since the sgShadowTexture was never actually set, the current texture stage is still NULL, so this call does nothing!)
4) We attempt to set the sgShadowTexture as the active texture in a future call, however, since the drawprimitive call never happened, the sgShadowTexture is still in the GFX "pending textures list" (which is called mNewTexture). Thus, it fails the assert.
I hope this was clear.
I'm not really sure how I should fix this, but I am guessing that if sgShadowPolys is empty, we should be doing an early out before any of this stuff happens.
Thanks
Todd
-edit for clarity
#4
The second problem I mentioned above, occured because I had a shapebase object with "shadowEnable = true" but with no shadow geometry. When I set that to false, the second assert was not hit.
I'll probably put in some warning message to bettter ferret out this kind of asset error....
Thanks
Todd
edit - The above isn't quite right. If I set shaowEnable = false, I don't hit the assert. That part is right. But I still haven't figured out why shadowpolys is empty....
11/17/2006 (6:13 pm)
One more followup....The second problem I mentioned above, occured because I had a shapebase object with "shadowEnable = true" but with no shadow geometry. When I set that to false, the second assert was not hit.
I'll probably put in some warning message to bettter ferret out this kind of asset error....
Thanks
Todd
edit - The above isn't quite right. If I set shaowEnable = false, I don't hit the assert. That part is right. But I still haven't figured out why shadowpolys is empty....
#5
11/28/2006 (10:33 am)
Is there anymore info on this?
#6
----
GFXVertexBuffer * GFXD3DDevice::allocVertexBuffer( U32 numVerts, U32 vertFlags, U32 vertSize, GFXBufferType bufferType )
{
GFXD3DVertexBuffer * res = new GFXD3DVertexBuffer(this, numVerts, vertFlags, vertSize, bufferType);
// Determine usage flags
U32 usage = 0;
D3DPOOL pool; // = 0;
res->mNumVerts = 0;
if(numVerts == 0) {
return res;
}
// Assumptions:
...
12/04/2006 (5:12 pm)
To work around it (kinda hackish), we simply checked for 0 numVerts and returned the buffer:----
GFXVertexBuffer * GFXD3DDevice::allocVertexBuffer( U32 numVerts, U32 vertFlags, U32 vertSize, GFXBufferType bufferType )
{
GFXD3DVertexBuffer * res = new GFXD3DVertexBuffer(this, numVerts, vertFlags, vertSize, bufferType);
// Determine usage flags
U32 usage = 0;
D3DPOOL pool; // = 0;
res->mNumVerts = 0;
if(numVerts == 0) {
return res;
}
// Assumptions:
...
Torque Owner Kevin Johnson
console.log
error in debug build only release is fine.
removing the D3DAssert in gfxd3ddevice.cpp ~1492 clears it up -
not a perm fix but if anyone else comes accross it , this should get the debug build back running
;)