Should make the VBO objects act as arrays if no implementation
Written by
on
in
Snaking.
As I'm going through the (rather mechanical) process of eliminating the deprecated OpenGL functionality from OpenGLContext, I'm discovering something I hadn't thought about before, when I was on the library providing side. Namely that most of the time what you really want to do is to create the VBO and if there's no implementation, still pass it off to the back-end as a regular OpenGL 1.1 era array. The implementation currently forces you to decide whether to use VBOs at the application level, which makes for lots of "if vbo.get_implementation():" lines, or code that won't gracefully degrade on older hardware.
Tomorrow I'm thinking I'll rework the font sub-package, which uses the traditional one-quad-per-character approach. There's a recent thread on Pygame users where a new user created a sprite engine using VBOs that they found was faster than their original display-list-based version (yay "fast path" rendering). Fonts are somewhat more bookkeeping, but it should be the same basic operation, sort into same-texture sets, render each set. Of course, that means you may render two adjacent characters with two different calls, but oh well.
One thing I remembered this evening that I need to remind people about in the presentation: no more selection render mode. Someone realized that just using object-space queries on your spatial tree is way faster than rendering a scene, and the math to do a point-plane intersection isn't all *that* complex. So people who did selection "the right way" now have to redo it :) .
I've been seriously tempted to make OpenGLContext "legacy free", but since the presentation is about how to migrate slowly and carefully I guess we'll stick with mixed functionality... though as mentioned in the first paragraph, that would be easier if a VBO would pass its underlying array in if there's no implementation available...
Pingbacks
Pingbacks are closed.
Comments
Comments are closed.