Here is a screenshot of a test for Oculus Rift support. It is at actual Rift resolution. I set it to 90 degrees horizontal FOV (total) - not sure if it should be more. This is not optimised or finished and the distortion is probably wrong or at least a bit off. Just thought you might like to see the progress.

There are now 3 display types that can be selected in LFS :

1) TV / monitor / projector
2) conventional 3D headset
3) headset with distorting lenses

And each comes with suitable sliders. For example (1) and (3) need a screen width slider. I have no plans to integrate with the Oculus SDK at the moment, so you will not get head tracking support from LFS. I'm not coding specifically for the Rift this time round. It's not worth my time while the resolution is still sub-standard and the head tracking is not complete. But there seem to be other ways to get the head tracking input, so that shouldn't be too much of a problem for Dev Kit users.

Nice! There's apparently an HD dev kit coming (early next year?) even though that wasn't the plan couple months ago, so might want to keep an eye out for that.

Quote from Scawen :

Here is a screenshot of a test for Oculus Rift support. It is at actual Rift resolution. I set it to 90 degrees horizontal FOV (total) - not sure if it should be more. This is not optimised or finished and the distortion is probably wrong or at least a bit off. Just thought you might like to see the progress.

There are now 3 display types that can be selected in LFS :

1) TV / monitor / projector
2) conventional 3D headset
3) headset with distorting lenses

And each comes with suitable sliders. For example (1) and (3) need a screen width slider. I have no plans to integrate with the Oculus SDK at the moment, so you will not get head tracking support from LFS. I'm not coding specifically for the Rift this time round. It's not worth my time while the resolution is still sub-standard and the head tracking is not complete. But there seem to be other ways to get the head tracking input, so that shouldn't be too much of a problem for Dev Kit users.

Thanks a lot for the update... I have a dev kit and will definitely be testing the Rift support out as soon as it's available!

Another Rift test shot, at the point I got to on Friday. This time with the proper distortion formula.

This is with the default IPD of 64mm. I set 90 degrees FOV because I don't yet know what it should be.

Nice work. Just a question though, once you'll update LFS to DX9, will you also switch to the official Rift SDK with native tracking/IPD adjustment and rest of the bells and whistles or stick with your own solution?

It's not useless to me. I have a rift and will deffo buy the consumer version too so this is great timing. Also, Scawen can do whatever he wants in whatever order he wants. I'm guessing it's a nice break from tyre physics and is a reasonably short development time for implementing 3d & rift support. Yes, we all want new physics and new content but any work on lfs is good news in my eyes.

Quote from Matrixi :

Nice work. Just a question though, once you'll update LFS to DX9, will you also switch to the official Rift SDK with native tracking/IPD adjustment and rest of the bells and whistles or stick with your own solution?

Good question. I thought maybe I could simply connect with the Oculus SDK to get those setup values out of it and also the tracking.

I tried this today but it simply cannot be compiled with the compiler that LFS is using - the venerable VC6. It seems that it can't compile in VC6 due to the heavy use of templates that throw up errors when I try to compile, and also the use of various library functions that don't exist in VC6.

It's the first time I have encountered any kind of problem with VC6. I suppose that the upgrade to DX9 and the use of a modern compiler will need to happen at the same time, then I'll be able to connect with the Oculus SDK.

I'm disappointed that I can't find any simple version of the Oculus SDK. I really just need to know a few values about the device's screen and the user's IPD. Also the current yaw, pitch and roll of the user's head. But they have only provided this massive bloatware SDK full of things I don't need.

