Jump to content

Compatibility Wrapper

reepblue

309 views

While we have Leadwerks today to make our apps, Turbo is currently in development. To make my projects more long term, I decided to take a step back from my VR project and create a wrapper class that apps can use to more easily transfer to the new engine.  Keep in-mind, this doesn't cover everything and I'm used the last beta from November for testing so things can change. Regardless, as long as that bridge is made, I can always go back and edit the Turbo stuff as more things come online. The goal is to make the Leadwerks stuff compatible with the new tech.

This code works on both engines.

#include "GameEngine.hpp"
using namespace ENGINE_NAMESPACE;

int main(int argc, const char *argv[])
{
	auto window = Create_Window("MyGame");
	auto context = Create_Context(window);
	auto world = Create_World("Maps/testrender.map");

	while (window->Closed() == false)
	{
		if (window->KeyHit(KEY_ESCAPE))
			break;

		UpdateWorld();
		RenderWorld();

#ifndef TURBO_ENGINE
		context->Sync(true);
#endif
	}

	return 0;
}

As you can see, I went with with the cleaner style of the new engine. The only thing is ugly is the context syncing for Leadwerks, I didn't want wrap that since context syncing is totally different between Leadwerks and the new engine.

Marcos!

To comply with the new engine's integer values, I've defined a few macros that is only defined in Leadwerks. While this doesn't cover everything right now, So far I got the Window stuff, Collision, and all keys defined!

#ifndef TURBO_ENGINE
// -------------
// Window:
// -------------
#define WINDOW_TITLEBAR Window::Titlebar
#define WINDOW_RESIZABLE Window::Resizable
#define WINDOW_HIDDEN Window::Hidden
#define WINDOW_CENTER Window::Center
#define WINDOW_FULLSCREEN Window::FullScreen


// -------------
// Color:
// -------------
#define COLOR_DIFFUSE Leadwerks::Color::Diffuse
#define COLOR_SPECULAR Leadwerks::Color::Specular
#define COLOR_EDIT Leadwerks::Color::Edit

// -------------
// Collision:
// -------------
#define COLLISION_NONE Collision::None
#define COLLISION_PROP Collision::Prop
#define COLLISION_SCENE Collision::Scene
#define COLLISION_CHARACTER Collision::Character
#define COLLISION_TRIGGER Collision::Trigger
#define COLLISION_DEBRIS Collision::Debris

#define COLLISION_COLLIDE Collision::Collide // Not Turbo'd
#define COLLISION_PROJECTILE Collision::Projectile // Not Turbo'd
#define COLLISION_LINEOFSIGHT Collision::LineOfSight // Not Turbo'd 
#define COLLISION_FLUID Collision::Fluid // Not Turbo'd
#define COLLISION_LASTENTRY COLLISION_FLUID // Not Turbo'd

 

Shared Pointers vs Raw

The new engine uses smart pointers to replace the current reference system. I needed macros to address this to prevent my code being #ifdef/#endif living Hell.

// Smart Pointers vs Raw Pointers
#ifdef TURBO_ENGINE
#define ENGINE_OBJECT(x) std::shared_ptr<x>
#define ENGINE_OBJECT_RELEASE(x) if (x != nil) { x->Free(); x = nil;  }
#define ENGINE_REFERENCE(x) std::weak_ptr<x>
#define ENGINE_CAST(_class_, _pointer_) dynamic_pointer_cast<_class_>(_pointer_);
#else
#define ENGINE_OBJECT(x) x*
#define ENGINE_OBJECT_RELEASE(x) if (x != nil) { x->Release(); x = nil; }
#define ENGINE_REFERENCE(x) x*
#define ENGINE_CAST(_class_, _pointer_) (_class_*)_pointer_
#endif

To my surprise, you don't delete an entity alone calling something like "model = NULL". This is because the world class keeps a list of all entities in the world via a shared pointer. Instead (for right now) you call the Free command to totally remove the model. Another thing to note is that with Leadwerks, ENGINE_REFERENCE is the same as ENGINE_OBJECT. while ENGINE_REFERENCE is a weak pointer.

 

Setters and Getters.

