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
Wasted time: too many hours
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
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.
