On March 17th, I outlined a project for an OpenGL Custom Control that could be used in Visual Basic.
That outline can be seen here: https://universalbri.wordpress.com/2016/03/17/qs-opengl-ocx-control-for-visual-basic-6-0/
The acquaintance I had created the outline for who was wanting to learn C++ has been too busy to work on it, so for the last two weeks. I have been working off and on prototyping the code and whipping out a first draft of the control.
First draft – the prototype – was a proof of concept Pyramid completely done in OpenGL I created in Visual basic.
This is based on the 3d pyramid based on NEHE’s OpenGL code sample from lesson 5, here: http://nehe.gamedev.net/tutorial/3d_shapes/10035/
Here’s the prototype project – a simple forms based project coded in Visual Basic 6.0 which presents the chief reason I didn’t like this route. I was dependent on someone else’s type library with no real control over it – for something that did nothing more than declared the references for the OpenGL libraries.
So while I could ‘hand code’ my references to OpenGL (and I’ve done that before), I had already been fighting with Visual Basic’s approach which had me realizing – early on – that a split development – C++ and Visual Basic – was the most optimal approach.
Here’s the code for this simple pyramid:
A lot to do for so little, right?
Now there was a problem with that code, there’d be a flicker as the draw method was called four times just to start the project up. Initially, I had been trying to convince myself to do this ALL in VB, when I realized there’s TWO things Visual Basic 6.0 does EXTREMELY well. Prototypes. Where I can very very quickly test out ideas and concepts before industrializing the code. AND User Interfaces.
So I took this ‘foundation’ as a concept, knowing VB will act as a great container when I optimize the code in C++, so from there I started the conversion process leveraging my lessons learned from this prototype and the original code from NEHE to create my ActiveX control…
Much of that code has been retrofitted for use in an MFC (statically linked) ActiveX control with statically linked OpenGL libraries, with a few properties for x,y, z positioning of the object as well as the rotation angle and an externally available redraw method (just in case) for a total compiled release size of the control of 352k. Fucking amazing, if I must say so myself.
All that with NO dependencies other than the operating system….
Makes me a happy camper. Literally + Figuratively
Here’s the evidence:
So I take that control, once compiled, and place it in a Visual Basic 6.0 project.
At first, I had a shitload of problems with DC and memory management. I am admittedly a bit rusty with my C++, and remembering all the nuances of development between projects. Between killing the GL subsystem one time and putzing up my entire computer with creating a DC every time a paint would occur, oh and property bag management for serializing and saving the properties state between development and run time, and… jeez… the problems I had were too many to mention to be sincere..
AFTER finally dealing with all that nonsense.
And then a subsequent debate with myself (that happens frequently) – this morning about whether I should convert the project to ATL to slim it down even more and hopefully gain better access to the message pump, after taking one look at the ATL, I stepped back and questioned my sanity for considering it and stuck with the MFC implementation.
The simple fact is, for the cryptic nature of ATL in contrast to MFC’s straightforward approach, I’ll take the LITTLE BIT of bloat for a more straightforward and reusable control.
So here’s the first project test of it in a visual basic container. NOW works marvelously without any memory glitches at all:
See how easy those properties work to rotate the control and set the initial positioning of the object being rendered?
No code. One dependency. Something I created. Me likey.
Add a few more of those controls onto a form, a time, and a few lines of Visual Basic 6.0 code to dynamically rotate the object or respond to the ‘w’ and ‘s’ keys to move the primary pyramid in and out:
The end result looks seamlessly smooth and looks like this, with a lot of nifty pyramids most rotating independently in their own locations:
Now all this compiles to a Visual Basic 6.0 executable that is only – get this – 20k in size…
I know, I know, size doesn’t mean everything, right?
And while sure there’s the dependencies such as the VB Run time and the OCX control, but I’m proud to say that the first round draft of this control, at least proving the functionality and mash up right now creates a deliverable which will have a smaller footprint than the installer package itself.
If you’d like to check out a soundless video that demonstrates it – I will have Bennett do a soundtrack for me like the rest of the nerds do later – then here’s the youtube link..
That’s it for today on this. Next up to bat: Allowing for user generated objects, transparent backgrounds to allow for blending of the 3d render to the background image, and digging into the message pump for lighting.
I have an idea for how to handle the lighting, which is to create a light source control which will send messages in the message pump which the controls such as this will then receive and then render themselves on their own thread. Should work out pretty sweet if it works.
And I can use similar concepts for gravity.
For instance: Let’s say I place a gravity object on the form, at runtime, the object control will drift (or repel) based on the gravity. a two dimensional and three dimensional reaction at the same time. so it might be a little tricky.
But might be fun to implement scaling based on intense gravity.
Until next time…..