Archive

Posts Tagged ‘opengl’

Creating Render-to-Texture Secondary Framebuffer Objects on iOS Using OpenGL ES 2

2012/05/20 8 comments

I’ve come to greatly respect OpenGL and for which it stands as I discussed in my prior post.  OpenGL was recently added to our awareness for a project for work at a time I was dabbling with it at home.  These parallel lines of development brought excitement and mutual benefits for each locale.   The project I am working on at work depends on what is inherently gaming technology even though you would think so to look at it.

I needed the ability to render the scene to a secondary framebuffer object (or FBO) due to the way the application incrementally draws a picture over time.  Successive scenes merely draw the remaining portions whilst being merged with previous fragments rendered in the framebuffer.   Think of the way Google Earth draws the image.

Anyway, the code worked fine on OpenGL 3.3 but for some reason the FBO failed the completeness test on OpenGL ES 2 under iOS.  After much banging of head-to-wall I found the reason was due to the fact I was creating the secondary FBO ultimately during GLKViewController’s viewDidLoad call.  This puzzled me as I already have a OpenGL context at this time due to a:

// We want OpenGL ES 2 thank-you very much
self.context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];

It seems creating a secondary framebuffer will fail if the size differs to the main framebuffer size.  The best way to create secondary framebuffers is to wait for a viewWillLayoutSubviews notification.  By this time your GLKit view is already resized so all you need to do is query the new size and create an appropriate FBO.

The above controller calls into the following view for creating the framebuffer

To draw, you must:

  1. Have the controller call into your view
  2. Bind to your secondary FBO
  3. Draw
  4. Return to the controller
  5. Have the controller rebind to the main FBO
  6. Call into your view again to draw the offscreen texture
    The final step is to draw the screen quad (steps 5-6 above)

You might be wondering what all the bindDrawable is about.  Well normally in OpenGL you would glBindFrameBuffer(…) to your framebuffer then perform a glBindFramebuffer (…, 0) to reset to the default framebuffer – well that won’t work on OpenGL ES (well you could perhaps if you knew the actual handle).  You must use bindDrawable() instead.

Here are some books that helped me greatly

OpenGL® SuperBible: Comprehensive Tutorial and Reference (4th Edition)

OpenGL® ES 2.0 Programming Guide

Advertisements
Categories: Development Tags: , ,

You Mean I’ve Been on the Dark Side All Along?

2012/04/22 1 comment

This is how I felt earlier this week after my initial forays into OpenGL, an open standard graphics library for multiple platforms.  From the books I was reading, I had come to realise that XNA is perhaps an immature API from both age and sensibility viewpoints, particularly where one is concerned with cross-platform and backwards compatibility and DirectX was just too hard.  I was already aware of the last point from personal experience.

I quite like how OpenGL has its extension system to expand the API without breaking other peoples code.  XNA and DirectX could learn a lesson here.

The XNA team have had a history of breaking backwards compatibility for “reasons” of motivation.  There were major breaking changes between XNA 3 and XNA 4.  The future of XNA to me is uncertain.  Microsoft’s next OS Windows 8 has XNA no where to be seen. XNA can be found on Windows Phone 7 devices but they are quite rare.  There is XNA on XBOX for end-users, but it has fewer features than what a proper XBOX game has access to hardware-wise. XNA was not the first Microsoft managed DirectX wrapper.  Before XNA there was MDX and sadly it went the way of the Dodo bird.

Just a few lines is all it takes to display a 3D window

OpenGL is reportedly easy to learn and thus far I agree with what I have been told.  Just a few lines is all it takes to display a 3D window.  It’s also good to know that no bloatware, no mammoth class libraries, no over-the-top OO-style programming – just pure, nice and clean c-style methods.   Contrast this with DirectX – now I would like to think I know something when it comes to COM, but trying to learn DirectX is quite challenging.   DirectX did come out later with c++ helper classes but they were perhaps rather limited and let’s face it – too late!

XNA is a lot easier than DirectX but its way harder than OpenGL, however XNA is slightly bloaty compared to OpenGL.  Plus unlike XNA, OpenGL doesn’t have ridiculous legal restrictions on what you can do or how you distribute your application.   Want to give your buddy your game to try out?  He may need Visual Studio 2010; XNA Game Studio installed; and know how to compile your program.   Not fun.

…we still have point sprites on OpenGL using the same modern-day video card!

The worst bit about learning XNA, was how unprofessional some of the key representatives and tutors were on certain forums and blogs.  No, these were not fan forums.  Forum manners were atrocious; people with perceived ulterior motives; and some cases of propaganda.  One was to do with the elimination of point sprites from the API, another over not to use the FBX file format and the bizarre recommendation for people not to use sky domes.  Funny, we still have point sprites on Windows via OpenGL using the same modern-day video card!   Even iPads can use point sprites via OpenGL ES.  Sure, point sprites may be old hat but we were lead to believe that modern hardware doesn’t support it when the truth is is that latter DirectX doesn’t.

The point is, if my legacy app wants to use some ancient deprecated feature, the API should damn well let it have it, even if it means it runs like a pig.  This is why OpenGL is so much better.  OpenGL is kinder to you – it gives you the opportunity to run your legacy app whilst allowing you to gradually upgrade to newer discipline.

You were told to do things a certain way in XNA either with no explanation, or if one was given, was perhaps a half-truth in hind-sight.  I was reminded of how I felt when I first heard of OpenGL back in the days of Windows NT 4 and basically dismissed OpenGL most likely due to at the time being influenced by others in the know.  Back then, I suspect I didn’t hear both sides of the story, like the point spites half-truth.

Now I don’t profess to be an expert in XNA, let alone DirectX, but my experiences in both of these has made me come to the realisation that I have more important things to worry about – what my application is about and how the tools or APIs can help me.

Hello OpenGL, so nice to be in the light with you!

Categories: Development Tags: , , ,