First thing first, I needed to redefine the the Setters/Getters system from Leadwerks. While the decision to remove this functionality opens the door for more possiblites thanks to the new engine's architecture, In my five years of using Leadwerks, I never had a needed more than one world/context/window for most use cases.

//-----------------------------------------------------------------------------
// Purpose: We still need Getters/Setters to comply with LE code.
//-----------------------------------------------------------------------------
namespace ENGINE_NAMESPACE
{
	void SetCurrentWindow(ENGINE_OBJECT(Window) pWindow);
	void SetCurrentContext(ENGINE_OBJECT(Context) pContext);
	void SetCurrentWorld(ENGINE_OBJECT(World) pWorld);
	void SetCurrentCamera(ENGINE_OBJECT(Camera) pCamera);

	ENGINE_OBJECT(Window) GetCurrentWindow();
	ENGINE_OBJECT(Context) GetCurrentContext();
	ENGINE_OBJECT(World) GetCurrentWorld();
	ENGINE_OBJECT(Camera) GetCurrentCamera();
}

While in Turbo, the object are assigned to pointers in the cpp file, In Leadwerks, this is just a wrapper for the Set/GetCurrent functions.

Then we have wrapper functions for every create and load function. So we just do this to set our currents.

	// Creates a window.
	ENGINE_OBJECT(Window) Create_Window(const std::string& pszTitle, const int x, const int y, const int iWidth, const int iHeight, const int iStyle, ENGINE_OBJECT(Window) pParent)
	{
#ifndef TURBO_ENGINE
		auto window = Window::Create(pszTitle, x, y, iWidth, iHeight, iStyle, pParent);
#else
		auto window = CreateWindow(pszTitle, x, y, iWidth, iHeight, iStyle, pParent);
#endif
		SetCurrentWindow(window);

#ifdef WIN32
		window->SetActive();
#endif
		return window;
	}

	// Creates a Context.
	ENGINE_OBJECT(Context) Create_Context(ENGINE_OBJECT(Window) pWindow)
	{
#ifndef TURBO_ENGINE
		auto context = Context::Create(pWindow);
#else
		auto context = CreateContext(pWindow);
#endif
		SetCurrentContext(context);

		return context;
	}

 

World

How the world loads scenes between the two engines is completely different! In Turbo, the map is loaded to a shared pointer in which you can throw around your application while in Leadwerks it's just a static function call. As the goal is to just make a compatibility layer,  I just had to do something like this:

	// Loads a scene into the current world.
	bool Load_Scene(const std::string& pszPath, void hook(ENGINE_OBJECT(Entity) entity, ENGINE_OBJECT(Object) extra))
	{
#ifdef TURBO_ENGINE
		if (m_pCurrentWorld.lock() == nil)
			return false;

		if (FileSystem::GetFileType(pszPath) == 0)
		{
			Msg("Error: Failed to load scene file " + ENGINE_NAMESPACE::FileSystem::FixPath(pszPath) + "\"...")
				return false;
		}

		auto scene = Turbo::LoadScene(GetCurrentWorld(), pszPath); // There is no C++ maphooks rn. :(
		return scene != nil;
#else
		return Map::Load(pszPath, hook);
#endif
	}

	// Creates a world.
	ENGINE_OBJECT(World) Create_World(const std::string& pszPath)
	{
#ifdef TURBO_ENGINE
		auto world = CreateWorld();
#else
		auto world = World::Create();
#endif
		SetCurrentWorld(world);

		if (pszPath != "")
		{
			if (Load_Scene(pszPath) == false)
			{
				Msg("Error: Failed to load scene \"" + pszPath + "\"...");
			}
		}

		return world;
	}

 

Creating Entities

