rigs of rods monster jam have linked steering

Current 1.x version is 1.10x magnifficently maintained by Pavel Rojtberg, see 'new and noteworthy' in 1.10 - then there's nextgen OGRE 2.1+, see FAQ on their wiki

OGRE upgrade: We're using outdated OGRE version - 1.9.

When time comes for rendering, relevant data are copied from simulation context to rendering context and rendering runs independently from next physics update. My scheme: single threadpool, physics tasks are inserted at fixed rate. I want RoR to be truly multithreaded with physics running in parallel with rendering.

single-and-half-threaded software: We're just a singlethreaded app which sometimes parallelizes something - see 'history' and 'design' above.

I already removed the duality it in but the new 'Actor' class is still a monster.

This sucks for both terminology and coding.

Code behind actors: The softbody actors (I'll call them such from now on) comprise of 2 structs: `class Beam` and ancestor `struct rig_t`.

It's already somewhat used in upstream and fully cleaned in Let's refer to simulated softbody objects as 'Actors' instead.

We employ a threadpool but make limited use of it.

But for historical reasons, some physics calculations run on variable timestep (time since last frame). We accumulate time spent rendering and then advance physics.

Our physics use Euler integration and run on 2khz frequency.

But for historical reasons, the parsed object is not reused.

When loading an actor ( Truck file format) we load+parse the file first into `RigDef::File` object, then spawn from it.

Our main simulation loop lives in `RoRFrameListener::EnterSimulationLoop()` and calls OGRE's 'renderOneFrame()' which invokes `frameStarted()` callback (same thread).

We use OGRE 3D for rendering - we init engine at startup and shut down on exit.

Our entry point is straightforward 'main()' function - it performs inits and then enters game state loop governed by GVar 'app_state'.

We embrace global variables via 'GVar' mechanism inspired by Quake's cvars - see file 'Application.h' and older 'GlobalEnvironment.h'.

However, some previous authors seem to have loved OOP while disregarding common sense.

RoR isn't OOP, it's structured and just makes use of objects.

Hopefully I'll compose something meaningful to put to our Doxygen docs. ** split to multiple posts because of character limit **Įarly draft, just notes from the top of my head. The reason to write it down right here right now is this excellent contribution from a new developer This is an entry point for new RoR developers - it describes how RoR currently works, why it sucks and what I'd like to do about it.

Rigs of rods monster jam have linked steering