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.
@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.
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.
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"{
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;
}
@%};
}
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
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.
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.
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.