Entities in Turbo can be assigned to any world pointer upon creation while with Leadwerks, it creates the entity to the world that's set to current. This was a easy fix as again, we are are just doing a compatibility layer. While the style is more Turbo like, there is no world argument, it grabs the current pointer just like Leadwerks.

	// Creates a Pivot.
	ENGINE_OBJECT(Pivot) Create_Pivot(ENGINE_OBJECT(Entity) pParent)
	{
#ifdef TURBO_ENGINE
		if (pParent != nil) return CreatePivot(pParent);
		return CreatePivot(GetCurrentWorld());
#else
		return Pivot::Create(pParent);
#endif
	}

	// Creates a Camera.
	ENGINE_OBJECT(Camera) Create_Camera()
	{
#ifdef TURBO_ENGINE
		return CreateCamera(GetCurrentWorld());
#else
		return Camera::Create();
#endif
	}

	// Creates a Listener.
	ENGINE_OBJECT(Listener) Create_Listener(ENGINE_OBJECT(Entity) pParent)
	{
#ifdef TURBO_ENGINE
		return CreateListener(GetCurrentWorld(), pParent);
#else
		return Listener::Create(pParent);
#endif
	}

 

Lights are different in the new engine. Instead of lights being their own classes, the new "CreateLight" function returns "Light". Again, I solved this with Macros.

	// Creates a Point Light.
	ENGINE_OBJECT(CLASS_POINTLIGHT) Create_PointLight(ENGINE_OBJECT(Entity) pParent)
	{
#ifdef TURBO_ENGINE
		return CreateLight(GetCurrentWorld(), LIGHT_POINT, pParent);
#else
		return CLASS_POINTLIGHT::Create(pParent);
#endif
	}

	// Creates a Spot Light.
	ENGINE_OBJECT(CLASS_SPOTLIGHT) Create_SpotLight(ENGINE_OBJECT(Entity) pParent)
	{
#ifdef TURBO_ENGINE
		return CreateLight(GetCurrentWorld(), LIGHT_SPOT, pParent);
#else
		return CLASS_SPOTLIGHT::Create(pParent);
#endif
	}

	// Creates a Directional Light.
	ENGINE_OBJECT(CLASS_DIRECTIONALLIGHT) Create_DirectionalLight(ENGINE_OBJECT(Entity) pParent)
	{
#ifdef TURBO_ENGINE
		return CreateLight(GetCurrentWorld(), LIGHT_DIRECTIONAL, pParent);
#else
		return CLASS_DIRECTIONALLIGHT::Create(pParent);
#endif
	}

And loading things are the same concept. . . .

	// Load a Sound file.
	ENGINE_OBJECT(Sound) Load_Sound(const std::string& pszPath, const int iFlags)
	{
#ifndef TURBO_ENGINE
		return Sound::Load(pszPath, iFlags);
#else
		return LoadSound(pszPath, iFlags);
#endif
	}

 

That's about it. I'm going to use this going forward updating as I go and hopefully doing this will make the transition less painful when the time comes.

  • Like 2


0 Comments


Recommended Comments

