For example: layout(location = 0) in vec4 position The thing you're more likely to get caught on are the convenience features of desktop GL 3.x. So how much you need it depends on what you're trying to do, and there may be alternatives depending on the algorithm. As is transform feedback, geometry shaders, etc. Rendering to texture (or to multiple textures) is something that is called for by your algorithm. It's easy to avoid the actual hardware features. At the very least, you should read up on what OpenGL ES 2.0 does, so that you can know how it differs from desktop GL. It rather depends on how much work you intend to do and what you're prepared to do to make it work. Explicit attribute locations ( layout(location=#)), VAOs, etc.įor example, if I start reading this book, am I wasting my time if I plan to port the engine to Android (using NDK of course ) )? Some of which may be platform-specific.īut there are also some good API convenience features available on desktop GL 3.x. These are all specific hardware features that either aren't available in ES 2.0, or are only available via extensions. There's transform feedback, integer textures, uniform buffer objects, and geometry shaders.

Framebuffer objects are core in 3.x, whereas they're extensions in 2.0 (and even then, you only get one destination image without another extension). But there is a mostly common subset of the two that would work on both (though you'll have to fudge things for texture image loading, because there are some significant differences there).ĭesktop GL 3.x provides a lot of functionality that unextended ES 2.0 simply does not. Desktop GL 2.1 has a bunch of functions that ES 2.0 doesn't have. From what I've read, it appears that OpenGL ES 2.0 isn't anything like OpenGL 2.1, which is what I assumed from before.ĭefine 'isn't anything like' it.

OpenGL ES 2.0 model