Developer suffering a "release block"

only_a_ptr

Lead Developer
Administrator
Developer
Joined
Jan 31, 2018
Messages
25
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:
  • 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:

klink

New member
Joined
Jan 14, 2018
Messages
4
  • softbody-ptr-removal-UNTESTED . GitHub - the very tip of all my work, 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
    Code:
    https://youtu.be/WDIkqP4JbkE
    - even if you're not coders/tech people, just ignore the code in the slides, the presenter will entertain you.
I doubt that.
Currently gfx settings like shadows are the FPS killer.



 
OP
OP
O

only_a_ptr

Lead Developer
Administrator
Developer
Joined
Jan 31, 2018
Messages
25
@klink It's normal that gfx settings have big impact on FPS :) 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+

When I said "FPS gains" in the last post, I was referring to physics performance, specifically collision. Just slight touch between vehicles may cause massive increase of CPU load. My guess is that there are 2 primary causes: <1.> poor data layout in RAM causing CPU stalls while fetching node positions to evaluate collision/update visuals <2.> Poor filtering before doing actual collision tests - too many individual arithmetic calculations

UPDATE: @klink: Please check out if either of these can help us:
- AMD μProf - AMD
- NVIDIA PerfHUD | NVIDIA Developer
- Profiling DirectX Apps (Windows)
 
Last edited:

Razz Kiran "Raven"

New member
Joined
Jan 25, 2018
Messages
17
So i run anywhere frum 30 to 60 fps. at any giving time. what do you thank i could run after the code rewrite?
 
OP
OP
O

only_a_ptr

Lead Developer
Administrator
Developer
Joined
Jan 31, 2018
Messages
25
So i run anywhere frum 30 to 60 fps. at any giving time. what do you thank i could run after the code rewrite?
Sounds like you have a 60Hz display and VSync enabled, so that would be undisrupted 60Hz for you. :) And if you turn it off and set all visuals to minimum, you should get ~250FPS
 

akaikitty

Active member
Joined
May 10, 2018
Messages
147
Location
channel islands
Don't cars tend to 'wake up' when you get within a few units of them? that's where i tend to have big FPS drops.

Is it certain that you're going to move with dx11? Lots of people here have hardware that struggles to catch decent frames with caelumXAntistrophicXOnevehicleMainlight, but then again 0.4 has some issues with older maps like Nhelens, with even auriga running better at times.
 
Top