In creating my OpenGL Custom Control, one thing that’s highly important is the ability to set a ‘transparent’ property on the control to true or false, and if set to true, then the control will draw the 3d blending whatever model is being rendered with the background.
Whether that background’s a static bitmap, or a another 3d model.
This has sent me on a path which feels much like I am chasing my own tail.
I found a wonderful example of this on StackOverflow, here, where someone’s using flat triangles similar to what I am using which comes out looking pretty sweet:
So I pulled it down and did a little modification to add 3d vertices to it and lo and behold what do I get?
Now all day, I have been working to import this into a reusable custom control framework that I can use in Visual Basic 6.0, as the end goal is to leverage Visual Basic to focus more on User Interface Design than the actual ‘code behind’ the windows.
And another goal is simple: To make the desktop icons that look like this:
… look 3d, with 3d animations that don’t flicker and are seamlessly integrated with the desktop window and have transparencies. See TESTGL.exe, above, and how the icon has ‘transparent’ sections which let you see the desktop green background? That’s the effect I am looking for, only my icons will all be rotating in 3d, and when I select one it will stop rotating.
Easy smeasy, right?
Not so easy.
I’ve spent the better part of two days putzing around with converting the code from “C” to an MFC/C++ based custom control, and let me tell you – it’s been a BITCH. Here’s an example of some of the crap I’m getting for output because the conversion isn’t a straightforward conversion:
This “tearing” is the result of me drawing direct to the window.
Now I will be the first to admit. I’m rusty with my Visual C++ 2005. WAY rusty. And that is where my problems lie. I can’t blame MFC. I can’t blame Microsoft. I can’t blame C++’s limitations. It’s just a plain and simple I’ve been too far removed from C and C++ for too long and have forgotten the simple things such as “What’s the different between Draw and Paint”.
Add into that issues which are new to me, such as off screen buffering, Differences between drawing using MFC and CDCs versus HDCs, Pixelformats, and internal debates about transparency colors, and I have a LOT of time spent just jumping back and forth between testing out a change here and there and crashing the programs and a couple times – my machine.
So herein lies the problem I’m having: The abstraction that Microsoft and MFC offers is nice and all, but most usable examples for portable OpenGL functionality lie in the “C” language. The MOMENT it gets transported to MFC, C++, C#, I get into language semantics which – while the example may work fine and dandy in isolation for that one particular thing, trying to convert it to do something else is a bitch.
This is a great for instance. ALL too many times people respond on the internet with ‘It can’t be done” concerning transparency. And if I ask questions myself, usually I’m insulted or lambasted so I’ve just gotten out of the habit of asking questions and doing it my own way.
It’s a bitch, and weirdly unfortunate as the internet hasn’t always been like this – so utterly unhelpful.
I suppose that’s forcing me down a path of ‘back to basics’, which right now has me considering shifting the entire development into the C language, managing the windows and message pump myself directly, and that also guarantees the code will be as absolutely tight as possible with no dependencies. I mean, I can after all embed the opengl libraries.
I’m going to try a few more things with the control tomorrow, but rather than ‘butt my head’ – at least I have a viable path and can use C to build my desktop window manager which will have “aero” looking like it was created by children.
Oh wait. It already does.
This isn’t to say it’s not pretty. IT VERY much IS.
But it’s horrible with memory and horribly conflicting with just about everything else that runs under windows.
That’s it. I’m outta here.