Things are getting closer to being done: https://github.com/Revolutionary-Games/Thrive/pull/790#issuecomment-514331968
Soontm it will be time do a public tech test to see if the game runs on different computers.
1 Like
Getting closer to having animations on flagella again:
Those are just the changes needed to handle importing the animation data…
1 Like
Code for the flagella animation is now done (hopefully). However the model and animation is a bit broken, but that is already being worked on by @Uniow. So hopefully the flagella will look good soon.
2 Likes
Added skybox importing and I added one to thrive. Seems it doesn’t do much for the membrane:
But in the editor it makes the grey hexes look less dull:
3 Likes
Speed changing of the flagella animation is back in.
Positioning of the flagella is now correct (on the membrane edge):
Opened an issue about the resizing being broken: https://github.com/GameFoundry/bsf/issues/382
1 Like
I guess I should post something here as well for this week.
I did mostly non-visible stuff:
- fixed compiling bsf on windows: https://github.com/GameFoundry/bsf/pull/386
- fixed the GUI being flipped when using directx
- added formatting script running to circleci, as my jenkins is being silly with it for some reason
- found out that vulkan is broken on linux, and reported it: https://discourse.bsframework.io/t/vulkan-crash-on-linux-after-update/492
I took a few screenshots just to put here:
Here I accidentally used the vertex buffer size for rendering so only a part of the membrane showed up.
Here’s a screenshot of renderdoc showing how the membrane is now a triangle list (to support directx):
I don’t have a screenshot of the working membrane as it looks exactly the same as before.
The membrane is now rendering as a triangle list, which means that directx support is closer.
3 Likes
The bsf version is now ready for early testing:
I forgot to mention that the pull request is now merged. All that’s left to do is fix a bunch of stuff and hopefully find some way to squeeze more performance on intel, however that might be a bit problematic:
I’m currently working on fixing crashing on shutdown (so that I can debug the reported memory leak): https://github.com/GameFoundry/bsf/pull/391
1 Like
The high memory usage was due to each organelle loading its texture (instead of there being one copy). There is now a partially working solution (I think it causes everything to be loaded exactly twice):
Fixing this properly needs a bunch of changes to the resource import process to create a manifest file. The good news is though that there was no memory leak related to bsf. However I did find one small(ish) memory leak, that is now fixed in Leviathan.
I’m also working on moving my custom hacky bsf setup, to be supported in bsf directly: https://github.com/GameFoundry/bsf/pull/391
3 Likes
I feel like this topic is once again relevant, with the huge number of compatibility issue reports (https://dev.revolutionarygamesstudio.com/report/30 193 currently) and what I presume to be actual bugs in bsf causing random crashing while trying to render: https://dev.revolutionarygamesstudio.com/report/38
These issues are currently not going to get better as the bsf developer has put bsf on the backburner after starting a new job. It’s been more than two months since the last commit and the developer has also not replied on the bsf forums in a while.
So as unfortunate it would be for short term progress, we need to consider a different graphics engine (or maybe even switching to godot, but that once again is way more work, with a new graphics engine the existing GUI can be kept as is). I’ve been looking at a bunch of different ones, but one that really caught my eye is diligent engine:
It has a bunch of nice features, like:
- Supports a ton of APIs DirectX11, DirectX12, Vulkan, Metal, and OpenGL 4.3+. So it should cover all the platforms, though I spotted in their documentation that On Windows 7 only Vulkan and OpenGL is usable, so people with old intel integrated graphics need Windows 10, but that shouldn’t be a problem.
- It is low level graphics API abstraction, meaning that it is basically a layer to help code so that your code can work with all the rendering backend. This should make it way less likely that there are things that are not possible. But at the same time this means I need to code our own graphics pipeline using the basic rendering operations.
- It seems to be in very active development with commits happening daily. But referring to the previous point I perceive only a small risk from the project being abandoned as it seems to be a thin enough library that I could consider working on it myself after I gain more graphics programming experience from working on such a low level library.
While low level by default, it has a pbr rendering module: https://github.com/DiligentGraphics/DiligentFX/tree/master/GLTF_PBR_Renderer but I haven’t yet checked how easy that is to use, if it is easy to use we can use that to render all the stuff in Thrive.
So my plan is
- First adding a bunch of abstractions so that Thrive doesn’t use anything bsf related, instead it would use Leviathan objects that wrap the bsf objects. With this a graphics engine change will be much more transparent to Thrive, though some changes will be required.
- Second change the engine graphics abstractions to use Diligent internally. And then make changes needed to thrive. But before fully committing I’ll try to make a tech demo to see if people with intel graphics can run the game.
This should reduce the impact of the change. And hopefully make the game playable for a large number of potential new fans who haven’t been able to play the game yet. The next phase is then to change out CEF which also causes a lot of compatibility issues with a custom GUI library that will at the same time be more lightweight as well as easier to use.
3 Likes