Switching engines


So last weekend I had a look at the situation with Ogre (related to another project and not really specifically for thrive). I found out that Ogre 2.0 isn’t going to get updates and it’s basically obsolete and perhaps some of the issues we had with it was caused by this. Thus if we don’t switch to unreal we would have to update to Ogre 2.1 to keep up with new stuff (and that, too drops support for really old graphics cards).

Also that switch wouldn’t be the simplest as Ogre is heading towards not letting users mess with rendering as much: shaders are hidden much deeper and there’s a new shader block system (High Level Material System) that requires rewriting how our shaders work.

And that new version of Ogre has quite easy to use support for PBR (the same type of look that ue4 has by default) and an open source material editor: https://github.com/spookyboo/HLMSEditor. So really the biggest thing we would be missing is the full blown editor (with gui editing, asset importing etc.), which lets non-programmers add assets and other stuff to the game. So I still think this engine switch is required in order to speed up thrive development, but maybe I’m leaning a bit less towards unreal now that I’ve looked at the new Ogre stuff and the list of other libre game engines on github.


Update: the effort to switch to ue4 has basically fizzled out due to already getting very weird bugs (different behaviour on my computer than on crodnu’s) and it not being fully free and libre software.

So the current effort is in improving the engine with an engine written by me (https://bitbucket.org/hhyyrylainen/leviathan/src/7366e8d3951f51fb12ad6a16b9d09009fd3712f3/?at=develop). That, too uses Ogre and CEGUI making it very easy to replace the common parts in the thrive custom engine with it without completely breaking the gameplay code.

@crodnu is working on moving lots of the Lua things to C++, this way my porting job will be easier. And even if we decide to switch to some other engine it will be easier. There would still be lots of work in porting the thrive architecture and the parts that use Ogre to a new engine.
I also did try out Godot, but the way it needs you to structure your game is completely different compared to thrive so that, too would be tons of work to port.

The latest code is here: https://github.com/Revolutionary-Games/Thrive/tree/engine_refactor

Here’s a screenshot of the main menu in my engine (you might notice it looks exactly the same):

Release 0.4.0 Thread

I finally got around to making the video player work with my engine (I took the version I wrote for ue4 and added it into my engine):

Next up I just need to hook the GUI buttons and I can start working on porting the components and systems.


Instead of working on new stuff I integrated continuous integration into my engine: https://circleci.com/bb/hhyyrylainen/leviathan/tree/master

I might have to switch to a different one if that works too slow, but there doesn’t seem to be any good solutions for c++ projects other than hosting jenkins on a vps


I’ve been distracted by doing really complicated server setup. Now I’ve got one webserver hosting 3 different websites and a jenkins continuous integration server building leviathan documentation. I was going to move the continuous integration that runs tests there too, but it looks like circleci has given my builds more cpu cores all of the sudden.

So now the leviathan documentation is viewable online (and it automatically is updated every time the repo is updated): https://leviathanengine.com/doc/develop/Documentation/html/index.html

I just noticed that there are some out of date build instructions etc. still in there.


The intro video now works and the menu shows up after it has played. There are a few issues like it always using the same aspect ratio as the thrive window, which makes it looks stretched if not in 16x9 aspect ratio. Also there is no way to skip it currently.

But I’m going to move on to working on getting some components working and rendering some actual cell stage stuff.


Here’s a video of the start button changing the shown GUI.

This is the code that makes the magic happen in the GUI:

o GuiObject "Background/MainMenuInteractive/NewGameButton"{
        bool StartGame(GuiObject@ instance){
            // Disable all the menus
            instance.GetOwningManager().SetCollectionState("Background", false);
            // And show the microbe GUI
            instance.GetOwningManager().SetCollectionState("MicrobeRoot", true);

            // And notify the application class to start a new game
            return true;


So today I was trying to get the first thing working, the background. And I just couldn’t and now I found out that skybox / skyplane doesn’t work in Ogre 2.1 anymore http://www.ogre3d.org/forums/viewtopic.php?f=25&t=83023

Wasted time: too many hours


I finally got something to show up!


I just found a huge memory leak in CEGUI when using Ogre 2.1. Luckily I managed to already fix it.

On a more thrive related note I got entity component states to interpolate properly in my engine, I’ll get a video of that later.


Here’s a video of the interpolation system I have been working on:

Next I’ll start working on getting the thrive component types working.


GREAT! nice work


Finally got the background to be positioned correctly. But the nucleus is for some reason rendered transparently or something making it look like to be behind the background.


Are they in different z coordinates?


They are, in Ogre the height is actually the y coordinate. The camera is at +15 the nucleus model is at 0 and the background is at -50.

I even tried setting the model to be at +10 and it still looks like to be behind the background:

I think this has to do with me having to remove the transparency etc. settings from the materials, because Ogre said they where unknown (probably removed in Ogre 2.1).


They changed the coordinate system in ogre 2.1? What difference does it make using the z as the altitude (since ogre doesn’t handle physics)?
Also i just now see the nucleus in that image lol.


Ogre coordinate system has always been +Y being up.


So we were always using them backwards?


I guess if the camera was moved on the x and y axises with z being used for going farther from the camera, then we did use the “wrong” coordinate for up.


Unless using the “correct” coordinate types is relevant in some way the best option would be to be coherent with the physics engine coordinates, to avoid conversion bugs