There are no comments to display.

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 4
      I have been working on 2D rendering off and on since October. Why am I putting so much effort into something that was fairly simple in Leadwerks 4? I have been designing a system in anticipation of some features I want to see in the GUI, namely VR support and in-game 3D user interfaces. These are both accomplished with 2D drawing performed on a texture. Our system of sprite layers, cameras, and sprites was necessary in order to provide enough control to accomplish this.
      I now have 2D drawing to a texture working, this time as an official supported feature. In Leadwerks 4, some draw-to-texture features were supported, but it was through undocumented commands due to the complex design of shared resources between OpenGL contexts. Vulkan does not have this problem because everything, including contexts (or rather, the VK equivalent) is bound to an abstract VkInstance object.

      Here is the Lua code that makes this program:
      --Get the primary display local displaylist = ListDisplays() local display = displaylist[1]; if display == nil then DebugError("Primary display not found.") end local displayscale = display:GetScale() --Create a window local window = CreateWindow(display, "2D Drawing to Texture", 0, 0, math.min(1280 * displayscale.x, display.size.x), math.min(720 * displayscale.y, display.size.y), WINDOW_TITLEBAR) --Create a rendering framebuffer local framebuffer = CreateFramebuffer(window); --Create a world local world = CreateWorld() --Create second camera local texcam = CreateCamera(world) --Create a camera local camera = CreateCamera(world) camera:Turn(45,-45,0) camera:Move(0,0,-2) camera:SetClearColor(0,0,1,1) --Create a texture buffer local texbuffer = CreateTextureBuffer(512,512,1,true) texcam:SetRenderTarget(texbuffer) --Create scene local box = CreateBox(world) --Create render-to-texture material local material = CreateMaterial() local tex = texbuffer:GetColorBuffer() material:SetTexture(tex, TEXTURE_BASE) box:SetMaterial(material) --Create a light local light = CreateLight(world,LIGHT_DIRECTIONAL) light:SetRotation(55,-55,0) light:SetColor(2,2,2,1) --Create a sprite layer. This can be shared across different cameras for control over which cameras display the 2D elements local layer = CreateSpriteLayer(world) texcam:AddSpriteLayer(layer) texcam:SetPosition(0,1000,0)--put the camera really far away --Load a sprite to display local sprite = LoadSprite(layer, "Materials/Sprites/23.svg", 0, 0.5) sprite:MidHandle(true,true) sprite:SetPosition(texbuffer.size.x * 0.5, texbuffer.size.y * 0.5) --Load font local font = LoadFont("Fonts/arial.ttf", 0) --Text shadow local textshadow = CreateText(layer, font, "Hello!", 36 * displayscale.y, TEXT_LEFT, 1) textshadow:SetColor(0,0,0,1) textshadow:SetPosition(50,30) textshadow:SetRotation(90) --Create text text = textshadow:Instantiate(layer) text:SetColor(1,1,1,1) text:SetPosition(52,32) text:SetRotation(90) --Main loop while window:Closed() == false do sprite:SetRotation(CurrentTime() / 30) world:Update() world:Render(framebuffer) end I have also added a GetTexCoords() command to the PickInfo structure. This will calculate the tangent and bitangent for the picked triangle and then calculate the UV coordinate at the picked position. It is necessary to calculate the non-normalized tangent and bitangent to get the texture coordinate, because the values that are stored in the vertex array are normalized and do not include the length of the vectors.
      local pick = camera:Pick(framebuffer, mousepos.x, mousepos.y, 0, true, 0) if pick ~= nil then local texcoords = pick:GetTexCoords() Print(texcoords) end Maybe I will make this into a Mesh method like GetPolygonTexCoord(), which would work just as well but could potentially be useful for other things. I have not decided yet.
      Now that we have 2D drawing to a texture, and the ability to calculate texture coordinates at a position on a mesh, the next step will be to set up a GUI displayed on a 3D surface, and to send input events to the GUI based on the user interactions in 3D space. The texture could be applied to a computer panel, like many of the interfaces in the newer DOOM games, or it could be used as a panel floating in the air that can be interacted with VR controllers.
    • By Josh in Josh's Dev Blog 0
      Putting all the pieces together, I was able to create a GUI with a sprite layer, attach it to a camera with a texture buffer render target, and render the GUI onto a texture applied to a 3D surface. Then I used the picked UV coords to convert to mouse coordinates and send user events to the GUI. Here is the result:

      This can be used for GUIs rendered onto surfaces in your game, or for a user interface that can be interacted with in VR. This example will be included in the next beta update.
    • By Josh in Josh's Dev Blog 4
      I started to implement quads for tessellation, and at that point the shader system reached the point of being unmanageable. Rendering an object to a shadow map and to a color buffer are two different processes that require two different shaders. Turbo introduces an early Z-pass which can use another shader, and if variance shadow maps are not in use this can be a different shader from the shadow shader. Rendering with tessellation requires another set of shaders, with one different set for each primitive type (isolines, triangles, and quads). And then each one of these needs a masked and opaque option, if alpha discard is enabled.
      All in all, there are currently 48 different shaders a material could use based on what is currently being drawn. This is unmanageable.
      To handle this I am introducing the concept of a "shader family". This is a JSON file that lists all possible permutations of a shader. Instead of setting lots of different shaders in a material, you just set the shader family one:
      shaderFamily: "PBR.json" Or in code:
      material->SetShaderFamily(LoadShaderFamily("PBR.json")); The shader family file is a big JSON structure that contains all the different shader modules for each different rendering configuration: Here are the partial contents of my PBR.json file:
      { "turboShaderFamily" : { "OPAQUE": { "default": { "base": { "vertex": "Shaders/PBR.vert.spv", "fragment": "Shaders/PBR.frag.spv" }, "depthPass": { "vertex": "Shaders/Depthpass.vert.spv" }, "shadow": { "vertex": "Shaders/Shadow.vert.spv" } }, "isolines": { "base": { "vertex": "Shaders/PBR_Tess.vert.spv", "tessellationControl": "Shaders/Isolines.tesc.spv", "tessellationEvaluation": "Shaders/Isolines.tese.spv", "fragment": "Shaders/PBR_Tess.frag.spv" }, "shadow": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "Shaders/DepthPass_Isolines.tesc.spv", "tessellationEvaluation": "Shaders/DepthPass_Isolines.tese.spv" }, "depthPass": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "DepthPass_Isolines.tesc.spv", "tessellationEvaluation": "DepthPass_Isolines.tese.spv" } }, "triangles": { "base": { "vertex": "Shaders/PBR_Tess.vert.spv", "tessellationControl": "Shaders/Triangles.tesc.spv", "tessellationEvaluation": "Shaders/Triangles.tese.spv", "fragment": "Shaders/PBR_Tess.frag.spv" }, "shadow": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "Shaders/DepthPass_Triangles.tesc.spv", "tessellationEvaluation": "Shaders/DepthPass_Triangles.tese.spv" }, "depthPass": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "DepthPass_Triangles.tesc.spv", "tessellationEvaluation": "DepthPass_Triangles.tese.spv" } }, "quads": { "base": { "vertex": "Shaders/PBR_Tess.vert.spv", "tessellationControl": "Shaders/Quads.tesc.spv", "tessellationEvaluation": "Shaders/Quads.tese.spv", "fragment": "Shaders/PBR_Tess.frag.spv" }, "shadow": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "Shaders/DepthPass_Quads.tesc.spv", "tessellationEvaluation": "Shaders/DepthPass_Quads.tese.spv" }, "depthPass": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "DepthPass_Quads.tesc.spv", "tessellationEvaluation": "DepthPass_Quads.tese.spv" } } } } } A shader family file can indicate a root to inherit values from. The Blinn-Phong shader family pulls settings from the PBR file and just switches some of the fragment shader values.
      { "turboShaderFamily" : { "root": "PBR.json", "OPAQUE": { "default": { "base": { "fragment": "Shaders/Blinn-Phong.frag.spv" } }, "isolines": { "base": { "fragment": "Shaders/Blinn-Phong_Tess.frag.spv" } }, "triangles": { "base": { "fragment": "Shaders/Blinn-Phong_Tess.frag.spv" } }, "quads": { "base": { "fragment": "Shaders/Blinn-Phong_Tess.frag.spv" } } } } } If you want to implement a custom shader, this is more work because you have to define all your changes for each possible shader variation. But once that is done, you have a new shader that will work with all of these different settings, which in the end is easier. I considered making a more complex inheritance / cascading schema but I think eliminating ambiguity is the most important goal in this and that should override any concern about the verbosity of these files. After all, I only plan on providing a couple of these files and you aren't going to need any more unless you are doing a lot of custom shaders. And if you are, this is the best solution for you anyways.
      Consequently, the baseShader, depthShader, etc. values in the material file definition are going away. Leadwerks .mat files will always use the Blinn-Phong shader family, and there is no way to change this without creating a material file in the new JSON material format.
      The shader class is no longer derived from the Asset class because it doesn't correspond to a single file. Instead, it is just a dumb container. A ShaderModule class derived from the Asset class has been added, and this does correspond with a single .spv file. But you, the user, won't really need to deal with any of this.
      The result of this is that one material will work with tessellation enabled or disabled, quad, triangle, or line meshes, and animated meshes. I also added an optional parameter in the CreatePlane(), CreateBox(), and CreateQuadSphere() commands that will create these primitives out of quads instead of triangles. The main reason for supporting quad meshes is that the tessellation is cleaner when quads are used. (Note that Vulkan still displays quads in wireframe mode as if they are triangles. I think the renderer probably converts them to normal triangles after the tessellation stage.)


      I also was able to implement PN Quads, which is a quad version of the Bezier curve that PN Triangles add to tessellation.



      Basically all the complexity is being packed into the shader family file so that these decisions only have to be made once instead of thousands of times for each different material.
×
×
  • Create New...