Even if it’s possible to do tesselation, if it’s not necessary I might still make it toggleable for the end-user in case their machine chugs a little when rendering your game or app or whatever it is utilizing tesselation. If it just provides a higher level of detail, I would first do the dumb solution of: Desktop = Tesselation, GO!Embedded Systems = Tesselation, NO!And then if you find that you even need to add the tesselation capabilities to ES, simply add the classes/structures required, and do the little runtime check for hasExtension and make the ES version utilize the extensions. I only implemented what I needed – but I kept the interfaces similar to Qt OpenGL interfaces.Honestly though, if I were in your shoes, I would first ask “is tesselation necessary for the end user?”. See that and are examples of both of these cases. I simply remove the “Q” when making my own classes. (Hint: Look into setting your minimum Android NDK to a version which requires GLES 3.1, then have some common header in your project which will include the gles31.h header – BAM! GLES capabilities!)The cleanest solution in your case is to add the classes you need that Qt doesn’t provide (as I did with OpenGLFunctionsES31, and the like), and make them as “Qt” as possible if you want to continue to use a nice interface. So yeah, I’ll just have to make sure to only use features available with both GL ES 3.1 and GL 4.1.The one problem is I have a dependency on tessellation shaders, which is only an extension on a few Android GPUs out there. I’m currently targeting OpenGL 4.1 core (lowest common denominator of Windows/Ubuntu/Mac unfortunately). I’ve never run into this case myself, but it’s good to program for it.When programming modern GL, it’s always worthwhile to know what features you’re using and where they align with the ES features, especially if you want something to work across both desktop and mobile.Look forward to more blog posts about the ES30 and ES31 inclusion, I’ll have to send some emails and get on their code review systems to make the patch. If that fails, display an error message because the user doesn’t support the proper minimum GL which I’ve designed for. If neither of these are available at compile time, you likely don’t have the proper hardware to use the GL functionality you want.If both are supported, I try to make a desktop GL context first, if that fails, then an ESGL context. There really isn’t a need to switch, I’ve found what works best is to create a common OpenGLFunctions class which derives off the relevant desktop GL functions (primary), and then if that doesn’t work, the ESGL functions (secondary).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |