Thanks vannib!
1) Thanks, software is the abstraction layer to motion and very important to us. We are working as hard as possible to add features, fix bugs and add more titles. However we need to do it right. Some of our algorithms, like our Engine Vibration took 7+ months to develop, and recently our air heave was the same. This is the nature of doing things right and from scratch without relying on other open source software which we would have no control of and could not improve in the future. We will update our software roadmap shortly. You are right we missed a release in April 2022, but now looks like the first week of June 2022. This will include our new air-heave algorithm, DCS and X-Plane11 sims etc, which aligns itself for some of our DK6 customers waiting a few months now.
Additionally air-heave development might be in some parts added to our roll and pitch road algorithms to give them more definition at the limits rather than just saturating. Will write more about that when it becomes available. Should give the cars more feel at the limit and not just saturate, something our test driver Kenton Koch wanted to feel more.
So the other two slider we will be adding this year are the overall intensity slider and separate our the shift, braking and acceleration layers for better control.
All software/firmware updates happen automatically by just restarting the software.
F1 2022 should not be difficult to add, most of companies, just refresh the surface but the core physics engine and connections will stay the same. I've added it to our list roadmap. Thanks.
Sim Racing Studio and others, as far as I know, do their motion algorithms within the Windows OS which is a non-deterministic system and hence cannot guarantee real-time motion code execution. This topic is very detailed and past the scope of this thread, but Windows runs many processes in the background and needs to schedule them in priority order which you cannot control. We've played with many tools out there, that manage or prioritize Windows processes, such as this great tool
https://kingstar.com/products/rtos/ that we used for this project:
and also tried running other Linux RTOS systems to control our DK system before settling on a hard real-time system from Texas Instruments. Its simple and the RTOS is only 16KB, lol, but it means that certain algorithms need to be programmed in low level assembly language for this hard real-time motion execution. To us this is a guarantee or a necessity and ensures our idea of motion integrity, otherwise we are just guessing and assuming. But what this also means is that our software takes longer to develop and that we are starting from scratch when it comes to motion layer development. This is computer science level of thinking and implementation, its not easy at all, but this is the only way we think we can control the quality of the software going forward. Many of our current customers are very happy with the system as it is at the moment. We are not, lol, and will constantly improve our algorithms with time and priority. It's hard to comment on other software but they often have simpler relational algorithms for trying to replicate g-forces and/or using pre-programmed effects for certain conditions. One example is dirt oval, where the cars are 50% of the time sliding sideways with massive aero, very soft suspension and low tire pressure. With effect based motion the cars always shudder, an effect that 'resembles' the tire sliding sideways. The effect feels the same when sliding sideways on a clay like track, as they do when on grass, ice, concrete, dirt, asphalt, sand etc... this is the problem with effect based motion. It triggers false positives. We don't play that game. (no pun intended lol)
Hope that helps. ;-)
2) Velocity Trap is a fundamental layer that is available in all titles. It removes the robotic like nature of typical motion control systems and better translates the analog nature of vehicle dynamics. It's a difficult concept to grasp and we are awful at marketing/explaining. Will do another write up on it. Here is a video that talks about it and shows the visual evidence:
3) Negative Latency was our terrible attempt at humor for April Fools. My apologies. Although we hear some wild marketing claims out there and were taking a slight jab at those. "Never loose traction ever again," is another one I still don't understand which is often used for traction loss platforms.
But the joke was that Sigma would develop an algorithm that predicts the future and where the motion will be to give the most response or zero latency system. lol. We would be doing time travel basically. That being said, we did look into delay based netcode, such as this:
but its not necessary as we do not have vast distances and network hops to worry about. ;-)
Thanks for the great questions! Cheers!
