Yes, probably need a bit more practice on those bends. 
The transitions were done with the real time while the video was recorded quite slowly, so that's why the transitions were too fast.
Here it is redone using the actual frame steps, so it looks as it does in game.
Here it is redone using the actual frame steps, so it looks as it does in game.
I'm not sure what you mean. Are you referring to a difference between the two versions?
They both have the same rate of adjustment.
The new one uses centre-weighted metering, which has two advantages:
1) Exposure based more on what you are actually looking at, instead of peripheral vision.
2) More stable because peripheral parts often have large bright or dark areas that have a bad effect on exposure.
OK here it is. I think that:
1) The sky brightness fluctuations are reduced a bit before entering the tunnel.
2) Slightly earlier exposure reduction at end of tunnel.
Old: https://youtu.be/YL7q4t5esyI
New: https://youtu.be/jkudBQO4rfQ
A quick update today, centre-weighted metering prioritises pixels nearer the centre of the image.
At Fern Bay, the old version is too influenced by the white kerbs, so the exposure is reduced too much.
At Westhill, the new one starts to expose for the outside world more quickly at end of tunnel.
At Fern Bay, the old version is too influenced by the white kerbs, so the exposure is reduced too much.
At Westhill, the new one starts to expose for the outside world more quickly at end of tunnel.
I guess that might point to an issue in Windows itself, in the Direct3D 9 support.
One thing that hasn't changed recently is LFS itself.
Doing a search based on the error D3DERR_DEVICEHUNG...
This isn't very helpful but according to Chuck Walbourn:
https://stackoverflow.com/questions/61915988/how-to-handle-direct3d-9ex-d3derr-devicehung-error#61944287
I don't think I can get involved at this time. It may be the people who write video card drivers don't do a lot of testing for Direct3D 9Ex these days, so errors might creep in.
It's better for me to continue spending my time on the D3D11 version that I am developing intensely already.
This isn't very helpful but according to Chuck Walbourn:
https://stackoverflow.com/questions/61915988/how-to-handle-direct3d-9ex-d3derr-devicehung-error#61944287
I don't think I can get involved at this time. It may be the people who write video card drivers don't do a lot of testing for Direct3D 9Ex these days, so errors might creep in.
It's better for me to continue spending my time on the D3D11 version that I am developing intensely already.
What changed a few weeks ago? Did you install a new graphics driver at that time? Can you try reverting to an older graphics driver? Nothing changed in LFS, so it sounds to me like a fault in the graphics driver or D3D.
Your thread title says "D3D device error" but you didn't include that in your report. If LFS gives this message it suggests that the instance of Direct3D 9 reported an error and had to be restarted. Could there be a problem with the D3D9 support, which is not used by most games now?
EDIT: It's possible there could be a clue in the deb.log file after the hang, a message including a D3DERR_xxx value.
Something like:
D3D device error : D3DERR_xxx
Maybe the missing part in place of 'xxx' can give us a clue.
Your thread title says "D3D device error" but you didn't include that in your report. If LFS gives this message it suggests that the instance of Direct3D 9 reported an error and had to be restarted. Could there be a problem with the D3D9 support, which is not used by most games now?
EDIT: It's possible there could be a clue in the deb.log file after the hang, a message including a D3DERR_xxx value.
Something like:
D3D device error : D3DERR_xxx
Maybe the missing part in place of 'xxx' can give us a clue.
Last edited by Scawen, .
Yes I think that should be possible, the two screen assumption could be avoided if the primary monitor rectangle matches the desktop rectangle. I've made a note about it.
Hi, LFS has taken a guess that you have a two screen setup.
You can correct this, in the Options - View screen.
There is an option "Multiple screen layout" where you will see it is set to 1 left screen.
You can set that to zero and then it will work as a single wide screen.
You can correct this, in the Options - View screen.
There is an option "Multiple screen layout" where you will see it is set to 1 left screen.
You can set that to zero and then it will work as a single wide screen.
While I am sure your suggestions are sensible, I am not working on the vehicle editor as part of this release. the idea is to get the new version released, so I then have time to work on other things including vehicle editor improvements. Please feel free to post vehicle editor suggestions in the correct forum section: https://www.lfs.net/forum/532
The current plan is to avoid delaying the release for clouds. I love clouds and will miss them in the early versions of new LFS. But it's a big job with many technical difficulties and that's why there will be no clouds at first, although I do want to allow completely overcast (i.e. the whole sky is a cloud).
It's a tricky issue at the moment and that is one thing lacking in the vehicle system at the moment. We really need some way to separate the parts of the dashboard that are illuminated by the environment (in traditional dashboards that are not just a computer screen) and the other parts that are self-illuminated like lights and the modern screens. I'm sure that in real life these modern screens must adjust their brightness a great deal depending on the lighting conditions, to be visible in the day but not completely blinding in the night. In some way, all our dashboards in LFS are self-illuminated like the modern computer screens, so I think they will have to start out light-sensitive and self-adjusting, even if that is unrealistic. Awaiting the more proper dashboard support mentioned above. I've probably not explained myself very well.
It's a completely new system with D3D11 graphics, dynamic lighting, 1000Hz physics, multithreading, dynamic echo rendering. It's not a thing you could release half of.
To be honest that would be a bit like going to your BMW dealer after hearing they are developing a completely new car, and saying, I have lots of money, can you at least sell me the seats, steering wheel and some suspension parts, it would be great, I can stick it in my existing BMW that is from an entirely different era, it'll be no problem.
In fact, the whole thing goes together and has to be in one piece.
[ EDIT:
In case my rubbish analogy makes no sense, I'll say it straight: The new tracks are constructed in a new editor, for a new version of LFS. They cannot be loaded into an old version of LFS that is completely incompatible. And the new lighting system cannot be released without updated tracks. Think of it more like LFS version 2, it's completely different.
Three more points:
1) Many, many, updates from the new version HAVE been copied into the old LFS, just look at the releases of the past few years with so many updates! It's funny how people forget how much has been done in the past few years.
2) The idea is that when the new version is finally released, updates can be done more easily because I don't have to copy the same updates into two different versions of LFS and development can be finally back on track.
3) This development is a huge part of my life. If you are desperate for it to be released, try multiplying that feeling by 1000x and then you may understand how important it is for me to get it released.
end of EDIT ]
To be honest that would be a bit like going to your BMW dealer after hearing they are developing a completely new car, and saying, I have lots of money, can you at least sell me the seats, steering wheel and some suspension parts, it would be great, I can stick it in my existing BMW that is from an entirely different era, it'll be no problem.
In fact, the whole thing goes together and has to be in one piece.
[ EDIT:
In case my rubbish analogy makes no sense, I'll say it straight: The new tracks are constructed in a new editor, for a new version of LFS. They cannot be loaded into an old version of LFS that is completely incompatible. And the new lighting system cannot be released without updated tracks. Think of it more like LFS version 2, it's completely different.
Three more points:
1) Many, many, updates from the new version HAVE been copied into the old LFS, just look at the releases of the past few years with so many updates! It's funny how people forget how much has been done in the past few years.
2) The idea is that when the new version is finally released, updates can be done more easily because I don't have to copy the same updates into two different versions of LFS and development can be finally back on track.
3) This development is a huge part of my life. If you are desperate for it to be released, try multiplying that feeling by 1000x and then you may understand how important it is for me to get it released.
end of EDIT ]
Last edited by Scawen, .
There is no plan to release track editor in the near future. It's kind of a long term dream of something that may or may not happen. It would probably be a year or two or more of work like the vehicle mods. It's difficult to even imagine how it could work and the tracks would be distributed. It can't work like the vehicle mods. Anyway, I say this not to start a discussion about the track editor, that I cannot get involved in at this time, but to make sure people don't have false hopes. I simply added a few more features to help Eric use the track editor, as I have been doing for the last 25 years or so.
That message is probably because last time you started LFS, the headset was not connected. We need to see the openvr.log after a successful entry to VR.
In LFS there are only two options, OpenVR and Oculus Rift. I believe OpenVR is the only choice for most headsets, but all the Meta ones can use "Oculus Rift" which I should probably rename. But I'll need to know if it does work on Meta headsets... or maybe the whole option should be deleted.
To select Oculus, start LFS in the normal way (not VR) and then:
Options - View
At top of screen is a 3D button.
Click that button and you can select Oculus Rift.
It would be good to know if that works. If not, then try OpenVR again and you can paste that log result, I'll have a look and see if there are any clues in there.
In LFS there are only two options, OpenVR and Oculus Rift. I believe OpenVR is the only choice for most headsets, but all the Meta ones can use "Oculus Rift" which I should probably rename. But I'll need to know if it does work on Meta headsets... or maybe the whole option should be deleted.
To select Oculus, start LFS in the normal way (not VR) and then:
Options - View
At top of screen is a 3D button.
Click that button and you can select Oculus Rift.
It would be good to know if that works. If not, then try OpenVR again and you can paste that log result, I'll have a look and see if there are any clues in there.
Technical progress report, March 2025
Hello Racers,
We have been working hard to get LFS ready to release. As many of you know from a recent report I have incorporated the current public tyre physics into the new development version. We call it the Retro model. It's the same tyre physics but now at 1000Hz and with a self-aligning torque component that slightly improves the force feedback. The idea is to get the new graphics out without further delaying the release to await the new tyre model that is still unfinished. We also described how Eric has expanded Kyoto massively, in a way that reminds you of Westhill but with more roads and with its own character. South City is all opened up too. Eric has continued to work on South City and Kyoto.
On my side, since the start of February, it has been mainly technical work finishing loose ends from the graphical update. In a roughly chronological order, areas covered in early February include:
Force feedback (appropriate filtering to prevent spikes)
ABS (updated for 1000Hz physics updates)
Thread-related crash related to moving subobjects
Retro model updated to use new system for friction on various surfaces
AI - some bugs were present after reinstating the Retro model
Then something I found interesting that can be illustrated with screenshots. As we now use physically based rendering and high dynamic range, the exposure (brightness of the final image) has become an issue, just as it is in real life. The difference between light areas and dark areas can be quite extreme. For example if we used an exposure level suitable for outside on a sunny day, then the inside of a tunnel or a multi-storey car park would look extremely dark, even with artificial lights switched on. The exposure must be turned up in these cases and we do that by analysing the output image for brightness and constantly updating the exposure.
So far, so good, but it's a tricky thing to get right. In a typical in-car view there is the dark car interior, the bright sky, and the landscape you actually want to see. It's not good enough to take the average of the whole scene and adjust the exposure based on that. Certain areas are of interest and they need to be exposed correctly.
Two examples that produce the wrong result if we consider the whole image.
1) In an open wheel racing car, you can see so much of the sky that the exposure is reduced and the image becomes too dark.
2) In a car with restricted view of the sky and a dark interior, a lot of the image is dark and so the exposure is turned up too high.
In the FERA, an approved mod by CarlosSainz55, the overall image is quite dark so the exposure ends up too high for the scenery.
In the FOX, the overall image is bright so the exposure ends up too low.
I used a trick, to identify the scenery using the alpha channel. When rendering the sky (each frame) and the interior of your own car in a driving view, I made sure the alpha channel of the pixels was set to zero (like transparency). The alpha channel was set to not transparent when drawing the scenery. So the image that is read to create the histogram for the exposure calculation, looks a bit like this. The magenta indicates where the alpha channel is left at zero.
Now the exposure calculation can consider only the parts that are not transparent. The exposure in driving views and trackside cameras is far more usable and stable, no longer a problem and you are mostly unaware of exposure changes as you drive around. Exposure adjustments as you move into and out of darker places seem appropriate and helpful.
One thing on my list was Z-buffer issues, that I had noticed at Kyoto and have always been around, usually seen as flickering of two nearby surfaces when it's not clear to the graphics card which pixels are nearer to the viewpoint. I noticed a post by Bokujishin in which he mentioned the "Reversed-Z" method that can produce more accurate Z-buffer results with no loss of performance. It is a now well known method in which the Z buffer values go from 0 in the distance, to 1 at the near clipping plane, instead of the other way round. I tried a quick experiment that did show an improved Z-buffer and then spent a couple of days working it in properly and solving the bugs and issues that inevitably come up when you make such a change in a complex program.
While doing that, I learned about the infinite far plane, a slight change to the projection matrix that allows us to avoid cutting off pixels that are rendered beyond a certain distance, with barely any loss of Z buffer accuracy (that had already been massively improved by the Reversed-Z system). This seemed to me almost like magic, but I tried it out and it worked perfectly. It's not the usual thing to find a little code that simplifies things and provides a better result without any downside.
One of the issues that had come up when first implementing the Reversed-Z system was fog. The haze effect that helps create a sense of depth by including more of the sky colour as objects are further away. It didn't work at all but by a simple change I was able to restore a Z value to the shaders and fix the fog. But as usual, one thing leads to another and I started to look at an ongoing problem we had, with fog glowing in dark places. The short explanation is that our graphics engine doesn't really know which parts of the air are in sun or shade, so even when the camera exposure is turned up (in a tunnel or car park) the fog effect still appears as if you are looking through lit air. And as the exposure is up by such extreme values, the fog level then appears to be incredibly bright and it looks quite bad. A previous workaround had attempted to alleviate the issue by starting the fog only after a certain distance. But it wasn't a good fix: in a long tunnel you could see a 'fog line' moving down the tunnel 120 metres in front. This can be seen in the South City Work in Progress video made by Victor in 2021 (time 2:40).
120 metres was OK for car parks but not for tunnels. In the end we came up with a solution based on a comparison between the image-based exposure, and the predicted exposure if you were outside (based on a simple calculation). Now when the image-based exposure is much higher than the predicted exposure, the fog is turned down and this seems to solve the problem in a way that it it no longer perceptible as an issue. Glowing fog in dark places is no longer, while haze in open areas is unaffected.
Continuing work after that included:
Shadows: a useful optimisation and slight improvement in accuracy
VR: post-processing is now available and final image submitted as 32-bit
VR: fix for Vive Pro 2 and any other headsets with non-square pixels
Interface: shaders to show some interface elements in greyscale
Public version: Compiled public version exe for the first time
Track editor: Some minor usability improvements
Still to do:
Support for pop-up headlights and handlebar mounted headlights
- these currently are undetected and do not cast a beam
Headlight analysis to allow smaller headlights to be drawn more brightly
- currently intensity is constant so a large headlight appears brighter
Take more steps towards building an actual public version
- currently exe runs but can only get as far as track selection screen
Some amount of adjustable weather, e.g. overcast sky
- not supporting clouds for this version but some options are possible
When will it be released?
We still can't say. There are several things on our lists and new things keep popping up, so it's not possible to give an estimate.
We have been working hard to get LFS ready to release. As many of you know from a recent report I have incorporated the current public tyre physics into the new development version. We call it the Retro model. It's the same tyre physics but now at 1000Hz and with a self-aligning torque component that slightly improves the force feedback. The idea is to get the new graphics out without further delaying the release to await the new tyre model that is still unfinished. We also described how Eric has expanded Kyoto massively, in a way that reminds you of Westhill but with more roads and with its own character. South City is all opened up too. Eric has continued to work on South City and Kyoto.
On my side, since the start of February, it has been mainly technical work finishing loose ends from the graphical update. In a roughly chronological order, areas covered in early February include:
Force feedback (appropriate filtering to prevent spikes)
ABS (updated for 1000Hz physics updates)
Thread-related crash related to moving subobjects
Retro model updated to use new system for friction on various surfaces
AI - some bugs were present after reinstating the Retro model
Then something I found interesting that can be illustrated with screenshots. As we now use physically based rendering and high dynamic range, the exposure (brightness of the final image) has become an issue, just as it is in real life. The difference between light areas and dark areas can be quite extreme. For example if we used an exposure level suitable for outside on a sunny day, then the inside of a tunnel or a multi-storey car park would look extremely dark, even with artificial lights switched on. The exposure must be turned up in these cases and we do that by analysing the output image for brightness and constantly updating the exposure.
So far, so good, but it's a tricky thing to get right. In a typical in-car view there is the dark car interior, the bright sky, and the landscape you actually want to see. It's not good enough to take the average of the whole scene and adjust the exposure based on that. Certain areas are of interest and they need to be exposed correctly.
Two examples that produce the wrong result if we consider the whole image.
1) In an open wheel racing car, you can see so much of the sky that the exposure is reduced and the image becomes too dark.
2) In a car with restricted view of the sky and a dark interior, a lot of the image is dark and so the exposure is turned up too high.
In the FERA, an approved mod by CarlosSainz55, the overall image is quite dark so the exposure ends up too high for the scenery.
In the FOX, the overall image is bright so the exposure ends up too low.
I used a trick, to identify the scenery using the alpha channel. When rendering the sky (each frame) and the interior of your own car in a driving view, I made sure the alpha channel of the pixels was set to zero (like transparency). The alpha channel was set to not transparent when drawing the scenery. So the image that is read to create the histogram for the exposure calculation, looks a bit like this. The magenta indicates where the alpha channel is left at zero.
Now the exposure calculation can consider only the parts that are not transparent. The exposure in driving views and trackside cameras is far more usable and stable, no longer a problem and you are mostly unaware of exposure changes as you drive around. Exposure adjustments as you move into and out of darker places seem appropriate and helpful.
One thing on my list was Z-buffer issues, that I had noticed at Kyoto and have always been around, usually seen as flickering of two nearby surfaces when it's not clear to the graphics card which pixels are nearer to the viewpoint. I noticed a post by Bokujishin in which he mentioned the "Reversed-Z" method that can produce more accurate Z-buffer results with no loss of performance. It is a now well known method in which the Z buffer values go from 0 in the distance, to 1 at the near clipping plane, instead of the other way round. I tried a quick experiment that did show an improved Z-buffer and then spent a couple of days working it in properly and solving the bugs and issues that inevitably come up when you make such a change in a complex program.
While doing that, I learned about the infinite far plane, a slight change to the projection matrix that allows us to avoid cutting off pixels that are rendered beyond a certain distance, with barely any loss of Z buffer accuracy (that had already been massively improved by the Reversed-Z system). This seemed to me almost like magic, but I tried it out and it worked perfectly. It's not the usual thing to find a little code that simplifies things and provides a better result without any downside.
One of the issues that had come up when first implementing the Reversed-Z system was fog. The haze effect that helps create a sense of depth by including more of the sky colour as objects are further away. It didn't work at all but by a simple change I was able to restore a Z value to the shaders and fix the fog. But as usual, one thing leads to another and I started to look at an ongoing problem we had, with fog glowing in dark places. The short explanation is that our graphics engine doesn't really know which parts of the air are in sun or shade, so even when the camera exposure is turned up (in a tunnel or car park) the fog effect still appears as if you are looking through lit air. And as the exposure is up by such extreme values, the fog level then appears to be incredibly bright and it looks quite bad. A previous workaround had attempted to alleviate the issue by starting the fog only after a certain distance. But it wasn't a good fix: in a long tunnel you could see a 'fog line' moving down the tunnel 120 metres in front. This can be seen in the South City Work in Progress video made by Victor in 2021 (time 2:40).
120 metres was OK for car parks but not for tunnels. In the end we came up with a solution based on a comparison between the image-based exposure, and the predicted exposure if you were outside (based on a simple calculation). Now when the image-based exposure is much higher than the predicted exposure, the fog is turned down and this seems to solve the problem in a way that it it no longer perceptible as an issue. Glowing fog in dark places is no longer, while haze in open areas is unaffected.
Continuing work after that included:
Shadows: a useful optimisation and slight improvement in accuracy
VR: post-processing is now available and final image submitted as 32-bit
VR: fix for Vive Pro 2 and any other headsets with non-square pixels
Interface: shaders to show some interface elements in greyscale
Public version: Compiled public version exe for the first time
Track editor: Some minor usability improvements
Still to do:
Support for pop-up headlights and handlebar mounted headlights
- these currently are undetected and do not cast a beam
Headlight analysis to allow smaller headlights to be drawn more brightly
- currently intensity is constant so a large headlight appears brighter
Take more steps towards building an actual public version
- currently exe runs but can only get as far as track selection screen
Some amount of adjustable weather, e.g. overcast sky
- not supporting clouds for this version but some options are possible
When will it be released?
We still can't say. There are several things on our lists and new things keep popping up, so it's not possible to give an estimate.
There is no option to remove the crosshair. It should only be visible in menus anyway so should not affect your driving.
That is the first time I have heard of a loss of position tracking in any VR headset. I'd be interested to see the contents of your openvr.log file that is created when you enter VR.
But that brings me to a question, if you have a Quest 3, why are you using OpenVR? Does it not work if you select the "Oculus Rift" option? I'd be very interested to know the answer. Maybe it does work, but you don't select "Oculus Rift" because it's really a Meta Quest?
That is the first time I have heard of a loss of position tracking in any VR headset. I'd be interested to see the contents of your openvr.log file that is created when you enter VR.
But that brings me to a question, if you have a Quest 3, why are you using OpenVR? Does it not work if you select the "Oculus Rift" option? I'd be very interested to know the answer. Maybe it does work, but you don't select "Oculus Rift" because it's really a Meta Quest?
I've reinstated the round templates, allowing the new style options.
The change is that practice/qualify/race can all be specified in minutes/hours/laps without restriction.
This required some extra data in the default round format (which is stored in a different way from actual rounds). That means the old default round storage format is invalid and old round templates do not appear.
Please try it and let me know if you think it is working OK.
rane_nbg, I understand your other requests, but as I'm not really good at adding web page input systems and changing Victor's code, it's not easy for me so I can't get into it at this time while I am on a big push to get to our release.
1) The car selection option I see is a pain. At least now you can leave it as "unspecified" due to a recent change.
2) The use of a full calendar for every session in a round seems annoying, I get it. I think it should be you specify the start time of the round, and the sessions should have time offsets from that start time. In that case, the offsets could be inlcuded in the default event format.
But right now I am battling my things to try to get to a release, so I can't take on this extra confusion in the web languages that I'm not really good at. I can do these things but, as you know, it's slow progress working in someone else's system, in strange languages.
The change is that practice/qualify/race can all be specified in minutes/hours/laps without restriction.
This required some extra data in the default round format (which is stored in a different way from actual rounds). That means the old default round storage format is invalid and old round templates do not appear.
Please try it and let me know if you think it is working OK.
rane_nbg, I understand your other requests, but as I'm not really good at adding web page input systems and changing Victor's code, it's not easy for me so I can't get into it at this time while I am on a big push to get to our release.
1) The car selection option I see is a pain. At least now you can leave it as "unspecified" due to a recent change.
2) The use of a full calendar for every session in a round seems annoying, I get it. I think it should be you specify the start time of the round, and the sessions should have time offsets from that start time. In that case, the offsets could be inlcuded in the default event format.
But right now I am battling my things to try to get to a release, so I can't take on this extra confusion in the web languages that I'm not really good at. I can do these things but, as you know, it's slow progress working in someone else's system, in strange languages.
What are the files named in the data\layout folder?
You can only load them from the appropriate track configuration.
E.g. BL3 or BL3X count as a different configuration.
You can only load them from the appropriate track configuration.
E.g. BL3 or BL3X count as a different configuration.
Hi,
I could have a look at this.
I removed it when I recently added the ability to show races in minutes (not only laps and hours). The event template system didn't support that as it uses a different type of storage.
I should probably add it back, as I see that the feature is used.
I could have a look at this.
I removed it when I recently added the ability to show races in minutes (not only laps and hours). The event template system didn't support that as it uses a different type of storage.
I should probably add it back, as I see that the feature is used.
Small changes yesterday:
1) Race duration can be specified in minutes (not only hours or laps)
2) Cars can be 'unspecified' (league admin is not forced to select a car)
1) Race duration can be specified in minutes (not only hours or laps)
2) Cars can be 'unspecified' (league admin is not forced to select a car)
Think this topic has gone on long enough. If Daniel wants to update LFS Lazy he can start a new thread.
Restate previous post with actual truth, because half truths, exaggerations and distortions are unhelpful and spread bad feeling, which is the intent of certain post authors.
An unauthorised version, hacked to work with layer versions of LFS, without permission of the author, was released to this forum without permission and the post was removed. We don't host links to pirate software.
I have tried to contact the developer of LFS Lazy on multiple occasions but have not been successful.
An unauthorised version, hacked to work with layer versions of LFS, without permission of the author, was released to this forum without permission and the post was removed. We don't host links to pirate software.
I have tried to contact the developer of LFS Lazy on multiple occasions but have not been successful.
Fix for Vive Pro 2
I wonder if anyone uses a Vive Pro 2?
vRenegade reported an issue here that caused the image to be skewed when your head is tilted.
I hope that is now fixed in test patch F6, which you can try here: https://www.lfs.net/forum/thread/110607
vRenegade reported an issue here that caused the image to be skewed when your head is tilted.
I hope that is now fixed in test patch F6, which you can try here: https://www.lfs.net/forum/thread/110607
Thanks for your patience!
I have finally done something about this, as I have been in the development version dealing with VR and projection matrices recently.
The new option is available for testing in the test patch forum, which I have left hidden for now to try and avoid distraction from people making random off-topic requests.
https://www.lfs.net/forum/thread/110607
I will be happy to know if the VR support is fixed when you are able to test it.
I have finally done something about this, as I have been in the development version dealing with VR and projection matrices recently.
The new option is available for testing in the test patch forum, which I have left hidden for now to try and avoid distraction from people making random off-topic requests.
https://www.lfs.net/forum/thread/110607
I will be happy to know if the VR support is fixed when you are able to test it.
Last edited by Scawen, .
Reason : typos
FGED GREDG RDFGDR GSFDG