Weird glGetError 1286

[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 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/resou...isplaylist.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 and related glEnableVertexAttribArray. 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_V...ute_-_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).