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.

Quote from Neilser :

My own particular problem right now appears to be linked to CPU overload (open tracks). Not sure what would fix that. Is it really the case that the physics loop is still updating at 100 Hz even when the CPU is pegged and the graphics update rate falls to 30 fps or less?

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.

Quote from dawesdust_12 :

why not look towards a 120hz cycle for the physics as there are already displays that run at 120hz (plus divides evenly by a 60hz display, rather than having slight drift).

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

Quote from DANIEL-CRO :

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.

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

Quote from DANIEL-CRO :

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

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.)

Quote from Neilser :

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...)

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.

Quote from Dygear :

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)...

Quote from Fordman :

Just a heads up, as it is a bug but not. If you use SoftTH and the LFS Patch, and you go to windowed mode when connecting ( I know who does this now ) LFS crashes back to desktop.

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?

Quote from Fordman :

Also, the new patch doesn't work with the DX9.dll file for SoftTH. You still have to use the 1.08 version of SoftTH.

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.

Quote from Scawen :

My knowledge about this is sketchy and full of assumptions, so if anyone knows better, please do let me know.

Best person to ask would be Kegetys as he created SoftTH.

Quote from DANIEL-CRO :

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)...

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.)

Is this a bug? (E613/the car is to big)



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).



(incidentally i have about 12 FPS more too )

*sry for my bad english*

Graphics :

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.

Quote from Scawen :

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.

Quote from dawesdust_12 :

Best person to ask would be Kegetys as he created SoftTH.

For the record:

Quote from Kegetys :

[..]SoftTH does not modify or care about the D3DX utility library dlls, it only uses D3D9 itself (d3d9.dll). Switching to windowed mode crashing is likely the same issue as "alt-tabbing" crashing, it is a known limitation...[..]

***
LOVE the AA mirrors

AAed mirrors working great!

Quote from MandulAA :

AAed mirrors working great!

they just miss some more resolution (maybe as graphic option) and skies easy ... need also cockpit : D


edit: AAed dash possible?

Working great! it's compatible with custom AA, and I didn't loose even 1 FPS with AA mirror on

some screens for comparison:

Quote from Specht77 :

Working great! it's compatible with custom AA, and I didn't loose even 1 FPS with AA mirror on

some screens for comparison:

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

Just out of curiosity, there happens to be one server running on E14, how is that?

Hm.. not a server opened directly from a 0.6E14 client?

Multiplayer... Start new host...

Ah, simple as that, sorry

Quote from Flame CZE :

Just out of curiosity, there happens to be one server running on E14, how is that?

Yeap, exactly. By the way, i noticed when it's windowed it's forcing the FPS to what my monitor's hz. Is it a limitation of DX9?

Quote from DrBen :

...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

near ancient, i run lfs on a pentiun 4 3.2ghz, 2gb ram and HD 2600 pro
running lfs on max settings on 1800x1440 have 30fps on a full 32car grid

with "mirrors AA" i have 1fps loss so is not a big deal

also i didnt notice any increase in the performance on lfs at all, still having the exact same fps as i have for the past 2 years

Quote from Inouva :

also i didnt notice any increase in the performance on lfs at all, still having the exact same fps as i have for the past 2 years

I have less FPS(5-10) with that patch with the same settings. Mirrors AA make no difference in FPS.

Quote from DarkKostas :

Yeap, exactly. By the way, i noticed when it's windowed it's forcing the FPS to what my monitor's hz. Is it a limitation of DX9?

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.