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