Switching engines

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):

2 Likes

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.

2 Likes

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.

1 Like

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.

1 Like

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"{
    s{
        [@Listener="OnClick"]
        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
            GetThriveGame().StartNewGame();
            return true;
        }
        @%};
}
1 Like

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!

2 Likes

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.

2 Likes

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

The physics engine I use in Leviathan. Doesn’t have an “up” direction, so by setting the gravity vector to what ever you want, you define that as “down”. So there isn’t any reason to not do the coordinates the Ogre default way (also SFML sound and cAudio define +y as up).

Pretty much the only libraries that don’t by default have +y as up (most libraries let you set the up vector to be anything you want) are ones that want to use the DirectX convention.