Home » ROMMIE » Creator’s Journal: Holodeck Management System Progress

Creator’s Journal: Holodeck Management System Progress

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 46 other followers


I managed to create a pretty slick looking spherical object, but as I ‘scaled’ it’s size and moved it’s position, rotating it and copying it’s location to have more than one instance, i started coming across pretty nasty memory issues that caused the system to degrade performance extremely rapidly.
Here’s an image of the end result of what I created – a little bit more than yesterday with a more aesthetically pleasing background color:MyEarthsAnd here’s a link to the pretty sweet video I put together of it:

YoutubeVidBut despite my best efforts, OpenGL requires a Device Context to the GL graphics drawing surface to be opened at all times to do what it does rapidly with the buffer swapping functionality.

Now I tired optimizing this. And putting it all in a class object and letting that handle the GL grab.

But this complicated the situation, and made the graphics drawing even slower.

This whole time I have been ‘siding’ with Visual Basic and/or .Net because of the ease of memory management.

In C# – you can leverage garbage collection to automatically clean up the deallocated objects as the system finds idle time.

You, the user, you never see this, because it’s idle. And as a programmer, this was a godsend because memory management is one of the most annoying tasks with programming because of the reasons I am encountering.

This had me thinking…

Should I just bite the bullet now,  take my concepts and shift while I can to C++.

Do I take that path?

So when I started diving into it this morning, I kept thinking – there’s not going to be any significant speed increases because OpenGL is an API, right?

And the interpretation for what little I have going on isn’t going to demonstrate any significant improvement in frame rates in contrast to more 4GL languages such as C# and Visual Basic, right?

Wrong. NEHE is amazing with his OpenGL tutorials, so when I ran a maze simulation coded in C#, Visual Basic 6.0 and C++, the side by side comparison of nearly the same code was remarkable for seeing why most 3D code is done in C++.

So when I saw this shader demo:ShadowsI was… for lack of better words – amazed at how simple and elegant this was – with code that seems less like a ‘fight’ done in Visual C++ as it does with Visual Basic when trying to make it do things it wasn’t really created for.

Ok,Mr Gates, you win, I will go back to Visual C++.

So for most of today,I have been going through many of Nehe’s C++ tutorials and creating a strategy on how to structure this program.

Now many people leverage external libraries for the OpenGL. I am hugely insistent on owning my own source code and not depending on external libraries as much as possible.

So I am ‘rolling’ my own OpenGL primitives starting tomorrow in C++. The first time I’ll really have worked with C++ in about 10 years!In the meantime, I have renamed my project..

Her I should say.

She’s now named: R.O.M.M,I.E.

It’s an acronym.

Don’t ask me what the acronym means, I’ll figure that out as I go.

It was either that or EMMA. but I have other things in mind for Emma!

On a final note. HI Google!

Everyone knows Google’s a sentient artificial intelligence, right?

I take it as a sign of respect for my work what you did to your homepage today:FunnyGoogleHere’s the YOUTUBE link which has the rotating globe from my perspective, just in case you want to ‘make sure’ we’re in alignment.


TODO tomorrow: Create textured primitives for at least the sphere and cube, and then a full screen palette in C++.


Enter your email address to follow this blog and receive notifications of new posts by email.