Move over, StarFox
I was determined to get 3D graphics working this week, and I did it. Behold, a box, now with *3D PERSPECTIVE*.
Making another variation of the infamous "my first box" demo with OpenGL is certainly nothing to brag about. However, there is quite a lot of code in use beyond just a simple hard-coded demo. The materials, shader, file system, camera, surface, graphics, math, and entity classes are all functioning at various levels of completion. I coded these systems and then used them to make a spinning box. If I had simply set out to make a spinning box and nothing else, it would have required a lot less code, that wouldn't be good for anything else.
More importantly, I have got C++ doing everything I did with BlitzMax. I still would not recommend C++ unless you need it for some specific reason, but I am very comfortable with it. I've run into a number of bugs and problems I was able to fix without too much trouble, and the debugging tools that come with MS Visual Studio are adequate. Besides the funny syntax, C++ is not really any different than programming in any other object-oriented language, so don't let anyone make you feel bad if you prefer C#, BlitzMax, or something else.
One interesting problem was dealing with the lack of garbage collection in C++. I am not a fan of garbage collection, but some kind of smart handling of resources is needed. When you have objects that can be assigned to other objects and passed around, managing them can be a nightmare. I could pass the responsibility onto the end user, but it would be very problematic to keep track of which material's textures need to be manually deleted. I used the following solution.
When something like a shader is assigned to something like a material, a copy of the shader is actually made. The copy is just a pointer that has the same ShaderReference object in the "reference" member. The ShaderReference instance count gets incremented. When a shader is deleted, the ShaderReference instance count gets decremented, and when the count reaches 0 the ShaderReference is deleted. Wow, that sounded confusing.
Let me illustrate with some code showing how resources are managed in LE3:
Material* mat = CreateMaterial(); Texture* tex = LoadTexture("rock.dds"); mat->SetTexture(tex,0); delete tex; // Don't worry, you are fine! delete mat; // Internal copy of texture will be deleted, along with the //TextureReference object that contains the OpenGL texture data
It's pretty hard to crash the engine by accidentally deleting a texture that is in use somewhere else. The reference / instance system is a lot more advanced in LE3, and also allows copies of most objects to be made, either as an instance or as a new unique copy. Cool, huh?
I love OpenGL3. The way they cleaned up GLSL and just made everything user-defined abstract data is fantastic. Cannot wait to get into it further!
In completely unrelated news, I have an idea for another website that is oriented towards video game consumers rather than developers. It's an interesting idea...we'll see if it materializes over the next six months or so. There's also a major site feature coming to leadwerks.com in October. I am very excited about it, but I'm not ready to say what it is yet, so all I can do right now is make ambiguously optimistic statements.
Here is the game I referenced in the title. This was the first 3D graphics I think I ever saw, and I was blown away at the time. The soundtrack is pretty rockin', too.
I am getting a lot of work done. Have a good week and have fun!
5 Comments
Recommended Comments