I have a very minimal extension for my GLSurfaceView, and most of the wisdom belongs to my implementation of GLSurfaceView.Renderer. I had the following three reasons to use a wrapper for GLSurfaceView:
The base GLSurfaceView provides no way to get the Renderer instance back. I have multiple surfaces, and when I receive a UI event for one of them, I want to pass the command to the corresponding renderer. So, I override setRenderer and keep the reference in my extended class.
GLSurfaceView.Renderer does not receive notifications for onDetachedFromWindow() or surfaceDestroyed(). This caused some problems to my implementation. My extension of GLSurfaceView overrides these methods and lets the mRenderer know. It's possible because of ยง1.
Some methods are only wrapped to add try { super.whatever; } catch() { log(whatever) }. For example, queueEvent() will throw if Renderer is not set; but for me, it's OK to simply ignore such timeline inconsistencies.
I was doubting: I'm writing a cross-platform engine OpenGL C++, I figured out windows forces the developers to access OpenGL features above 1.1 through extensions.
That sounds odd, because Windows have never forced me to use extensions, I always use core functions when possible, and while saying "when possible" I mean if my graphics card/driver supports the features. Because that plays the biggest part.
If the functionality is available in the core, is it also available as extension (VBO's e.g.)?
Not necessarily! But always favor the core functions when you can. Though when using extensions (EXT, ARB, etc) just always remember to check, if they are available.
If you're going to release a program using an NV Extension (Nvidia Extension), then again be sure to have something that checks whether the function is available, as if someone with a non-Nvidia graphics card uses your program it will most likely crash.
Or is an extension something you never know is available?
Yes, you never know for sure if an extension is available, it depends on various things such as.
- The OpenGL version you're using
- Your Graphics Card
- Your Graphics Card version and model (GeForce, Cuda, Radeon, etc)
- Your Graphics Card vendor (Nvidia, AMD, etc)
By using core functions the chances are that the majority of people will be able to run the program, as long as their graphics card can run the particular GL version.
- EXT extensions usually only are supported by a few vendors.
- ARB extensions are often supported by the majority but not necessarily all vendors.
- Core functions are supported by every card which supports the particular GL version, which the program is using.
Remember
Always remember you can't mix-match and use GL_TEXTURE1 with glActiveTextureARB and you can't use GL_TEXTURE1_EXT with glActiveTexture. Even though mixing them sometimes produces the desired result, there is no guarantee for that.
Best Answer
What you're looking for is projective texture mapping, for which there are many tutorials and which has been possible in all versions of OpenGL: SGI's sample code was written for OpenGL 1.0.
What you do is essentially apply a perspective transformation on the texture when you apply it to an arbitrary surface.