The online racing simulator
TEST PATCH 0.6E4 (3D support - no change to physics)
(179 posts, closed, started )
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.
Quote from Scawen :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.

From your description I think you are better off not compiling the SDK in to your application anyway, I think when people over abstract their code too much it ends up bloated and often the team behind it are no longer capable of understanding what they system does anymore.

I have not looked at the Rift SDK - their site appeared to need a login and the effort involved in that exceeded my willingness to look but by what you say it sounds like they are using an MVC architecture - which is actually quite a nice way to work for modular and re-usable systems, but not very LFS'y.

It sounds like they envision the Occulus SDK will somehow form the foundation of a gaming project. If they believe that then they have lost sight of what their project is (cheesy pun intended) and/or have never actually written a game themselves.

This doesn't help however, but I think Ben might. Compiling a .dll with a few exposed functions is easy for any of us but I think he's a Visual Studio user with lots of experience in related areas and I'm pretty sure he's down with MVC architecture too, so he can probably knock you up what you need pretty easily. Visual Studio and me don't see eye to eye (cheesy pun intended) so I would probably struggle myself.

EDIT: Regarding your earlier question about differences between DX9 and DX11. The only real substantive feature difference that I can see in DX11 is Tessellation, it's a bells and whistles thing you can throw on top if present and the rest is just DX9. I'm using a DX11 engine myself but it drops to DX9 seamlessly, although I haven't actually played with the tessellation yet (I mostly code DX stuff on a Win7 machine). There's also some shader enhancements, the ability to run shaders on streaming video and something to do with shadows that I don't understand. It should be okay to migrate LFS to DX11 and use tessellation, but still run as DX9 on older OS' without it. Just be careful to test under DX9 when you start writing shaders.

EDIT 2: Oh here's a reason for DX11 in LFS. Rendering wheels with PN-Triangles would eliminate the polygonal artifact and give us properly round wheels so they no longer look like Captain Caveman drew them but under DX9 they would look as they do now, as tessellation is simply off.
Quote from Scawen :I set 90 degrees FOV because I don't yet know what it should be.

Hi,
the Rift should have a FOV of around 110 degrees. The Tuscany demo which is part of the SDK renders per default at some 111,xx degrees if i remember correctly. It did some test with my living room, which i modeled and imported to unity. Between 110-116 degrees the size of the room feels right with the real one. (Lifted the Rift up-down-up-down from the nose to see alternately real and virtual room)
Quote from Becky Rose :and/or have never actually written a game themselves.

you are aware that carmack is working for the rift these days?
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 then it would be a terrible idea to go further than DX9 because XP is still the best OS.

The problem with XP is that the support ends in april 2014, so no security fixes are made anymore. It is not a wise idea to use XP on a PC with internet connection after that date.
Mozilla (Firefox) and Google (Chrome) will also stop making updates for XP.

I think W7 strikes a great balance, whereas W8 is a terrible confusing mess. The fact that 8.1 literally broke mouse inputs for many games says how much MS cares for gamers with their touch designed OS.
Quote from Shotglass :you are aware that carmack is working for the rift these days?

He is now, yes, but not when they first came out. Carmack only joined in like 2 months ago.
The whole WinXP discussion is not really relevant at this point, neither DX9/11. It comes down (again) to;

Quote from Scawen :get the new tyre physics out and *then* look at modernising.

Quote from Scawen :urgency of finishing the tyre physics. So I plan to get down to it, make the appropriate approximations and sort out a good physically based system, with enough assumptions to make it workable, accepting that total realism is an unachievable goal.

( )
--
This Rift thing is waiting on input to bypass the whole DX9 problem but I guess the answer to that takes another X months.. Not a lot of activity on the official support forum.
Report Samsung LED TV 46D7090
I have tested this Patch on my Samsung TV UE46D7090 3D aktiv

My System was
-Windows 7 HP 64Bit
-AMD Athlon II X4 630 @Asrock @16Gb @120GBSSD
-AMD HD 5830 1GB DDR5
3D Future ist Geat.
SBS, Full.

I have adjust 3D
Focus in the "Mirrors".

Well done. "Catch me if you can!"


THX SCAWEN
I suggest you keep XP support and upgrade just to DX9 initially. While XP will not be officially supprted soon I bet a lot of LFS users will still keep it for a while.

Also the upgrade to DX9 may be less of a hassle than the upgrade to 10 or 11. Furthermore the visual improvement of going from DX8 to DX9, especially once you use shaders is very big already.
Quote from SpooSH :I suggest you keep XP support and upgrade just to DX9 initially. While XP will not be officially supprted soon I bet a lot of LFS users will still keep it for a while.

Also the upgrade to DX9 may be less of a hassle than the upgrade to 10 or 11. Furthermore the visual improvement of going from DX8 to DX9, especially once you use shaders is very big already.

Given that the one key difference between 9 and 11 is one LFS can benefit from, and that 11 can fall back to run on 9, there is no reason not to go to 11.
-
(Bmxtwins) DELETED by Flame CZE : no off-topic feature requests, please
I may be wrong but I thought that DX11 can fall back to run in DX9 mode but an application compiled with DX11 won't run with a DX9 installation such as can be found on win XP.
Not exactly, if your art assets are designed around using DX11 features then sure, but LFS has its own LOD engine so it could use tesselation if available to add detail beyond the vertices quality on things close to the camera - specifically wheels and crash helmets could use it - whilst maintaining the current behaviour under DX9.

