Jump to content

3 Ways Leadwerks Game Engine 5 Makes Game Programming Easier

Josh

1,931 views

Leadwerks Game Engine 5 moves Leadwerks forward into the future with massive performance increases and more advanced features, it also makes game development easier than ever before with three great new programming features.

Shared Pointers

I could write a whole article about the benefits of shared pointers.  Shared pointers are basically a simple form of garbage collection that relieves you from the need to manually delete objects, but doesn't suffer from the slow speed of full garbage collection.like C# uses.

In Leadwerks 4 we need to keep track of object reference counts by using the Release command when we are done with them:

Texture *texture = Texture::Load("Materials/Bricks/brick01.tex");
Material *material = Material::Create()
material->SetTexture(texture);
Model *model = Model::Box();
box->SetMaterial(material);
material->Release();
if (texture) texture->Release();

In Leadwerks 5 we never have to worry about calling Release() or (less commonly used) AddRef() because reference counts of shared pointers are tracked automatically.  The code below would cause a memory leak in Leadwerks 4 but is perfectly fine to use in Leadwerks 5:

auto material = Material::Create()
material->SetTexture(Texture::Load("Materials/Bricks/brick01.tex"));
auto model = Model::Box();
box->SetMaterial(material);

This even works with entities.  As soon as a variable goes out of scope the object is deleted:

if (true)
{
	auto model = Model::Box();
}// automatic deletion occurs here

1303-and-itsgone.jpg.cb17acc011c706142b7d8cf55eecd733.jpg

We can prevent deletion of an object by either keeping the variable in our code, or keeping a container that holds it.  In the case of map loading, the Map:Load() will return a structure that contains all the entity handles so they stay in memory.  Want to delete a camera?  It's easy:

camera = NULL;// poof!

There are still some details to work out but so far this approach is working great.

Another great benefit of shared pointers is that you can completely eliminate the need for big complicated destructors like this one.  All those objects will be automatically deleted when they go out of scope:

OpenGLCamera::~OpenGLCamera()
{
	for (int i=0; i<8; ++i)
	{
		if (shader_ambient[i])
		{
			shader_ambient[i]->Release();
			shader_ambient[i]=NULL;
		}
		for (int n = 0; n < 2; ++n)
		{
			for (int q = 0; q < 2; ++q)
			{
				for (int p = 0; p < 2; ++p)
				{
					if (shader_directional[i][n][q][p])
					{
						shader_directional[i][n][q][p]->Release();
						shader_directional[i][n][q][p] = NULL;
					}
					if (shader_directional_volume[i][n][q][p])
					{
						shader_directional_volume[i][n][q][p]->Release();
						shader_directional_volume[i][n][q][p] = NULL;
					}
					if (shader_point[i][n][q][p])
					{
						shader_point[i][n][q][p]->Release();
						shader_point[i][n][q][p] = NULL;
					}
					if (shader_point_volume[i][n][q][p])
					{
						shader_point_volume[i][n][q][p]->Release();
						shader_point_volume[i][n][q][p] = NULL;
					}
					if (shader_spot_volume[i][n][q][p])
					{
						shader_spot_volume[i][n][q][p]->Release();
						shader_spot_volume[i][n][q][p] = NULL;
					}
					if (shader_environment[i][n][q][p])
					{
						shader_environment[i][n][q][p]->Release();
						shader_environment[i][n][q][p] = NULL;
					}
					for (int usedecal = 0; usedecal < 2; usedecal++)
					{
						if (shader_spot[i][n][q][usedecal][p])
						{
							shader_spot[i][n][q][usedecal][p]->Release();
							shader_spot[i][n][q][usedecal][p] = NULL;
						}
					}
				}
			}
		}
	}
}

That entire function has been commented out in Leadwerks Game Engine 5. :D

Finally, shared pointers eliminate a problem that is the bane of all programmers' existence.  When used correctly, you can you can say goodbye to invalid and uninitialized pointers forever!  Yet shared pointers, unlike garbage collection, are fast to use and don't slow your game down.

