Jump to content
  • entries
    945
  • comments
    5,899
  • views
    930,073

Move over, StarFox


Josh

2,552 views

 Share

I was determined to get 3D graphics working this week, and I did it. Behold, a box, now with *3D PERSPECTIVE*. :blink:

 

blogentry-1-050216600 1285542838_thumb.jpg

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!

 Share

5 Comments


Recommended Comments

A red cube? That's like a red square, but in 3D? That's rad. We're all set to develop games for the awesome "Degenatron" system. Check out the amazing games it can play.

 

Link to comment

I wouldn't make things more complicated than they really are. If the user deletes a texture of a material, he should do it from a method of the Material class, which should set the Texture pointer to NULL. Then the Material class can properly check for NULL textures.

When the user destroys a texture which is used by other materials also, they should not stay visible! It would be like, WTF I just deleted the texture from the computer's memory, why is that material on that mesh still showing it, do I have to loop through the whole computer's memory to delete all copies? Why can't the engine do it automatically, since I definitely wanted to delete that texture, and I'm fully aware that it's used in many places?

Link to comment

C++ references won't work with external languages, and many functions want to have an optional NULL parameter. Pointers are used for things that you manually create and destroy, like entities. Objects are used for thing like Vec3s and other temporary structures that are really just glorified float variables.

 

I prefer this:

TFormPoint( 1, 2, 3, NULL, entity );

To this:

TFormPoint( 1, 2, 3, NullEntity(), entity );

Link to comment

Most, if not all C++ libraries use their own namespaces and constants. So you could say:

#define LE_NULL NullEntity()

and then use:

TFormPoint( 1, 2, 3, LE_NULL, entity );

 

You shouldn't worry about C++ features at all, since you need to make a procedural C++ DLL for other languages anyway, just like you needed to with BlitzMax. The BlitzMax DLL had no BlitzMax features either.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...