Weird glGetError 1286

[User137]

I get this error 1286 when running my nxPascal framebuffer demo. It works fine, i see textured cube with framebuffer effect. Although i'd like to get rid of the error if possible.
GL_INVALID_FRAMEBUFFER_OPERATION = $0506; (1286 in dec)

I traced the error down to my model (cube) rendering at glDrawElements. Then in this link:
http://www.khronos.org/opengles/sdk/docs/man/xhtml/glDrawElements.xml

GL_INVALID_FRAMEBUFFER_OPERATION is generated if the currently bound framebuffer is not framebuffer complete (i.e. the return value from glCheckFramebufferStatus (http://www.khronos.org/opengles/sdk/docs/man/xhtml/glCheckFramebufferStatus.xml) is not GL_FRAMEBUFFER_COMPLETE).
And so i have checked that too before using glDrawElements with:

function TNXGL.CanRender: boolean;
begin
result:=glCheckFramebufferStatus(GL_FRAMEBUFFER)=G L_FRAMEBUFFER_COMPLETE;
end;
If checked CanRender at beginning of rendering loop, and if false, skip rest until window is ready to render, and it returned true.

Starting to be out of ideas... I can simply comment out the ShowMessage(...error here...), but then i won't have peace of mind :(

[LP]

This error means that frame buffers were not created correctly. Check this link (http://www.opengl.org/wiki/Framebuffer_Object) under "Framebuffer Completeness" section.

In some cases the application may apparently work as expected as certain OpenGL drivers try really hard to maintain functionality (typically Nvidia video cards), but it doesn't mean that everything is okay. Try running the same application on AMD and Intel video cards to see how it works.

If you could post the frame buffer's creation code, I'd take a look to see what's missing.

[User137]

I have Intel CPU and AMD video card :) Raden HD 5700.

The files are all available there, from SVN trunk:
http://code.google.com/p/nxpascal/source/browse/#svn%2Ftrunk%2Fsrc
Or now already bit outdated zip files of source and demos.

Window is created in nxGL.pas at line 606, and with fpc it uses TOpenGLContext, and functions from dglOpenGL. I get same error with Delphi 7 too though, which uses only dglOpenGL. (In both cases on a TForm)
http://code.google.com/p/nxpascal/source/browse/trunk/src/nxGL.pas

Also, the demo is doing the glDrawElements() while compiling a displaylist only, so it shouldn't actually be doing anything to framebuffer.

[LP]

Would you mind copying and posting FBO creation code here?


Also, the demo is doing the glDrawElements() while compiling a displaylist only, so it shouldn't actually be doing anything to framebuffer.
Are you rendering to the frame buffer? In other words, is frame buffer active while you call to glDrawElements? Because if not, errors could be propagating from FBO creation to rendering code.

Also, I'd suggest putting glGetError() after each call in FBO creation to see if some portion is not being created properly. Finally, you might want to comment the FBO section entirely, if it's not being used anyway.

[User137]

I commented out nearly all code now. Only these are executed:

in formCreate:
nx.CreateGlWindow(self);

in onTimer:
if cube=nil then begin
// Do glCheckFramebufferStatus
if not nx.CanRender then exit;

err:=glGetError();
if err>0 then ShowMessage(format('Model_before: glGetError, code: %d',[err]));

model:=TGLModel.Create;
model.LoadFromW3D('cube.w3d');
model.UseMaterials:=false;
model.MakeDisplayList(cube);
model.Free;

err:=glGetError();
if err>0 then ShowMessage(format('Model_after: glGetError, code: %d',[err]));
// Seen code 1286 (GL_INVALID_FRAMEBUFFER_OPERATION)

exit;
end;
I get only 1 messagedialog with "Model_after...1286".

So FBO is not being used at all, just rendering vertex array to displaylist. If i comment out "model.MakeDisplayList(cube);", then no error comes.

I also made a guide in the nxPascal wiki to show how to easily install the SVN version. It shouldn't take more than 1 minute if you already have SVN environment in your system, something like TortoiseSVN, or linux comparative. This whole demo is included there.

[LP]

It seems that you'll have to narrow the issue down within MakeDisplayList() itself. Try commenting lines one by one after which the error code disappears.

Other than that, the code is a bit difficult to understand. By the way, an unrelated note is that you may want to make plans to switch away from deprecated functionality (http://www.opengl.org/wiki/History_of_OpenGL#Deprecation_Model) such as display lists, which only make code more complicated, and client states (e.g. glEnableClientState/glDisableClientState calls).


I also made a guide in the nxPascal wiki to show how to easily install the SVN version. It shouldn't take more than 1 minute if you already have SVN environment in your system, something like TortoiseSVN, or linux comparative. This whole demo is included there.
It's not about installing SVN and updating from the trunk, but all that takes time, which means more time for doing unnecessary work and less time to analyze the code and help you. We're working 10 hours a day including weekends lately so free time is a luxury. :)

[User137]

I did some tests long ago about displaylists, and found that they draw faster than other methods. Idea is similar to compiled code and interpreted code, where you normally would have own rendering class code to manage materials, textures, polygon groups etc. With displaylist only "recorded" real rendering related actions are done, and you can free all the model data arrays from memory. There was always a performance gain even if just glDrawElements or glDrawArrays being the only call in the displaylist. Found VBO's much harder to use.

I'll see if i can narrow it further. I did go through the displaylist code though, things should be done in correct order. Also, would graphics be seen at all if there weren't clientstates? It seems to be standard way to use them
http://www.songho.ca/opengl/gl_vertexarray.html

Update: Narrowed it down to displaylist behavior. If i only draw the cube without using displaylist, no errors appear. Then when i executed glGetError after every line in displaylist creation code, it triggered exactly after glDrawElements().

I can't really find that anyone else would have ever used displaylist to draw vertexarrays. They're like exclusive methods. What i did find is
http://www.songho.ca/opengl/gl_displaylist.html

Note that not all OpenGL commands can be stored into the display lists. Since display list is a part of server state, any client state related commands cannot be placed in display list, for example, glFlush(), glFinish(), glRenderMode(), glEnableClientState(), glVertexPointer(), etc.
However even when i tried to move enable and disablestates outside of displaylist, it gave same error. So i suppose i have to stop using displaylist and vertexarray same time.

That has another interesting point:
http://www.opengl.org/archives/resources/faq/technical/displaylist.htm

However, in most implementations, there's also some memory that's needed to manage the display lists of a given context and other overhead. In certain pathological cases, this overhead memory can be larger than the memory used to store the display list data!

Now updated demos to SVN too. Case should be solved :) (I won't mix displaylists with vertexarrays now on.)

[LP]

I did some tests long ago about displaylists, and found that they draw faster than other methods. Idea is similar to compiled code and interpreted code, where you normally would have own rendering class code to manage materials, textures, polygon groups etc. With displaylist only "recorded" real rendering related actions are done, and you can free all the model data arrays from memory. There was always a performance gain even if just glDrawElements or glDrawArrays being the only call in the displaylist. Found VBO's much harder to use.
This is probably the case in outdated drivers or those that are no longer supported. In addition, if you explicitly request specific core functionality, in Core 3 and above, display lists won't be supported at all.


Also, would graphics be seen at all if there weren't clientstates? It seems to be standard way to use them
http://www.songho.ca/opengl/gl_vertexarray.html
You can replace client states with glVertexAttribPointer (http://www.opengl.org/sdk/docs/man/xhtml/glVertexAttribPointer.xml) and related glEnableVertexAttribArray (http://www.opengl.org/sdk/docs/man/xhtml/glEnableVertexAttribArray.xml). This would also imply using shaders as fixed-function pipeline is also deprecated in Core 3 and above.

P.S. The tutorial you linked uses deprecated functionality, not to mention that glEnableClientState is buggy in some drivers.

[User137]

That's alot to digest... Found a tutorial with little search:
http://www.opengl.org/wiki/Generic_Vertex_Attribute_-_examples
Would indeed mean using shaders for all 3D at least.

However deprecated they may be, do you believe they stop being added to drivers? It would mean many old games and graphical applications would stop functioning.

[LP]

Using programmable pipeline is not that difficult and it is unlikely that you are using large portion of FFP (fixed-function pipeline), so your shaders may end up being quite small and thus more efficient than using FFP; not to mention that you can do many more things in shaders and the code will be readily portable to OpenGL ES 2.0 (which has no FFP at all), should you decide to port to iOS/Android. There are many tutorials available (not to mention whole books) and you can always ask here. :)


However deprecated they may be, do you believe they stop being added to drivers? It would mean many old games and graphical applications would stop functioning.
On typical systems where it is already available in drivers - unlikely. However, it is also unlikely that legacy code will be actively maintained leading to potential bugs and unpredicted behavior. Also, there is always a risk that at some point OpenGL 3 (or for that matter, OpenGL ES 2) could become forcefully minimal standard, especially on new platforms. I mean, for how long do you think they will keep supporting and publishing 15 year old code? OpenGL 2.0, which introduced programmable pipeline, has been out for 8 years already, while DirectX had it for 10 years now (since DX8 ). FFP has been dropped out from DX10 (6 years ago), and out of OpenGL 3 (4 years ago).