Wheel input/FFB feeling would be improved if it could also always be updated at 100Hz, regardless of display rate. Higher FPS reduces the seesawing problem too.
Physics loop doesn't seem to be very heavy for a CPU (with not as much cars in race) for example try minimizing LFS, CPU usage will fall down immediately, even though physics is still updated. There are other loops heavier in normal conditions.
Key reason for selecting 100 Hz, is probably 0.01s time precision. (1/100)
If physics would run at 120 Hz, first loop=0.008333s, second=0.01666s, ... users will definitely like such a times on splits
Ah, OK, excellent point, thanks. I had been thinking that open tracks were harder on the CPU because of the physics loop doing more, but that didn't quite make sense either. Your explanation does seem to match the evidence awfully well
Agreed, BUT (as I once suggested in the distant past) LFS could semi-trivially interpolate between the current position+time and the previous one to give much higher precision splits. This would free the physics clock to be run at whatever we want. (Probably same for everyone tho, or sync issues...)
What's not overly clear is whether we'd gain anything at all by exceeding 100 Hz. How does one quantify smoothness?
Last night I played with limiting the frame rate to 50fps (I was hoping for exactly 2 physics updates per frame). It didn't really work though as the expected frequency lock did not occur - it was dancing around the 48 fps mark... (It was capable of 90-100 fps when not limited.)
But that would be a lie. Do you really want to lose a race because the game engine took a guess. I guess you could make the argument that everything is a lie.
Huh?
I'm unsure where you see a problem here.
Interpolation of a smoothly varying quantity is NOT the same as a guess.
(In fact, it's arguably better than the current scheme, but the difference would only be apparent if you really split hairs.)
Neilser, do you mean something like this? (attachment)
Circles with numbers represent point (physical) where physics is calculated.
When LFS detect that split has been passed, it calls function which will calculate time more "precisely".
For example:
SplitTime = TimeInPoint2 - LengthOf_a / VelocityInPoint2;
Its not like Velocity can change much between two time steps (0.01s).
IMO its good on a paper, saves CPU power (no need to use 1000Hz physics to get 1ms splits precision)...
Is there any crash address? Although I'm guessing it's not in the LFS module anyway so I might not be able to fix it. Does LFS crash if you use SHIFT+F4 to go to a window?
I don't really know what that means, what is the 1.08 version?
Is there a version of SoftTH that uses an edited version of the DX9_43.dll that LFS seems to use? As far as I understand it, LFS uses DX9_43.dll rather than DX9.dll because I have used the latest version of DX9, the June 2010 version. I have assumed this is the best one to use and although some people will have to update their DirectX runtime, it's really the version to have because a lot of games will require DX9_43.dll.
My knowledge about this is sketchy and full of assumptions, so if anyone knows better, please do let me know.
Yeah, that's pretty much what I mean (many ways to tackle it but that's one).
And in fact I reckon LFS already has all the maths to handle velocity changing between timepoints because I seem to recall that it uses multiple derivatives in order to make multiplayer mode work well with only a few updates per second. (Can't recall how many derivatives tho.) That's the part that could make it more accurate to do it by interpolation than (what I'm guessing is) the current scheme
(To do the best possible job on it, you would also need to store the previous point's information - position, time, velocity, accel, and the higher derivatives; the storage required would be negligible. However, doing it by just using the current point's info is probably acceptably accurate anyway.)
In the Box the same, the car is to big (but the AI & Color selection and the Setup selection is on the right place in the Game but not on the Screenshot).
Cars and drivers in menu screens are now antialiased
New Graphics Option : Mirror antialiasing
Oculus Rift :
New option : Antialiasing - NOTE : this reduces frame rate a lot...
Fixes :
FIX : Setup could (rarely) be corrupted when joining. Now detected and spectated with message.
FIX : NumConns was set to an invalid value of zero after disconnecting from an online host.
FIX : Arrow keys were re-enabled in the input dialog by using the code page selector.
Looks amazing. Great job. Will DX9 make it easier to have multiple(the other driver's) mirrors at the same time? I wonder how much this will "eat" our FPS though.
...on my near ancient system:
Win-7 64bit, AMD PhenomII-955, Radeon HD5777
nearly no reduction in frame rates with mirror-AA on, (I use 4x fs-AA, 4x mirror-AA, 4x-fs-AF, peaks to near-100fps, drops down to ~60fps when inside a big field. (( 1920x1200; everything else on high ))
I do not use "v-sync", by the way.
I had the brief impression of 2..3 sprint-races, yesterday on cargame-S2, so far it did not seem to reduce performance. If anything things might have smoothened a little bit - but that might just be a false impression because of a small grid, late in the evening / night-time.
However: big thumbs-up for keeping us updated on development-progress, again
I've now looked into this. Unlike DX8, DX9 allows vertical sync in a window and that is the default setting. I've now switched it off with one line of code.