It's not so much a case of DX incompatibility as it is a case of a games own internal architecture and media asset design.
I was thinking more about the programming side specifically having the right libraries available to link to. I assume an application compiled with DX11 headers would need DX11 DLLs to even start and since there is no DX11 on win XP you'd need a specific build for that.
In the mean time nobody noticed there actually is a reply like this;

Quote :I'm working on a build of the community SDK that will include a C API for accessing the Rift.

No me neither but now I do

https://github.com/jherico/OculusSDK
AFAIK (from random Internet research - I could be wrong) you can target/fall back to a reduced D3D9 feature set in D3D11 for hardware compatibility (albeit limited - shader model 2? probably targeting the original D3D9 rather than 9c which had newer shaders).

However, I believe that's still actually running DX11 software and you'll have the OS/driver requirements/restrictions associated with it - ie still no XP.


AFAIK to run on XP, the program itself needs to link to D3D9 instead (D3D11 can't fall back to anything if D3D11 can't even run) and only link to D3D11 if it's present for the shiny new features.

From what I've read, you only need link (at runtime) to whichever version; there's no need to have two separate compiles.


As Becky Rose said, if you design for D3D9 by default and only in D3D11 for specific features to give an (optional) extra level of pretty, it should be much more straightforward to maintain compatibility.
The thing is even if you do full dynamic linking, and select DX9 or DX11 depending on availability you'll still have extra programming overhead because the API itself has changed and as far as I know some DX9 functions have been replaced in DX11 so for part of it at least you'd need to take into account both, depending on which you run on. Also you'll probably need an extra set of shaders.

Disclaimer: I'm not saying it's necessarily technically impossible to support both but given the 1-man programming team I was suggesting it was perhaps a good idea to limit scope, at least initially, and make sure you retain as much of the player base as possible. It is my impression that adding both DX11 and DX9 support is a bigger time drain and it may be worth considering a quicker DX9 upgrade which already has many benefits over the current DX8 engine.

Obviously in the end only Scawen knows the code base well enough to asses what the rewards/time ratio is for each option and what his short and long term strategy is.

Also this is a test patch thread so I'd rather not derail it too much.
Yeah, I wasn't suggesting Scawen rushed into DX11, I was just making some (hopefully useful) points if he, or anyone else, decides to do it at some point.

As far as LFS goes - it's amazing what DX9 shaders can do...
Oculus Rift Tracking Test (not in LFS yet)
Hi, please could anyone with an Oculus Rift have a go with this little program and see what happens? The attached zip contains a small console EXE and a DLL. As originally suggested by Becky and subsequently suggested by tech support at Oculus, I have built a DLL in VS2010 to access the Rift basic info and tracking.

The idea is that this DLL can be supplied with LFS and loaded if you select Rift mode, with no need to use a new compiler for LFS.

Just put the DLL and the EXE in the same folder somewhere, and run the EXE. It will try to load the DLL and then get access to your Rift. It should show information about the Rift and try to start tracking, displaying the output once per second. You can then move your Rift around and see if the orientations change correctly. Press ESC or ENTER to exit. I'd be interested to see a screenshot of the initialisation process if possible, or any description you can give.

Thanks!

[ EDIT : Removed the attachment which had a debug thing in it that obscured the orientation results.
Corrected version here : https://www.lfsforum.net/showt ... php?p=1827575#post1827575 ]
I recently abandoned Windows XP and running now Windows 7 on all my PCs. Still XP is great OS and used by quite a lot of people (about 30% think), so leaving out compatibility for such OS wouldn't be good in any way. Altough I see that some programs have ability to run on multiple versions od DirectX (DX8, DX9, DX10 modes), but from my point of view it looks like troublemaker. DX9 is the way to go.

Scawen I'd like to draw some of your attention to some more and more commonly reported problem with LFS here on forum. Check this thread for example, today again saw new thread about that. I tested on 4 different computers and always same thing, those textures... Basicly when you run Win XP, 13.4 AMD driver it happen. It won't be a big deal if AMD would update and fix drivers, but they stoped support for Windows XP and don't accept bug reports anymore.
Is there anything you can do from LFS's side and fix it. It looks like its not "bug" in driver, neither in LFS, but more like some incompatibility (it doesn't happen in other games).
About 30% people still run XP, and AMD's market share is about 50%, so 15% people could potentialy have that problem
http://imgur.com/dF573xl

Values don't seem to change even though I moved the rift around. I loaded up one of the tech demo's and the tracking was working fine. Tried removing any other usb controllers still no luck.

Also if you want to crowdsource your testing to rift owners, head over to www.reddit.com/r/oculus The community there is pretty good and willing to help out.
Thank you for the test. Sorry about that, my mistake leaving some debug values in there. Here is the fixed version, hope it works.
Attached files
DLLLoad.zip - 67.6 KB - 202 views
Quote from DANIEL-CRO :...It looks like its not "bug" in driver, neither in LFS, but more like some incompatibility (it doesn't happen in other games).

The first thing I thought was that it resembles what happens when you run out of memory, but I don't think is happening, because reversion to older drivers fixes the problem.

My second thought is that maybe it's a problem with AMD's support for DirectX 8.1. Do you know if anyone has tried an older game that uses DX8.1? It's really hard for me to think that it is LFS's fault because it's so long established and always developed in a debug version of DirectX - meaning LFS is doing its best to do everything in the proper way.
I run Codecreatures Benchmark, which supposed to be DX8.1 benchmark and everything was fine just like on earlier versions of drivers. Actually they updated drivers to 13.9, but bug seems to be still there. Anyone have ideas about other DX8.1 stuff I could try?
This thread is closed

TEST PATCH 0.6E4 (3D support - no change to physics)
(179 posts, closed, started )
FGED GREDG RDFGDR GSFDG