Jump to content

Compatibility Wrapper

reepblue

293 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 0
      I'm back from I/ITSEC. This conference is basically like the military's version of GDC. VR applications built with Leadwerks took up about half of Northrop Grumman's booth. There were many interesting discussions about new technology and I received a very warm reception. I feel very positive about our new technology going forward.

      I am currently reworking the text field widget script to work with our persistent 2D objects. This is long and boring but needs to be done. Not much else to say right now.
    • By Josh in Josh's Dev Blog 4
      Here are some screenshots showing more complex interface items scaled at different resolutions. First, here is the interface at 100% scaling:

      And here is the same interface at the same screen resolution, with the DPI scaling turned up to 150%:

      The code to control this is sort of complex, and I don't care. GUI resolution independence is a complicated thing, so the goal should be to create a system that does what it is supposed to do reliably, not to make complicated things simpler at the expense of functionality.
      function widget:Draw(x,y,width,height) local scale = self.gui:GetScale() self.primitives[1].size = iVec2(self.size.x, self.size.y - self.tabsize.y * scale) self.primitives[2].size = iVec2(self.size.x, self.size.y - self.tabsize.y * scale) --Tabs local n local tabpos = 0 for n = 1, #self.items do local tw = self:TabWidth(n) * scale if n * 3 > #self.primitives - 2 then self:AddRect(iVec2(tabpos,0), iVec2(tw, self.tabsize.y * scale), self.bordercolor, false, self.itemcornerradius * scale) self:AddRect(iVec2(tabpos+1,1), iVec2(tw, self.tabsize.y * scale) - iVec2(2 * scale,-1 * scale), self.backgroundcolor, false, self.itemcornerradius * scale) self:AddTextRect(self.items[n].text, iVec2(tabpos,0), iVec2(tw, self.tabsize.y*scale), self.textcolor, TEXT_CENTER + TEXT_MIDDLE) end if self:SelectedItem() == n then self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos, 0) self.primitives[2 + (n - 1) * 3 + 1].size = iVec2(tw, self.tabsize.y * scale) + iVec2(0,2) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 1) self.primitives[2 + (n - 1) * 3 + 2].color = self.selectedtabcolor self.primitives[2 + (n - 1) * 3 + 2].size = iVec2(tw, self.tabsize.y * scale) - iVec2(2,-1) self.primitives[2 + (n - 1) * 3 + 3].color = self.hoveredtextcolor self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos,0) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 1) self.primitives[2 + (n - 1) * 3 + 3].position = iVec2(tabpos,0) else self.primitives[2 + (n - 1) * 3 + 1].size = iVec2(tw, self.tabsize.y * scale) self.primitives[2 + (n - 1) * 3 + 2].color = self.tabcolor self.primitives[2 + (n - 1) * 3 + 2].size = iVec2(tw, self.tabsize.y * scale) - iVec2(2,2) if n == self.hovereditem then self.primitives[2 + (n - 1) * 3 + 3].color = self.hoveredtextcolor else self.primitives[2 + (n - 1) * 3 + 3].color = self.textcolor end self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos,2) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 3) self.primitives[2 + (n - 1) * 3 + 3].position = iVec2(tabpos,2) end self.primitives[2 + (n - 1) * 3 + 3].text = self.items[n].text tabpos = tabpos + tw - 2 end end  
    • By 💎Yue💎 in Dev Log 5
      The prototype of a four-wheeled vehicle is completed, where the third person player can get on and off the vehicle by pressing the E key.  To move the vehicle either forward or backward, is done with the keys W, and the key S, to brake with the space key.  And the principle is the same as when driving the character, a third person camera goes behind the car orbiting 360 degrees.

      I don't think the vehicle is that bad, but I'm absolutely sure it can be improved.  The idea is that this explorer works with batteries, which eventually run out during the night when there is no sunlight.
      Translated with www.DeepL.com/Translator
       
      Mechanics of the game.
      I'm going to focus on the mechanics of the game, establish starting point (Landing area), after the orbiter accident on Mars where all your companions died, now, to survive, you will have to repair your suit, oxygen runs out, good luck.  This involves replacing the oxygen condenser that is failing and the suit is stuck.

      On the ground and performance.
      The rocks, the terrain and the vehicle kill the SPF, but there is a solution, and everything is related to the chassis of the vehicle. That is to say that if I put a simple collision bucket for the vehicle, the yield recovers, something that does not happen if I put a collider of precise calculation for the car. This has the advantage of better performance but is not very accurate, especially when the car crashes with an object in front, because the horn of the car has no collision. And the solution to this, is to put a sliding joint, as was done with the area in which the player climbs the car and descends from it.


       
      On the rocks, I am trying to make them with the slightest polygons and the most distant from each other. 
      Obviously on Mars I can not create canyons, high mountains, is because the terrain does not produce shadows on itself, that's why the terrain tries to be as flat as possible, simulating a desert with dunes. 

      That's all for now.
       
×
×
  • Create New...