Sounds like a typical "do all the things" SDK that is also designed to lock you in :-(

Quote from Scawen :

I'm disappointed that I can't find any simple version of the Oculus SDK. I really just need to know a few values about the device's screen and the user's IPD. Also the current yaw, pitch and roll of the user's head. But they have only provided this massive bloatware SDK full of things I don't need.

Ah, that's a real pity. I do hope you'll go with the SDK/DX9 route at some point though, as it does also use other variables with the profiler to calculate the correct viewpoint, such as your real life height and the gender (whatever effect that has).

Edit: Attached screenshot of the profiler I meant.

Quote from Scawen :

It's the first time I have encountered any kind of problem with VC6. I suppose that the upgrade to DX9 and the use of a modern compiler will need to happen at the same time, then I'll be able to connect with the Oculus SDK.

Is DX9 where you are intending on landing just to support Oculus? Are you considering going to DX11 in order to get the performance gains from it? Perhaps a OpenGL version, so it's easier to make it cross platform at a later date, as some of us are staring at SteamOS and it should increase the lifespan of LFS by going to a platform agnostic graphic API ...

Questions, questions ...

No, DX9 is in my head because Alex Evans told me some time ago it's a really good level, it's a good interface and what DirectX always should have been.

As far as I understand (and I'm probably wrong, because I haven't checked) DX10 and later don't work on XP. If that is true then it would be a terrible idea to go further than DX9 because XP is still the best OS. For example, I recently installed Windows 7 and now I can't go full screen on a dual monitor setup.

As I'm just a chap who likes programming and am not really interested in what all the different versions of DirectX and latest video cards can do, I assume that DX9 has plenty of good features we could make use of, and I have no idea why we would want to go to a higher version.

Is it really worth continuing to support XP, as it goes totally end of life in 6 months time.

Quote from Bean0 :

Is it really worth continuing to support XP, as it goes totally end of life in 6 months time.

Yes it is still worth it! Probably 25% of users are on XP

Quote from Scawen :

As far as I understand (and I'm probably wrong, because I haven't checked) DX10 and later don't work on XP. If that is true

Yes, it is true. DX10/11 are supported on Vista and higher. So for now, as the game handles very good on slower computers with XP, i'd think the same. DX9 is the thing for LFS.

Quote from Bean0 :

Is it really worth continuing to support XP, as it goes totally end of life in 6 months time.

of course it isnt
anybody who still uses xp after the support ends must really not care about their data

Quote from fwj515 :

Yes it is still worth it! Probably 25% of users are on XP

The latest Steam survey says 7%.

Globally it is probably more, but the majority will be business users who are still using it for application compatibility reasons.

Quote :

I tried this today but it simply cannot be compiled with the compiler that LFS is using - the venerable VC6.

Quote :

For example, I recently installed Windows 7 and now I can't go full screen on a dual monitor setup.

I suppose that you resent trying out VC12.0 and/or Windows 8.1? Not implying you should (if you haven't already) but it would be interesting to hear your opinion about Microsofts latest software releases in retrospect.

Quote from Bean0 :

The latest Steam survey says 7%.

Globally it is probably more, but the majority will be business users who are still using it for application compatibility reasons.

supporting old hardware is one of the key features of LFS, so keep that.

Am I guessing right that supporting 3D technology is is also part of the strategy to make LFS a great sim for exhibition and full-motion-sim use? Saw LFS running on some sort of sim rig on probably half the fairs I went to in the last years.

Quote from Scawen :

As I'm just a chap who likes programming and am not really interested in what all the different versions of DirectX and latest video cards can do, I assume that DX9 has plenty of good features we could make use of, and I have no idea why we would want to go to a higher version.

Thank you for the honest answer.

I think about everyone would settle for DX9, but why keep using VC6 instead of at least VC10... With Daffodil plugin if really needed.

The answer to that is here :
https://developer.oculusvr.com ... p;t=95&p=65636#p65636

I'm not ready to produce an incompatible version yet. And for all I know, later compilers may cause other unforeseen problems. It's not a good thought also while I'm maintaining two branches of LFS and have to merge all changes into both versions. Much better to get the new tyre physics out and *then* look at modernising.

Quote from Scawen :

Much better to get the new tyre physics out and *then* look at modernising.

This is the right Way!

Quote from sicotange :

I suppose that you resent trying out VC12.0 and/or Windows 8.1? Not implying you should (if you haven't already) but it would be interesting to hear your opinion about Microsofts latest software releases in retrospect.

I work on Windows 8.1 at work with 3 screens. Well I used to have 3 screens but since Windows 8.1 I am down to 2 because the drivers for the third screen haven't been updated yet - and it's driving me crazy! On top of the lost screen the fact remains that the Metro interface whilst is lovely on my touch screen is a multi-screen disaster in so many ways. Add that to pop up side panels that trap the mouse on the screen on top of the plethora of little things wrong with it and Windows 8.1 is a productivity disaster. I am still tweaking settings (it seems it is possible to get rid of the side of screen popups that trap the mouse) and stuff but overall I would say stay off Windows 8 for productivity work, it still isn't right.

Quote from Scawen :

The answer to that is here :
https://developer.oculusvr.com ... p;t=95&p=65636#p65636

I'm not ready to produce an incompatible version yet. And for all I know, later compilers may cause other unforeseen problems. It's not a good thought also while I'm maintaining two branches of LFS and have to merge all changes into both versions. Much better to get the new tyre physics out and *then* look at modernising.

Not sure why you are neading to compile the Rift code, surely using a .dll as densohax suggested is the right approach anyway - to isolate the third party stuff?

I've not read up on the Occulus Rift at all or what the API does but mixing languages or even 3D engines isn't terribly difficult within the same project. Even I can do that stuff and I am a coding novice compared to you so I imagine the reticence is more about getting it to work on your dev machine without messing up your dev machine right?

If so, then what about using a vmware install for VC12 - make a .dll for the Rift calls you need, then back to VC6 goodness for physics awesomeness?

Thanks... I am prepared to believe that would work. Though I actually don't know how to do that, I guess I could figure it out. Perhaps the Rift developers could supply a DLL instead, like the TrackIR developers do. Anyway, I hope they might consider doing something sensible. I am most unimpressed by the massive SDK which looks more like some kind of basis for an Object Oriented Programming project, with added confusion of templates in header files to look clever and confuse the hell out of 80's programmers like me, rather than a small thing to add on to your existing project. Maybe they should really consider that.

Would it be feasible to set up some unit testing on the physics code to ensure that there won't be any differences between compilers? I guess any problem is most likely going to be with the corner cases, though, which might make that a bit tricky to set up.