Live for Speed now has a much needed update

[Alex Franchini]

One of the underdog simulators, Live for Speed, has finally received an update (version 0.6J) after a long period of silence.

Live for Speed was originally published in 2003 and developed by a three-strong team to become one of the most respected simulators around. While it's been overshadowed by newer, flashier games, LFS still has a loyal and dedicated following.

Patch 6J brings performance improvements in order to reduce the load on CPU and GPU. The game now also has a more accurate frame limiter, and Oculus VR users can enter and exit 3D-mode without leaving the game.

Changelog:

• Static vertex buffers reorganised to reduce DirectX instructions.
• Frames buffered (default 1) to allow next frame to start rendering.
• More efficient car distance sorting system for sound and graphics.
• Dynamic vertex buffers now set to use hardware vertex processing.
• Better frame rate in places where many objects may be visible.
• Sky texture is now drawn in mirrors.
• Layout editor object selection buttons are sorted by distance.
• Z-buffer depth setting can now be changed without restarting LFS.
• Mirror now uses 24 bit Z buffer if Z buffer setting is more than 16.
• Frame rate limitation system is now accurate and has better values.
• New frame info display shows sleep / physics updates / gpu waiting.
• Now using an event query instead of a lock for input lag prevention.
• Minimum sleep setting changed to "Sleep every frame" (yes / no).
• Now using Direct3D 9Ex if available (Windows Vista and later).
• Reduced glitch when autocross objects are optimised (e.g. on load).
• Reduced min / max values for "Sound lag" setting - default now 0.08
• New Audio Option "Sound when window is inactive" (off / on).
• Added a 3D level slider option to adjust monitor-based 3D views.
• Reduced CPU / GPU usage by sharing scene preparation for both eyes.
• Now using Oculus SDK version 0.6.0.1 which includes timewarp.
• You can now enter and leave Rift mode without restarting LFS.
• Smooth display (if you do not use SLI or force vertical sync).
• Monitor window view options : blank / one eye / two eyes.
• For users who cannot use the Oculus 0.6 runtime, you can still use the 0.5 run-time. Simply rename the ORDIRECT.dll to some other name, and LFS will then use LFSORDLL.dll instead (extended mode only).
• Some buildings at Westhill track were drawn using a slow method.
• Mouse clipped to window (CTRL+C) now works properly with ALT+TAB.
• Using mouse wheel to change gear did not work properly at high fps.
• Layout editor object selection buttons used interface button slots.
• Crash changing texture resolution with two or more objects selected.
• Anisotropic filtering did not work on car textures (including skin).

 

[TOOOlazy545]

This update has been out for almost two weeks, old news!

 

[RaceNut]

There have been a few small updates recently, some of them due to VR support improvements. Scawen has been active on the Oculus forums since the DK2 came out and seems to be staying on top of VR development for LFS.

 

[El-ahrairah]

@Sun Levi 's reaction

 

[Sun Levi]

That'll be my reaction when LFS S3 comes out...

 

[Steve William]

That'll be my reaction when LFS S3 comes out...

If it does...!

 

[TzZyO]

That'll be my reaction when LFS S3 comes out...

Now that would be "a much needed update" indeed. What's the point of improving framerates if it wasn't an issue, like, ten years ago already.
Seriously, is the work on the new tire model still underway? Or does Scawen think it's perfect as is?

 

[Richard Eriksson]

What should be done is scrap the LFS engine completely as it is now outdated and outpaced by other simulation platforms by far.

The talent should be put to use on a new platform where todays increase in processing power can be tapped fully...

 

[TzZyO]

What should be done is scrap the LFS engine completely as it is now outdated and outpaced by other simulation platforms by far.

The talent should be put to use on a new platform where todays increase in processing power can be tapped fully...

I don't think the team can afford simply re-writing everything anew... Unless we are ok with waiting till 2030 or so. But the sim desperately needs an improved tire model. Not higher framerates, not better VR support... The only update it should have before anything else is the new tire model, period.

 

[Associat0r]

What should be done is scrap the LFS engine completely as it is now outdated and outpaced by other simulation platforms by far.

The talent should be put to use on a new platform where todays increase in processing power can be tapped fully...

People saying stuff like this clearly don't understand how software development works.

 

[Richard Eriksson]

People saying stuff like this clearly don't understand how software development works.

Ok. I am a software engineer and credited with a double masters degree in the subject. I have worked more than 25 years in the field and on military simulations as project and development lead. So i do understand actually...

Care to evolve instead of spewing that comment out? Why would it be bad software design to scrap the old engine and follow the trends in hardware developments?

I still think i am right, but i will hear your argument.

 

[Associat0r]

Ok. I am a software engineer and credited with a double masters degree in the subject. I have worked more than 25 years in the field and on military simulations as project and development lead. So i do understand actually...

Despite you degree, it actually it looks like you don't understand what you're talking about.

Why would it be bad software design to scrap the old engine and follow the trends in hardware developments?

And on what do you base this, how do you know that their current design is insufficient or outdated? Marketing buzzwords?
Which hardware development trends would require them to scrap which parts of their engine? (be more specific, since you claim to be a software engineer after all)
The only part that might benefit from a rewrite to follow hardware trends is their gfx renderer, which is only a small part of the whole thing.

 

[Richard Eriksson]

Which hardware development trends would require them to scrap which parts of their engine? The only part that would benefit from this is their gfx renderer and even then you wouldn't have to scrap the whole thing.

Physics engine could be rewritten to fully use threading and offload main render loop. You could make use of higher parallellism also by handling inputs on separate low latency threads. Support for new physics libraries for rigid body (anything trackside, not the cars) could be added. A rewrite could also make use of newer middleware like DirectX11+ to align rendering better and bring in higher fidelity visual simulation.

