Is that... putting the shaders in a text file that LFS loads, so you can make changes to it?
As you know I'm not experienced with this stuff. Actually at this point I have just used the old assembly shaders written by Alex, with some slight changes in the declarations to make them work in DX9. And just left the text strings for them in LFS.exe rather than using a text file.
So they are basically ready to translate into HLSL. What are the possibilities available to users just changing the shaders a bit, while the rest of the code stays the same? I am guessing that there isn't much you could do at this point, while they are just vertex shaders, but it could become more fun if there were pixel shaders?
It will great step forward with pixel shading.
I know you used some nasty tricks for dx8 like reflections on the buildings which made with double face meshes, where bottom layer is reflection and top layer is wall with transparent textures on windows. All of this will be in the past with simple color blending in pixel shader.
And this akward per-vertex lighting on the track can be changed to nice looking lightmaps.
This is just small examples with basic things, which can be much more. (came here after 6 years read-only to say this)
yah, okay. But you need to set your focus on S3 and the other planned stuff
We can collect ideas for the possibility of implementing a method for public Cars and Tracks. A Voting System is a start. But in the end it should be a decision on your side. Flushing LFS with public conent isn't a good idea at all
There are several types of shader, the most commonly used are vertex and pixel shaders and you can do a lot just with those - especially in a game like LFS where you do not have animation transforms. I'm not sure in DX9 whether you even have hull and domain shaders, I think the pipe is a bit simpler than DX10 in that regard, anyway...
Most vertex shaders serve as little more than allowing the programmer to pass information to the pixel shader, such as Out.texCoord2 might be used to hold the data for the lighting normal, or some other data that the fragment (pixel) shader uses. You can send across some basic information from the vertex shader to the pixel shader and most commonly you use the 8 available texture channels to pack in all sorts of data which is not normally available such as the normal, binormal or tangent etc.
But my favourite thing (from a programming perspective) is a vertex shader which modifies the position of a vertex which is manipulated entirely within the shader, by itself this is not terribly useful until you mix it with data - like adding wind sheer to your foliage :P
The shader's main loop per se is the technique, and although loop iterators are not in themselves supported (I got around that by writing a pre-processor) I used a loop here to render each pixel multiple times in my fur shader on this model ( http://beckyrose.com/media/images/katzen.jpg ) - a technique known as a shell shader. The vertex shader transformed the position based upon the iteration counter and allowed each pixel to be rendered multiple times at different extrusions along the vertice normal and modified by a gravity factor - which creates each hair.
Now whilst this in itself is no use to LFS unless the new Westhill is going to be set in bear country, the principle could be used to replace the CPU driven animation wind effects.
The fragment shader itself ( pixel shader ) is where the real magic happens - and is where specular glints and the like are added to the final output colour. You return one of two things in the fragment shader - the first is discard; which allows you to discard a pixel - so your fences and tyre smoke might not be obscured by the windscreen, and you can return the final pixel colour.
Fundamentally there isn't much in the way of custom affects which can be added without being able to get custom data in from the application to the shader - so some forethought would be needed if you INTENDED for this to be modded, but it's probably better you just focused on getting the game working how you want it and let idiots like me focus on undoing all your work :P
I imagine the current track surface gets darker on the racing line because of either a second texture layer or an alternative mesh layered over the top. In either case, this is where fragment shaders come in to their own with techniques like splat shading, or a variation thereof, where a global texture map can plot in lo detail which texture map is used in high detail in any given area. I recently wrote a splat shader that allowed for 48 different textures to be used on a single surface, simply by being smart about how I managed each texture channel and what I used it for - and I am tempted to rewrite that to INCLUDE a shell shader for my grass, thus reducing my onscreen polycount by about one quarter...
LFS could certainly also make use of instancing, but I don't suppose you need me to introduce the benefits of that concept to you.
Anyway, yes, the raw HLSL as a text file - perhaps by entity/surface type ( eg: car.fx, tracksurface.fx, trackgrass.fx etc), would allow for some magic to happen.
EDIT: Ideally, typically, technique, vertex and fragment shaders are used in combination to achieve a single effect. eg: You can't do bump mapping with the fragment shader alone, it requires fragment and vertex shader... So ideally the .fx would contain all the elements within the shader.
EDIT2: Attached one of my simpler shaders to show a normal map being applied.
This has always happened after anything to do with the control input has changed - the update probably triggered it, but it always happens to me after I run LFS without my wheel in or a different controller.
As Daniel already said, go to axis options, hit recalibrate, move all axis to the full extents then hit lock. This will save the calibration until whatever caused it happens again (which will be very rare if you always have the wheel plugged in before starting LFS).
No, but you can have an old version installed if you want to see it.
I don't think that should be a problem.
Did you try installing the End-User Runtime? I don't know if it is suitable for Windows 8 but it is from Microsoft so I don't think it will do any harm to try.
Link to DirectX End-User Runtime: http://www.lfs.net/dx9/
Maybe it would be nice to have the new Westhill as extra environment and keep the old one and call it "Westhill 90ies"? And maybe could the old "Blackwood 90ies" from S1 times also added as extra environment? I know,that technically they aren't made in 90ies,just fantasising here...
Not sure if that would be good for the "promotion" of LFS tracks, to keep the older, slightly lower quality tracks there... But I see your point, it would be good for those who would like to race on the old tracks. We can always race in the old version, although there won't be much servers to race on anymore.
Great news here! I want to second all the applause to Scawen and Eric. It's nice to see that they worry about details like modeling and connecting the accomodation ways, I can see a lot of layout builders will have fun with that.
It's just a shame that Tweak or NTO are not compatible with this update.
While new Westhill looks great, I can't help to notice that there is one thing which looks rather awful. It's the shadows. I mean, look at this: http://i.imgur.com/65GaXQx.jpg
With red I've marked the shadows which look either weird or out of place. Yeah, that's like 80% of all shadows in the picture.
So yeah, are there any plans to improve track shadows? I wouldn't prioritize this over finishing the tyre physics - but then again - I have no idea how much time would it take to implement better shading system for the tracks.