How long would it take for LFS to switch to DX9?

ide say quite a while if ever because from what has been said before it would need alot of changes to the base programming.

Isn't DX9 basically DX8 + more/improved features? I have no experience in 3D programming, but I doubt the "switch" would take long at all. Implementing features that use the capabilities of DX9 would take a good amount of time, if that's what you're asking. However, we aren't even nearly using all DX8 features either, so...

graphics are not important
it lasts when i can see where the track and where the wall is

No idea - but it's not making LFS DX9 that's the issue (DX9 is just an API), it's making LFS USE the extra feautres to make it look better that's the problem.

The important differences between Dx8 and 9 are the pixel and vertex shader formats (and some stuff with color formats). Dx9 makes it easier to implement more complex effects, so the answer is that how long it takes depends on what they would choose to add. If they wanted to add a full HDR rendering pipeline (which would sure be nice), or dynamic time of day/weather effects, it would probably take a while.

But, there are few effects you can do in Dx9 that you can't do in 8, just with poorer performance. Consider that in general LFS looks about as good as rFactor (though newer rFactor mods have much more detailed models), with almost the same types of effects, and runs faster despite using an older version of DirectX.

It should also be noted that a lot of very nice effects can be added with nearly zero changes to the code. Normal and parallax mapping would basically only require new art, and would make shading and reflections look a lot smoother (check out netKar to see what I mean). Dynamic self shadowing could be added trivially (you actually have to add code to _prevent_ self shadowing), though may need better blurring to look nice. These things can be done easily in Dx8 as well.

Screw DX9 we need DX10

Btw, that bloom filter plugin is not HDR, and its horribly inefficient. All it does is filter the image after it has been rendered, like what you might do in photoshop. They could add something like that to the ingame shaders pretty easily and have it run much much much much faster. That said, bloom filters suck without HDR lighting data and tone mapping.

Quote from Luke.S :

Screw DX9 we need DX10

I'm sure the entire LFS userbase would love to be confined to Vista and DX10 cards only...

That all over post-processed bloom isn't ideal in the least as a solution to more realistic graphics. Some things do look nice with bloom, ie- the sun... that's where the bloom effect is ideal. Other things look really bizarre and unnatural.

As Almadiel points out, you could maybe use normal mapping to bump up some of the detail on the cars without needing to resort to higher poly models. I'm hoping the new interiors come with normal/spec maps as well- that's fairly standard these days.

LFS will look a lot better with better modelling and more attention to detail. these things add up. proper shadow for a start.

direct X effects....maybe some bump mapping and better defined material qualities, don't think we ever need to go to bloom HDR watereffects and all that.

Quote from Luke.S :

Screw DX9 we need DX10

Skipping DX9 would be a good idea if DX10 wasn't only available on Vista.

Quote from Almadiel :

But, there are few effects you can do in Dx9 that you can't do in 8, just with poorer performance.

While true in some cases, once you start doing normal and parallax mapping like you alluded to (perhaps even with some shadow mapping on top) you quickly run headlong into the instruction limits in DX8 shader programs. You could always multipass of course, but I dont' think that's realistic considering the CPU hit LFS already takes from rendering (though that too of course could stand to be improved).

I agree that LFS wouldn't need DX9 to get a marked improvement in graphics quality though. There's a lot of room for improvement within the existing system.

See they need to figure out how to get the strain off the CPU and get it evened out between the CPU and the graphics card so they both can do the work.

Well, some of that work happened in Y22.

LFS basically draws a lot of geometry vertex for vertex and (I assume) takes little care to group objects with similar state (shaders if any, textures, blending etc.) together before drawing. On older CPUs and GPUs that made sense since the GPUs got fed anyway and the CPU overhead of batching like that was too high, but these days the GPUs are orders of magnitude faster while CPUs mostly aren't. The CPUs can't keep the GPUs fed this way any more. The result is a maxed out CPU and a GPU mostly idling.

Changing this is no small feat though since it requires rather drastic changes to the design of the renderer. Switching to using vertex buffers instead of drawing vertex for vertex is simple(ish), and helps free up some CPU load (this happened at least partly in Y22). But the big gains are found in state grouping. Instead of for example drawing cars and their component pieces one after the other, LFS should instead draw (for example) all car bodies, then all wind screens, then all wheels, then all tires etc. This minimises the changes in state the GPU has to do, enabling it to scream through geometry at full tilt.

This can all be done within the D3D8 API though, and could potentially free up a lot of both CPU and GPU horsepower which could then be used on fancy shaders and other goodies.

For the CPU problem I think that a really good optimisation would be to make LFS able to use 2-4 cores
Don't know how hard it is but it would go really faster

Heh, if only things were that simple. Your plan lacks detail on the "make LFS able to use 2-4 cores" step. Doing that just isn't trivial. Especially when the main CPU bottleneck is talking to the graphics API (which can't really be parallelised).

Its not a ticky box situation where they can click "Enable DX9" and POW it looks better. I suspect they'd have to recode pretty much all of the graphics engines and some of the physics engines too.

The game already looks good how it is, lets just concentrate on getting rid of bugs first.

@Sir_Moi_407 - That is the same as I described for DX9. They'd have to recode the whole physics engine to optimize it for multiple cores.

I'm all for upgrading to DX9 it sounds awesome. Another thing to throw out there, slightly off topic,support for Physics cards. Fully deformable parts, frames etc. It would be nice even though I'm just dreaming. Perhaps this will come after a more complex collision and damage system.

My last status is that Scawen plan to switch to dx9 (or then dx10 who knows) in development progress of s3 because of big graphic changes for rain and those effects.
I am to lazy to search for the post he made

Quote from imadude10 :

I'm all for upgrading to DX9 it sounds awesome. Another thing to throw out there, slightly off topic,support for Physics cards. Fully deformable parts, frames etc. It would be nice even though I'm just dreaming. Perhaps this will come after a more complex collision and damage system.

Unlikely. Physics cards demand that you use their libraries, which LFS is not using. Porting across to these libraries seems exceptionally unlikely.

Remember that Doom 3 was a Directx 8 game. Sure it had a Dx9 mode, but the only visual difference as far as I recall was a glass/heat distortion effect.

Doom 3 used OpenGL with a few different rendering paths depending on what hardware it was running on. It ran on "D3D8 class hardware", but it wasn't D3D.

You are right. But the shader instruction limits were the same either way. To be more specific, the Doom 3 engine was built around the Geforce 3 line of graphics cards as a target. And as you say they added additonal optimization paths up to the Geforce 5 with its special shadow volume culling functions. But with some small exceptions, the effects and lighting model were identical for all code paths.

FTR Scawen said Multi-threading would take about a month to do.