// - Update client subsystem for rendering, audio and input
void Client::Tick( void )
{
// - Viewport rendering goes here
// - Update each viewport opened
for( int i = 0; i < nViewports; i++ )
{
assert( viewport ); // - Won't crash
// - Clear viewport and set view
render->preCompute( viewport );
assert( viewport ); // - Will crash
viewport->tick( ); // - Crashes also
// - Do something like a screen flash
render->postCompute( viewport );
}
}
Author
Hi there,
i've got a little problem using pointers and i don't know how to handle that.
There's only one thing happening between the valid assert and the invalid assert so please post the code of preCompute as well. Perhaps it does not do what you think it does.
Illco
Illco
Author
// - RenderDevice OpenGL implementationvoid RenderDevice::preCompute( Viewport *viewport ){ // - This is for function-call-backtrace guard( RenderDevice::preCompute ); assert( viewport ); glViewport( viewport->x, viewport->y, viewport->w, viewport->h ); glClear( ClearFlags ); glMatrixMode( GL_PROJECTION ) glLoadIdentity( ); // - This could be wrong glFrustum( -1.f, 1.f, -1.f, 1.f, viewport->nearZ, viewport->farZ ); glMatrixMode( GL_MODELVIEW ); glLoadIdentity( ); glRotatef( viewport->yaw, 1.f, 0.f, 0.f ); glRotatef( viewport->roll, 0.f, 1.f, 0.f ); glRotatef( viewport->pitch, 0.f, 0.f, 1.f ); // - Viewport object will exist until here return; unguard( );}[Edited by - S0n0 on October 21, 2005 6:10:03 AM]
Well, your
assert( viewport ); // - Won't crash
Does the assert() fail or does it actually crash? If it fails, the viewport pointer is NULL so you can make your debugger watch that memory address for changes. If it crashes, then I guess the viewport pointer is invalid and you should watch that instead.
I am not familiar with the guard() and unguard() functions, but one thing I noticed is that the call to unguard() is after the return; line, so it never gets executed. Could that be the problem?
Author
the assert is valid, means viewport is non-null. everything i know is that i never modified the data where viewport points to.
the guard- and unguard-statements are macros implementing try and catch.
an assert will throw an exception catched by the catch-directive after return.
the guard function will push the current function's name onto the stack. Is the function's name out of scope (means function has been left) the name will be popped. If an assertion fails it will throw an exception right to the unguard-statement which rewinds the stack and shows me a backtrace (which functions have been called and what happend in which file and line)
the guard- and unguard-statements are macros implementing try and catch.
an assert will throw an exception catched by the catch-directive after return.
the guard function will push the current function's name onto the stack. Is the function's name out of scope (means function has been left) the name will be popped. If an assertion fails it will throw an exception right to the unguard-statement which rewinds the stack and shows me a backtrace (which functions have been called and what happend in which file and line)
Well, are you sure your function/class declarations are consistent? Do you have compiler warnings turned on?
Also, have you tried a "clean" or "make clean" or whatever based on your build environment? Sometimes cleaning up can help weird bugs like this sometimes :)
Also, have you tried a "clean" or "make clean" or whatever based on your build environment? Sometimes cleaning up can help weird bugs like this sometimes :)
Author
thanks for the 'clean' advice, i will try, but do you mean with consistency of function/class?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
