On your place, i would simply throw out the code section which tries to create a software renderer (where NewGWorld function is used).
} else { /* software renderer; attach offscreen buffer to context */ ....<remove everything> ... goto FAILED; }
IMO, B3DAcceleratorPlugin is fairly obsolete and very basic. And i think it would be better to deprecate it and use something else instead.
Because there's a lot of various options, like choosing different pixel format, double buffering etc etc, when creating OpenGL rendering context, and B3DAcceleratorPlugin supporting only subset of them. It also serves as a common denominator for OpenGL/DirectX , which means you having minimum common from available features..
So, while it may be good for simple use cases (like drawing a 3D box), for any more serious 3D rendering (especialy using shaders etc) you have to use OpenGL directly via FFI.
What i saw in OpenGL examples (mostly in Croquet) using B3DAcceleratorPlugin only for creating and initializing OpenGL rendering context, the rest is handled by using direct FFI calls to OpenGL library.
My main concern for using OpenGL without B3DAcceleratorPlugin (when i was playing with GLCanvas project) was obtaining a handle to main squeak window. The rest stuff can be completely implemented via FFI.
IMO, in a future we should provide a generic plugin for window management , which would allow to control host windows explicitly by image side, not implicitly like today's VMs doing for main window (and HostWindowPlugin serves only as addon).
On 29 July 2011 20:14, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi, I'm following the problem that prevents B3DAcceleratorPlugin to compile in Lion, SDK 10.7. The problem is that glCreateRendererFlags is using NewGWorld, and an enum useTempMem, an API who is deprecated since 10.4 and is not present anymore in 10.7 (well... maybe it is there, but it is not declared on headers). I added this at sqMacOpenGL.c to test behavior:
#ifdef MAC_OS_X_VERSION_10_7
#define useTempMem (1L << 2) //This declaration is taken from old sdk definition.
#endif
and now it compiles, but of course... I have a lot of "implicit declaration of function..." With this, now I have two questions:
- how can I test if B3DAcceleratorPlugin is working?
- as this is obviously a horrible patch... how can we change the plugin to be really updated?
(btw... this is why I'm so strong about the migration of legacy code as soon as possible... we can not be sure how much time this apis are going to be present) cheers, Esteban