Also an overhaul of the physics system could be handy, as new CPU power gives possobilities for greater accuracy and more systems, for instance chassis flexing and a proper driveline simulation, as well as doing a full subpatch, splined tyre model.

The reason i would advocate it is that Scawen is a really talented dev... The potential exist to take the lessons learned with LFS and turn it into something even better, as in better simulation...

The model LFS uses is more rigid than it has to be. For instance compare what ISI did between rFactor and rFactor2, where gMotor was transformed from good to awesome.

LFS has equal potential...

Instead answer me this, why would you advocate staying on a 2003 base instead of rewriting and improving? There is only so much evolving you can do before you need to rewrite the base, in my experience, as you are often tied down by architectural descicions that made sense 10 years ago but are not really how you would do it now...

 

[Associat0r]

Physics engine could be rewritten to fully use threading and offload main render loop. You could make use of higher parallellism also by handling inputs on separate low latency threads.

Multithreading has nothing to do with new hardware trends. Where have you been for the past decade?

Support for new physics libraries for rigid body (anything trackside, not the cars) could be added.

Again, nothing to do with new hardware trends and doesn't require a new physics library as this has been done more than a decade ago.

A rewrite could also make use of newer middleware like DirectX11+ to align rendering better and bring in higher fidelity visual simulation.

DX is a low level media API and not considered middleware and is not exactly needed (it's desirable however) for a higher fidelity visual simulation. See pCars with the -DX9 switch.

Also an overhaul of the physics system could be handy, as new CPU power gives possobilities for greater accuracy and more systems, for instance chassis flexing and a proper driveline simulation

This could be done on older hardware and doesn't need a rewrite of the whole engine.

as well as doing a full subpatch, splined tyre model.

You mean a physically-based tire model since there is no such thing as a subpatch, splined tire model.

The model LFS uses is more rigid than it has to be. For instance compare what ISI did between rFactor and rFactor2, where gMotor was transformed from good to awesome.

gMotor is only the graphics part of rFactor, pMotor the physics part and isiMotor the whole engine, and they never rewrote the whole thing.

 

[Richard Eriksson]

@Associat0r, stop talking nonsense. You really mean that there is not any progress attainable by hardware gains between 2003 and 2015? Also multicore is very much a new thing on the consumer software side as it is largely underused still.

Also do you mean to say multithreading on separate cores (with separate stacks) was possible at home in 2003? Because it was not. It is now.

Also, an engine of this size has a point where it needs to be rewritten for new stuff to be added, because the old constraints in data formats used and other architecture limits you. I wrote a book on this subject 5 years ago to be used in university course material and i find it as true now as my research proved then.

As for the tyre model, of course there are subpatch models. Those can be splined or non-splined depending on how you normalize between subs. In a subpatched tyre model the tyre is divided into subsurfaces and each of those is run through a formula (often relating angular velocity to axle speed, with contact adherence and pressure on the specific subregion) giving slip and deformation for each subsurface...

What do you mean with "physics based" tyre model? As opposed to what? "Fantasyserie based"? Any simulation model is based ön physics, however simplified for computational speed.

I get that you want to pose your weight now, but i will say this in a civil manner, you started by offending me and now you are just pulling stuff out to make it look like knowledge. I rest the case with that.

 

[Richard Eriksson]

@Associat0r, out of curiosity, what is YOUR development background in the field since you deemed it sensible to offend me on mine?

 

[Richard Eriksson]

And no, i don't want to keep up some useless fighting. I am just curious as it was a bold statement to declare i know nothing on software development, given my background... And a bit insulting. The fact that @Associat0r then just rated some valid posts as "funny" to devalue my points there, does not help.

But with that i will return the topic to the actual news update

 

[gamer19]

Ok. I am a software engineer and credited with a double masters degree in the subject. I have worked more than 25 years in the field and on military simulations as project and development lead. So i do understand actually....

Aren't you actually a "real life rally driver" ?
Or you're both, perhaps ?
If so... how did you manage those two such opposed interest.
You know... I'm just curious...

 

[Richard Eriksson]

Aren't you actually a "real life rally driver" ?
Or you're both, perhaps ?
If so... how did you manage those two such opposed interest.
You know... I'm just curious...

Yes i am. You do know that you are allowed to have hobbies in life? Actually the combination of my tech background and my racing hobby is why i am here in the first place.

Driving rallycars is not my line of work. Software is. See the difference there?

So before you barge in and imply more stuff about me (i see what you imply with your sarcastic tone) to defend whatever you feel you defend, stop and think for a while, tiger.

Summarize: I am a software architect for a living and i race cars for a hobby. Both for 20+ years. So yeah...

 

[TzZyO]

@Richard Eriksson
Actually, I think their driveline model is pretty neat already... To the point of letting use it as a training aid for the new folks who are about to get acquainted with driving a manual. The only other tittle that required a bit of skill while starting from a standstill was netKar Pro. And I'm not entirely sure the latter didn't have the hideous autobraking feature to prevent you from rolling downhill with the clutch disengaged.
They could, however, benefit from having the driveshaft flex (as in R3E) AND from the rev-matching clutch-less shifting for the appropriate gearboxes (partial support in R3E, full-on in Project CARS).

As for the "subpatch" tire model... Maybe you meant a brush-based one? I'm pretty sure that IS what LFS uses to this point. As do rFactor 2 and Project CARS... This type of modelling, however, seem to calculate interactions of a set of points comprising the tire's mesh with the road surface.