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.
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.
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.
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.
What isn't fair is that the "haves" are placed at a disadvantage. A sim that supposedly promotes realistic driving punishes those who use the most realistic settings. There is no way for us to get a level playing field.
Normally when I downshift, I double clutch and skip gears. As soon as I get on the brakes I shift into neutral, then as I enter the corner I shift into the lower gear, heel and toe, and slowly lift off the clutch. Do I lose time with this approach as opposed to what you guys have described?
Personally, I think the real problem is that things like mouse steering and driving aids give benefits with no balancing downside. Take auto clutch for example. I have no problem with allowing it, but it should be conservative. The way things are now, auto clutch is equivalent to near perfect clutch and accelerator technique. It should be above average at most.
And obviously, you don't have to fight a mouse the way you do a FFB wheel. Maybe they should simulate resistance in the mouse by slightly reducing sensitivity when there is a lot of steering force opposing you, that way you have to jerk the mouse quickly just as you would a wheel to steer at the same rate, reducing accuracy a little. As it is, I feel the only tangible advantage I have over mousers is spin control.
Basically, it isn't right that using better equipment and more realistic control settings places you at a competative disadvantage no matter how skilled you are (not that I am, but I still want a level playing field, and I don't want to have to use arcade like settings and pick up bad habits). Failing that, servers should be able to disallow such control settings.
I suppose the lookup table approach would work, and I see your point about the fixed data structure size. And if this information were to be reported I suppose InSim would be a more logical place to put it, since max rpm isn't something that changes continuously. I still think there should be some way to get this information directly from the sim, however. After all there will be an S3 eventually, and there could always be balance tweaks.
What I am talking about is a way to do this with zero user intervention. Where the ranges of the gauges are always and instantly identical to those in the ingame dashboard, and don't fluctuate as you drive (or, say, switch around in spectator mode) while the program tries to figure out how the car is performing. Hence the "as soon as you get in the car." I suggest you read more carefully before replying in the future if you are going to patronize me.
I think its pretty important to have max rpm, and perhaps top speed information from outgauge. The way it is now we have to either let the user imput them manually, or have the program guess. Guessing isn't reliable for a few reasons: not all styles of driving or car/track combinations have the player going to max RPM (when using a clutch pedal particularly), and going by the shift light won't work because it doesn't necessarily come on at the same RPM for every gear. It makes for a much better user experience if the gauges we program just work, showing the correct range of values as soon as you get in the car. Right now there is no way to do this.
The maths you are looking for are linear algebra, not trigonometry (well, trig is used to compose the rotation matrices, but you won't have to deal with that directly). Just make a single fixed quad (two polygon square) of unit size, and then scale, translate and rotate it into place using matrices each frame. Both directx and opengl provide hardware accelerated vertex transformation for you, and will give you more versatility than the GDI based approach above, if you are willing to learn.
In my experience programming in OpenAL is pretty easy, and it gives you surround pretty much for free (except for people with those cheap nforce motherboard surround sound chipsets). Obviously I don't know the software architecture of LFS, but the hardest part would probably be setting up the 3D positions of all the sounds, which could require remixing of the sounds themselves. I for one think that being able to hear each tire from a different speaker would be pretty useful. None of the ISI sims have surround sound (due to a poor decision made long ago to go with the miles sound api), but netkar does and of course so does gran tourismo 5 prologue, and it definitely improves the sense of immersion and presence. Saying you don't need surround sound is like saying you don't need texture maps or shadows. Yeah its technically true but not having them would hurt the experience.
But hey, I don't know what the programmer is spending his time on instead of adding surround sound. I just think there should be more discussion since I think this feature should be high on the list at the very least.
Yeah I mixed up some terms there. Obviously LFS has 3D sound otherwise the sounds wouldn't fall off as things get farther away. And yes I have an 8 speaker setup, and yes I have it working for other games.
If you are only concerned with the visual appearance, it is possible to make the steering wheel invisible in cockpit mode is it not? You would lose the LCD info, though you could get that back using virtual displays or tools like SimView on a second display.
As a semi-related question: I'm getting a G25, and if I set the locks to and ingame wheel rotation to 900 degrees, what happens if I rotate the wheel past the car's maximum wheel turn? Will the ingame wheel rotate at the same rate as the physical one until it hits the "virtual" lock and then just ignore the additional input (maybe apply force to try and push the wheel to simulate the lock)? Or would it scale the rotation so that 900 degrees on the physical wheel equals 720 on the virtual one, etc? I would really like to not have to mess around with the profiler settings every time I change cars.
Is there any way to turn on 3D sound (5.1? 7.1?) in LFS? Or is it not implemented at all? I am running Windows Vista with an ASUS Xonar sound card, which supports 3D sound using OpenAL and DirectSound3D which it emulates in Vista using special drivers.
For me LFS would be pretty much perfect if it had dynamic weather changes/time of day. Like being able to plug in a value for % chance of rain. And if I am not mistaken LFS still doesn't simulate brake temp.