Hi everybody.
I can't get myself to work on the v0.4.8 release. RoR is still too glitchy to call 'stable', and new issues just keep coming. To make it worse for me, stabilizing RoR means 'resist the urge to fix any of this stuff' - and by extension, it means "just fix the code as it is, even though it's clearly all wrong and you'll throw it away when you get a chance". For the longest time I was letting off the steam by slowly moving things around while fixing bugs, but after the website collapse something snapped and I thought "what's the point?".
What I'm really doing right is just rewriting code to look and work more meaningfully without breaking anything. My dev branches:
TL;DR: Sorry guys, release v0.4.8 isn't coming anytime soon, the developer is too busy scratching his itches
I can't get myself to work on the v0.4.8 release. RoR is still too glitchy to call 'stable', and new issues just keep coming. To make it worse for me, stabilizing RoR means 'resist the urge to fix any of this stuff' - and by extension, it means "just fix the code as it is, even though it's clearly all wrong and you'll throw it away when you get a chance". For the longest time I was letting off the steam by slowly moving things around while fixing bugs, but after the website collapse something snapped and I thought "what's the point?".
What I'm really doing right is just rewriting code to look and work more meaningfully without breaking anything. My dev branches:
- dev-master-v4 . GitHub The main dev-branch, builds and works, I always do some random testing before I put things here (map scripts work, vehicles load, camera modes/flares/slidenodes/engine/ties working, planes take off, boats float...). To see what changed, see the commit history, I try to add meaningfull comments to each change. If you find something weird, just ask me "WTF?..." - you know.
- devmaster4-cameraman-C . GitHub - here I'm getting rid of our overly complex 'CameraManager'. It's badly designed - it updates the OGRE camera directly many times during a frame (whenever 'something happens' like player enters/exits vehicle). It also works on FPS timestep while it should work on physics timestep (risk of stuttering). It also scatters and duplicates data, so it's hard to see what's really going on.
- devmaster4-softbody-ptr-removal-UNTESTED . GitHub - (UPDATE 2018-03-16: completed, see below), I'm changing how the code reads and writes N/B. The purpose is to prepare grounds for changing how N/B data are stored in RAM and in which order are updates performed, which will bring FPS gains anywhere between 'big' and 'massive'. To understand what this is all about, I recommend watching youtu.be/WDIkqP4JbkE - even if you're not coders/tech people, just ignore the code in the slides, the presenter will entertain you.
- devmaster4-GfxScene-UNTESTED . GitHub - the current tip of my work, I'm building upon the "softbody-ptr-removal" branch above. Goal: Instead of having physics+rendering use the same data, let physics have the data for itself and do a copy for rendering. This will allow us to have actual multithreaded architecture where physics run asynchronously from rendering. For technical intro, check this code comment at GitHub
TL;DR: Sorry guys, release v0.4.8 isn't coming anytime soon, the developer is too busy scratching his itches
Last edited:
In RoR it's worse than elsewhere because OGRE 1.x engine is quite aged and inefficient, but also because we use DirectX9/OpenGL2 and our maps+vehicles consist of many many individual meshes with individual materials. For each mesh and each material, a draw call (or "draw batch") must be done which is very CPU-heavy under Dx9/OpenGL2 card drivers. Shadows are generated basically by doing another render from the light's point of view, so the problem gets order of magnitude worse. OGRE 1.10 uses Dx11/OpenGL3 which are better at this, but it's internally still not as efficient as OGRE 2.1+
