> > I was able to read through those changes in your pyglet fork over the > weekend. Unfortunately, I'm still weak in my understanding of both OpenGL > and Cocoa (and especially where they deal with eachother). Would you > expect these changes to fix the a-window-never-appears problem with system > python on 10.8.x? I'll try to get around to testing your code on my setup > later today. >
These code changes are simply to get the OpenGL Core profile working on OS-X. I believe it works on Windows / Linux (I just ran my core examples with no changes on Ubuntu). I don't experience the problem with the window not showing, and these changes aren't aimed at that problem so I highly doubt these changes will help. I don't expect them to be pulled verbatim into pyglet. But they work, so someone with more knowledge of the code base should be able to look into why they work and how to integrate it cleanly =) > > >> I also monkey patch the window at run time: >> >> https://github.com/adamlwgriffiths/PyGLy/blob/master/pygly/gl/core/__init__.py >> >> And disable the shadow window as suggested by another user who created >> the original cocoa patch: >> >> https://github.com/adamlwgriffiths/PyGLy/blob/master/examples/core/window_creation/main.py >> >> >> But I am unable to use any of the pyglet wrappers such as vertex_list or >> Label due to the use of Legacy profile code. >> >> I'm happy to begin modifying these to patch out the legacy code. >> But I want some feedback on how this should be done. >> I don't want to maintain a branch of pyglet. I'd rather any changes could >> eventually be integrated. >> > > Perhaps someone with commit rights could comment here. > > >> Now that core works, I'm at the point where I either write my own simple >> wrappers (very tempting as I don't want anything heavy weight), or I help >> fix pyglet up. >> >> > Help fix pyglet up! > > > >> My question is this: >> Does anyone have any thoughts on how this should be done? >> My thoughts at the moment are to make the legacy calls optional. By >> detecting if we're running in Core profile with no compatibility, we can >> 'if' most of these statements out. >> Is there any simple way to do this? Is there a boolean somewhere? >> > > I wish I fully understood what "Core profile" really means, and how that > translates to Linux and Windows. Does it simply mean a different version > of OpenGL? If it does, then some global approach to addressing how to > support multiple versions of OpenGL across all the platforms should > probably be discussed - right? Along with some new facility for listing & > choosing your OpenGL version... > > What does pyglet do now? Try to use the same version of OpenGL across > platforms, with the helper objects hard-coded to use that version of OpenGL? > > Am I on the right track, or have I missed some fundamental point, here? > OpenGL 2.1 and below are considered legacy and use the fixed function pipeline. This was pre-shaders being core to opengl. To get fancy effects you had to set a lot of state and do some tricky things with stencil buffers, etc to get opengl to do what you want. Shaders changed that. OpenGL 3 broke away from the fixed function by replacing almost _everything_ with shaders. There is no matrix stack, no push / pop functionality. And you _need_ shaders to render _anything_. It's a big change, and it breaks a lot of existing functionality. So they implemented a compatibility mode... well... the vendors did. So you can run fixed function logic along side core logic. But OS-X doesn't seem to support this. At least from the way pyglet is running. I may be wrong. OS-X also only supports either, 2.1 legacy, or 3.2 (OpenGL is up to 4 now). So it's very.... strict.... for lack of a better word. Pyglet already lets you select the opengl version you want in the gl config class that you pass to Window. You use the major_version and minor_version (3,2 for core 3.2). But on OS-X, this value is ignored. At least in vanilla pyglet. Hence the patch to read and process these. The problem I have is that classes like Label and vertex_list use fixed function calls such as glPushClientAttrib, glPushAttrib. These are (unfortunately) gone in the core profile. The best way I can think of getting around it, is to either monkey patch the code, or add a tonne of 'if core_profile and pure' statements to avoid these calls. But that's pretty messy =/ I can get things rendering in the core profile, but only using pure opengl calls. The pyglet wrappers will cause gl exceptions due to unsupported functionality being used. It's not a trivial job. Even in my project, trying to provide a single code path for legacy and core.... I just can't see one without scattering global variables all over the place to store matrix stacks and what not. And that really defeats the purpose of the core profile. Then there's also backward compatibility to think about. I don't think people would like it if they had to update existing code to keep it working. It's pretty confusing =/ Cheers, Adam -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
