Rigs of rods monster jam 0.4.0.7 code#

Here I at least cleaned up the `BeamEngine` and renamed it to `EngineSim`: I already did some experiments with Lua scripting (times ago) but I got nowhere because of the cross-simthread/mainthread logic and overall fragility (it blew up in my face). My idea: split apart raw softbody physics and any external updates (steering, hydraulics, torque, pressure) and perform the updates under const timestep via AngelScript scripting (performance is not a showstopper, tested). Motor sim starts in class `BeamEngine` (because Actor is Beam) and continues through a lot of ad-hoc updates elsewhere (brakes and more are done on frame-dependent timestep!!).

Rigs of rods monster jam 0.4.0.7 code#

engine/powertrain/drivertrain simulation: Although we're primarlily a land vehicle simulator, our capabilities are ridiculously limited and the code is a quagmire.Solution: use UTF-8 for everything and build appropriate filesystem API - I already started not long ago: The worst part is we can't deal with Unicode in file paths (I'm worried OGRE itself has problems). I introduced `*SanitizeUtf8*` functions to at least prevent exceptions. Unicode: We can't deal with it - there is a mixture of workarounds for this in the code (Ogre::UTFString, MyGUI::UString, broken copypasted snippets).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.