OpenGL 3.1 Talk Preview at PyGTA on Tuesday
Written by
on
in
Snaking.
It's official, I'm abusing my position as PyGTA convener to practice my other PyCon presentation on people. I am a very naughty boy. As I've been working on the OpenGL presentation I'm leaning further and further toward just teaching the 3.1 feature-set as "something to understand" and then just covering the migration to 3.1 as a side topic. The "how it all fits together" feels kinda silly when 90% of OpenGL 2.x and below is just tossed out at the last step (admittedly with mappings to the new, generic operations).
Need to get another day to fix bugs as well before Tuesday. I have a drop-dead deadline before I head off to PyCon as well, so it'll be tight, but that's what caffeine is for.
I'm rather excited about both talks, though I have to admit that I'm more excited about the OpenGL one. I think that's because it's "crystalized" already, while the profiling one feels like it needs feedback from real beginners to really know which questions they'll ask. Luckily that's happening tomorrow night :) .
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
adam on 03/12/2009 1:43 p.m. #
I found a problem with the new 'PyOpenGL-Demo'. The 'lesson48/__init__.py' is missing the closing quotes!
I would also recommend that you leave the immediate mode functions in as deprecated to ensure that it conforms to the full OpenGL spec and not just advanced features. It allows those that are new to OpenGL to learn from things such as the 'Red Book' and 'Blue Book' gradually. Even if they work slower now due to the new ctypes use I believe it to be a bad idea to completely remove those features.
Mike Fletcher on 03/12/2009 2:07 p.m. #
Thanks for the bug report, will look into that.
As for removing the functionality, *PyOpenGL* will continue to have the entry points if they are available on your machine. But your *driver* is going to drop the entry points as we move forward.
An OpenGL 3.1 driver won't have the old OpenGL entry points any more. The GPU makers want to drop the complexity of the OpenGL legacy mechanisms.
What I was referring to above, however, was de-emphasizing how to move your PyOpenGL legacy code to legacy-free behaviour and instead teaching the legacy-free behaviour with the transition process as a secondary topic.