Main Menu

checkGLError()

Started by Qudus, January 12, 2008, 02:28:38

Previous topic - Next topic

Qudus

Could you please improve the checkGLError() method by making it check, if the all data buffers are properly setup, if they are enabled?

It is very hard to track bugs of such kind, if the VM simply crashes when the drawing functions is called and the buffers are not correctly setup.

Thanks.

Marvin

Matzon

I am not sure that it is possible. We dont have a reference to all of the buffers, and getting one every checkGLError might be very expensive

Qudus

Quote from: Matzon on January 12, 2008, 12:04:08
I am not sure that it is possible. We dont have a reference to all of the buffers, and getting one every checkGLError might be very expensive

Well, Then maybe a second check method in the Util class would do the trick, which the user can call just in the debugging case. Expensiveness would then be less important.

Or is it possible to avoid the VM crashes in another way?

Marvin

Matthias

Hi,

you can even crash the VM if you setup all VA buffers (not VBO) correctly but try to render more primitives then the buffer contains. And this can't be checked because the number is only available at draw time.

The best solution for this is to create a geometry abstraction class that will setup and render 3d models so that the VA related code is in only one place.

Ciao Matthias

Qudus

Quote from: Matthias on January 12, 2008, 15:01:32
you can even crash the VM if you setup all VA buffers (not VBO) correctly but try to render more primitives then the buffer contains. And this can't be checked because the number is only available at draw time.

Well, it makes sense, that you can't check this. But why does it necessarily crash the VM?

Quote from: Matthias on January 12, 2008, 15:01:32
The best solution for this is to create a geometry abstraction class that will setup and render 3d models so that the VA related code is in only one place.

Of course I already have this ;). But it was buggy. And I had a hard time to track this bug because of the VM crash, which on Linux doesn't occurr consistently, but only sometimes.

Marvin