Automatic Typing

The use of C++11 in Leadwerks Game Engine 5 gives us automatic typing of variables with the auto keyword.  We can simply something like this:

shared_ptr<Model> model = Model::Box();

To just this:

auto model = Model::Box();

If you have long complicated type names this makes life a million times easier:

for (std::list<shared_ptr<Entity> >::iterator it = list.begin(); it!= list.end(); it++)
{
	shared_ptr<Entity> entity = *it;
	entity->SetPosition(1,2,3);
}

Here's the same code simplified with auto (and range-based loops thanks to @Roland and @thehankinator.  Look how much more readable it is:

for (auto entity : list)
{
	entity->SetPosition(1,2,3);
}

This isn't completely new, but Leadwerks 5 is the first version built exclusively for C++11 features.

More Explicit API

Leadwerks 4 uses several bound states to store a current world and context.  These are global variables that are mostly invisible to the user.  This causes problems with multithreaded programming because two threads might try to change or access the bound state at the same time.

World *world1 = World::Create();
Model *model1 = Model::Box();

World *world2 = World::Create();
Model *model2 = Model::Box();
World::SetCurrent(world1);

Model *model3 = Model::Box();

Quick, which world does "model3" belong to?  Leadwerks 5 gets rid of the concept of bound states and requires you to explicitly specify the object you want to use.  Here's how the above code would look in Leadwerks 5:

auto world1 = World::Create();
auto model1 = Model::Box(world1);

auto world2 = World::Create();
auto model2 = Model::Box(world2);

auto model3 = Model::Box(world1);

Not only is the second example easier to understand, it's also one line shorter.

In a similar manner, the idea of a "current" context will be eliminated.  When you render a world you will need to explicitly specify which context to render to:

world->Render(context)

These programming features will make it easier than ever to code games with Leadwerks.



4 Comments


Recommended Comments

Looks great 

This one could be even more simple

for each( auto entity in list )
{
    entity->SetPosition(1,2,3);
}

instead of 

for (auto it = list.begin(); it!= list.end(); it++)
{
    auto entity = *it;
    entity->SetPosition(1,2,3);
}

 

Share this comment


Link to comment
21 minutes ago, Roland said:

Looks great 

This one could be even more simple


for each( auto entity in list )
{
    entity->SetPosition(1,2,3);
}

 

Is that a Visual Studio only feature?

Share this comment


Link to comment
27 minutes ago, Josh said:

Is that a Visual Studio only feature?

Ranged based for loops were added to the C++ standard in c++11, not a MSVC only thing. I've not seen the exact syntax that Roland used but this is how I do it in MSVC 2015  and GCC.

for (auto&& entity : list)
{
	entity->SetPosition(1,2,3);
}

( auto&& ensures you get a reference and no copies are made)

http://en.cppreference.com/w/cpp/language/range-for

https://stackoverflow.com/questions/26991393/what-does-auto-e-do-in-range-based-for-loops

Share this comment


Link to comment
2 hours ago, thehankinator said:

Ranged based for loops were added to the C++ standard in c++11, not a MSVC only thing. I've not seen the exact syntax that Roland used but this is how I do it in MSVC 2015  and GCC.


for (auto&& entity : list)
{
	entity->SetPosition(1,2,3);
}

( auto&& ensures you get a reference and no copies are made)

http://en.cppreference.com/w/cpp/language/range-for

https://stackoverflow.com/questions/26991393/what-does-auto-e-do-in-range-based-for-loops

Yes that is even better. Will change my loops to that

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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.

  • Blog Entries

    • By Josh in Josh's Dev Blog 10
      Current generation graphics hardware only supports up to a 32-bit floating point depth buffer, and that isn't adequate for large-scale rendering because there isn't enough precision to make objects appear in the correct order and prevent z-fighting.

      After trying out a few different approaches I found that the best way to support large-scale rendering is to allow the user to create several cameras. The first camera should have a range of 0.1-1000 meters, the second would use the same near / far ratio and start where the first one left off, with a depth range of 1000-10,000 meters. Because the ratio of near to far ranges is what matters, not the actual distance, the numbers can get very big very fast. A third camera could be added with a range out to 100,000 kilometers!
      The trick is to set the new Camera::SetClearMode() command to make it so only the furthest-range camera clears the color buffer. Additional cameras clear the depth buffer and then render on top of the previous draw. You can use the new Camera::SetOrder() command to ensure that they are drawn in the order you want.
      auto camera1 = CreateCamera(world); camera1->SetRange(0.1,1000); camera1->SetClearMode(CLEAR_DEPTH); camera1->SetOrder(1); auto camera2 = CreateCamera(world); camera2->SetRange(1000,10000); camera2->SetClearMode(CLEAR_DEPTH); camera2->SetOrder(2); auto camera3 = CreateCamera(world); camera3->SetRange(10000,100000000); camera3->SetClearMode(CLEAR_COLOR | CLEAR_DEPTH); camera3->SetOrder(3); Using this technique I was able to render the Earth, sun, and moon to-scale. The three objects are actually sized correctly, at the correct distance. You can see that from Earth orbit the sun and moon appear roughly the same size. The sun is much bigger, but also much further away, so this is exactly what we would expect.

      You can also use these features to render several cameras in one pass to show different views. For example, we can create a rear-view mirror easily with a second camera:
      auto mirrorcam = CreateCamera(world); mirrorcam->SetParent(maincamera); mirrorcam->SetRotation(0,180,0); mirrorcam=>SetClearMode(CLEAR_COLOR | CLEAR_DEPTH); //Set the camera viewport to only render to a small rectangle at the top of the screen: mirrorcam->SetViewport(framebuffer->GetSize().x/2-200,10,400,50); This creates a "picture-in-picture" effect like what is shown in the image below:

      Want to render some 3D HUD elements on top of your scene? This can be done with an orthographic camera:
      auto uicam = CreateCamera(world); uicam=>SetClearMode(CLEAR_DEPTH); uicam->SetProjectionMode(PROJECTION_ORTHOGRAPHIC); This will make 3D elements appear on top of your scene without clearing the previous render result. You would probably want to move the UI camera far away from the scene so only your HUD elements appear in the last pass.
    • By tipforeveryone in tipforeveryone's Blog 12
      I spent a whole week for learning UE4 with cpp, yep, UE4 is a great engine for sure, but I found out that my mind could not understand the way UE4 works easily. It is too complex and made me tired. Then I returned to my Leadwerks project and felt so familiar. Soooo... sweet, everything is simple as it is
      It felt like I have had a long trip to UE city then return to my hometown. I miss Leadwerks indeed.
      Last year, I thought I could only use Leadwerks with LUA and never touch its CPP side. But I tried my best, learned Cpp for 8 months. Now I am not a cpp pro but I am confident in using this language. At least I can rewrite my whole project in CPP instead. this 3-years project helped me to understand my potential and interest in gamedev.
      I wish Josh be successful in progress of making Turbo, a new hope for much better Leadwerks.
      To all people who are using Leadwerks and help me these years, love you.
      ...
      Peace!
    • By Josh in Josh's Dev Blog 2
      Still a lot of things left to do. Now that I have very large-scale rendering working, people want to fill it up with very big terrains. A special system will be required to handle this, which adds another layer to the terrain system. Also, I want to resume work on the voxel GI system, as I feel these results are much better than the performance penalty of ray-tracing. There are a few odds and ends like AI navigation and cascaded shadow maps to finish up.
      I am planning to have the engine more or less finished in the spring, and begin work on the new editor. Our workflow isn't going to change much. The new editor is just going to be a more refined version of what we already have, although it is a complete new program written from scratch, this time in C++.
      It's kind of overwhelming but I have confidence in the whole direction and strategy of this new product.
×
×
  • Create New...