FUEL: RESHADED addon

To use...

1. download file
2. unzip contents (a folder with the new shader files)
3. go to your FUEL game folder
4. go to the "shader" folder there
5. make a backup copy of your "shader" folder
6. copy the new shader files into your FUEL's "shader" folder
7. start FUEL
8. let FUEL recompile shaders (if you're using Vetron's REFUELED mod, disable the option that lets you skip shader compiling as that will prevent FUEL from recompiling the shaders)
9. Enjoy

Tweaking

The "_setup.h" file that you came along with the new shaders (and which needs to be in the FUEL shaders folder) contains options to turn features on/off or tweak their impact. That file contains instructions on how to do so. I set options to an "optimal" level (for me, anyways), which include all new features on (enhanced rain effects, darker nights, etc), as well as brighter colors. There are notes next to each option explaining what it impacts and (if it's a value) the range you can adjust it within to get certain results.

Many of the options included impact the shaders globally, and I only gave 1 option to adjust. This makes it easy for you, the end-user, to tweak without being overwhelmed by tons of micro-settings that would take forever and a day to adjust and test yourself. EG: darker nights impacts lighting colors, horizon blue'ing effect, and even the post processing dynamic luminance if you have it on. I found what needed to be impacted and formulated how it should be impacted by just letting you tweak 1 variable and it does all the rest behind-the-scenes.

Updating

I update the shaders occasionally. When I do (and feel I have a version that's suitable for human consumption, and not just a hodge-podge of broken shit), I'll post a new file here.

To update to the new file...

1. download the new shader zip file from here
2. delete (or make a backup) of the shaders in your FUEL shader folder
3. copy/paste/unzip the new shader files into your FUEL shader folder

The new shader files need to overwrite whatever files are named the same in the FUEL shader folder, so if you mass copy/paste, just say "ok" to "replace all" when prompted.

I try to date-stamp the download file, so you should be able to easily tell if there's a newer one here on ModDB or not. I also try to keep a running change log below to let folks know what's the latest and what got changed.

Uninstalling

If at any time you don't like the new shaders, you can simply delete all of them from the FUEL shaders folder, and then copy/paste the originals from your backup shaders folder. Then run FUEL, and let the shaders recompile.

If you were lazy, and didn't make a backup copy, then if you're using Steam's version of FUEL you can go into Steam and right-click on FUEL to look at properties. Then select "verify local file integrity". This will replace ALL files that have been tweaked, though (shaders, any .tsc files you may have altered driver names or whatever in, etc). It will probably also hose things up if you have Vetron's REFUELED mod installed. So, you'll basically need to reinstall his mod again to overwrite what Steam flipped back to originals.

Really, save yourself some heartache and just make a flipping backup copy of your shaders folder.

Changes ( in General )

The FUEL shaders are basically a hodge-podge mess of shader code library that Asobo created while testing FUEL. I think they were shooting for a 2009 release, then CodeMasters came along and told them to wrap it up and ship it early in 2008. So, they didn't have a chance to finish implementing some features (eg: better shadows), or clean up the shader code. This made it a hairball mess to try to sort out what code was used, not used, and what each thing did.

Optimizations, Corrections & Refactoring

• Ripped out all the unused code that PC version doesn't need (eg: code for compiling Xbox360 and PS3 versions (that said, these shaders are for PC only; don't slap them on your Xbox 360 or PS3 install and expect miracles to happen).
• Ripped out routines that seemed to have no impact on the game. (In some cases I deleted whole files that weren't being used. In other cases, I would disable an entire routine of code and just have it return a simple value, since, after testing, the routine didn't seem to be used. I disabled the code on the off-chance that the game engine was still calling it and using it for stuff, but not finishing by piping the results to the screen.)
• Removed code that was running, but not being used (eg: they'd have a variable run through a bunch of calculations... then the variable wouldn't be used for anything impacting the return value of a function. The variable was just wasting processing time.
• Asobo hand-coded a lot of stuff to make the shaders compatible to compile for CG or HLSL, that way they could single-source the shader files to compile on all three platforms (Xbox, PS & PS). To make that happen, they hand-coded out a lot of sub-routines that HLSL has intrinsic functions to handle. EG: for specular lighting, HLSL has a "reflect" function that can do the specular shine reflection easily, and a "lit" function that can do the lighting calculations easily. Put those together, and doing specular shinies in HLSL is very easy. Asobo had to hand-code out what those two functions can do by hand, though, to make it compatible with CG. Since PC version of FUEL uses DirectX 9, which is HLSL, I ripped out all of the hand-coded stuff and replaced it with intrinsic HLSL functions if possible. The baked-in intrinsic functions perform better then hand-coded replacements at the shader level.
• In replacing some code with intrinsics, I realized Asobo had incorrectly coded certain hand-coded replacements. EG: their specular reflection formula was incorrect, which caused some things, like the Spider Wraith buggy, to have massive over-shine on it that blocked out the livery. By correcting code like this, it fixed some issues in the game.
• HLSL lets you do math on multiple variables at once. eg: you can have var1.xyz * var2, and it will take each component of var1 (x, y, z) and multiply them by var2 in a more efficient manner then if you had var1.x * var2, var1,y & var2, var1.z * var2. You get the same result, but HLSL does behind-the-scenes optimizations when leveraging their component math. In some cases Asoso was not leveraging this to full effect. So, I tweaked it where I could.
• As I went along, I broke a lot of code to figure out what the heck it was doing. Then I pieced it back together again by refactoring a lot of it to make sense. This just made it easier to organize the code and see what's going on. HLSL inlines all code, so making a sub-routine that 5 things call doesn't help. During shader compile, HLSL just takes the code from the sub-routine and pastes it into those 5 spots.But, being able to see what's going on while coding makes it easier to make changes, corrections and see possibilities for improvement.

Improvements

Rain Effects .. ran makes things look wet/shiny now

• Rain makes things look wet / shiney now. Asobo had some code for this in the vehicle / object shader, but it wasn't commented out and disabled. I turned it on and tested it, then tweaked it to look good. It was a pain, because some things, like wheels, need to use certain cube-lighting then others, otherwise the shine on them spins around with the wheel (and looks dumb) instead of staying stationary like it should.
• Once I got the code for objects working, I applied it to ground to make it look wet, too. This required more tweaking.
• With ground looking wet, plants started to stick out like dry, sore thumbs. So, I wanted to apply rain wetness to them, too. However, that required shifting a lot of the plant/tree lighting from vertex shaders to pixel shaders in order to get eye vectors and normals / bump maps that were needed. This was a bitch, but I got it done. Plants on the ground seem to off-shade a bit sometimes, but overall the effects are nice.
• With rain wetness happening globally, I then worked on making things "less wet" under trees. Trees already use an ambient occlusion to darken stuff under them, so I used that to decide how wet things under a tree should be (this simulates rain being blocked by tree canopy coverage).
• Then it was time to add some shadowing to the ground even in rain, which blocks some specular.
• Then it was time to impact water... Lake / Ocean water get lighter colored to simulate foam aerating the water and algal bloom in storms. Puddles get lighter colored to simulate silt stirring up in them as they get agitated by the rain. Water apecular highlights dim down in rain storms to simulate impact of overcast weather on lighting.
• If you haven't guessed by now, this was a shit-ton of work. (esp for someone that was new to not only C-Programming styles, but HLSL programing specifically, and new to graphics programming as well.)

Speaking of Water...

• I learned how to multi-sample things by taking several samples of them, each with a slight variation in the uv, to then blend things together to create anti-aliasing, smoother textures, etc.
• I did that with the water. So, instead of just 2 samples of bump-mapping it has 6. This creates a smoother bump-mapping surface, especially when looking at the specular shine from the sun.
• I used mutli-sampling to create better shore foam, with larger patches out in the water making it easier to see where it's shallow enough to drive and smaller band near the shore to create a nice breaker.
• I got tired of lakes/oceans having "stripes" of color in them from their underlying ground colors. So, I had them use a single color source instead of mixing in ground color. The ground color still mixes in, but just barely now. This creates a more uniform ocean/lake water.
• Puddles and Rivers got tweaked to look better. Puddles look a bit siltier / muddier, and Rivers look a bit more watery instead of dark emptiness.

Better Lighting

• I organized the hodge-podge lighting model, which took a lot of work. Asobo built some ambient occlusion into certain things (like vehicles) while other thigns didn't have it. I learned that the lighting works in layers, with shadows blocking sunlight to let shadow color through, and occlusion blocking shadow to let a darker ambient occlusion lighting (shading) through.
• Then I had to realize that while every HLSL lighting tutorial I read said "dots" were used to create a luminance multiplier for light colors, Asobo's "sky dot" wasn't for making sky/shadow coloring, it was for acting like another layer of ambient occlusion. (This was an epic shit-ton of testing and trial-n-error and pulling my head out, because multiplying sky/shadows by the skydot worked for some things and made others have pitch-black shadows. I was pulling my hair out wondering wtf was going on until I realized it was an ambient occlusion-like blocking agent instead of a light color luminance factor.)
• With a more unified lighting model, I could then add in setup options to lighten/darken the shadow and ambient occlusion colors based on user preference instead of using the defaults (especially the pitch-black ambient occlusion color they defaulted with).
• Then I experimented with using sunlight color to do shadow colors, which created a much warmer scene and shadows. But, then as sunlight fades in storms, scenes became very dark. So, I had to add in a smooth transition routine that checked sunlight to sky/shadowlight, and if sunlight got too dim then to switch back over to sky/shadow light coloring smoothly instead of just a stark change. (every time I added something, there seemed to be some hack methods to work around problems involved).

Darker Nights

• With a more unified, easier to understand lighting model organized, it was on to darker nights. This took a lot of testing, because it not just had to impact the lighting model, but it had to impact the horizon blueing effect as well as post processing due to dynamic luminance. Plus, some things needed to be brightened back up (eg: lightning and sky clouds when lightning strikes) to still look natural as nights darken.
• I originally tackled darker nights this all in post-processing, then had to hack-fix each element like headlight lighting and lighting strikes separately. I then realized it was better to just tweak the entire lighting model once I had that better-unified. So, this was a long road/process to work through.
• In some cases I had to hack solutions together. EG: as nights get darker, water is harder to see. I didn't want players to drive right into oceans or lakes, so I had to find a way to light those up. I couldnt' wrap my head around Asobo's deferred headlights lighting model to apply it to other things then ground, plants and vehicles/objects. So, I had to think of another way. It dawned on me that water does a refraction of the ground under it, and that ground already has headlight lighting mixed in. So, I took the refraction and with a few calculations I was able to simulate headlights hitting the water better. It's not perfect (at night, lakes and oceans look like transparent pool water), but it's better then the empty, black masses they were which were too easy to drive right into.

Anti-Aliasing

• With figuring out how to multi-sample, I realized I could just multi-sample the final scene in post processing then blend it together to create a slight "blur" for simulated AA.
• Then I experimented with adding more and more multi-samples... a basic Bilinear 2x2 (around a central sample), trilinear (3x3 around a center sample).
• Then I came across a trilinear equation online which seemed to work nice.
• I settled on a simple over-sizing, cheap AA and the trilinear equation. Then I made it where you could combine the two.
• The end result is "good enough" without having to get into major code experiments in FXAA or the like (which may be possible to do all shader-side, but at this point I just don't want to tackle something that drastic).

Speaking of Post-Processing...

• I wasn't a fan of FUEL's default washed out colors. So, I found a way to brighten the colors. You can now enjoy greener grasses and bluer skies!
• The default Dynamic Luminance / Eye Adapt effect (screen brightening or darkening based on surrounding light/shadows) and Bloom (super-smudgey) were the bane of some players existence, so much so that we put how to disable it (by ripping out the code) in the FUEL wiki and Vetron created options in his mod to disable it. I tweaked those two features to be less pronounced and more subtle, making them look quite good now (if I don't mind saying myself)... to the point where I myself actually play the game with them on now!

Plus lots of other tweaks...

• Made asphalt road paint more weathered-looking. This was done by finding a way to capture when road decals were done on asphalt vs. dirt roads (which, as it turns out, I had to use the specular amount to determine), and then I could just tweak the alpha to make less asphalt road decal show up. A side-effect of this is that rivers that cross asphalt roads now make the asphalt roads look darker there, like they're residually wet from water crossing the road.
• Tweaked clouds in the sky to include sun & sky lighting directions, that way the side opposite the sun has more shading/depth. This transitions as the sun moves, making clouds look more cloudy and full-bodied in the sky rather then just white static textures just sitting there.
• Tornadoes and sandstorms got some tweaking and optimizations.
• Ground bump maps are very flat-looking. Added a slight amount of specular shine to ALL ground textures so a) asphalt roads have nicer, more prominent shine in the sun, and b) the specular adds depth to the bump mapping around the vehicle making it seem like the ground bump maps are working properly when they're not really.
• Added in some slight specular to plants/trees, too, so they shine along the "sunlight specular trail" towards the camera from sun along the ground. During sunrises and sunsets this creates a very nice "sunlight shine trail", especially with bloom on.
• Shifted ground's bump map matrix calculations from vertex-shader to pixel-shader. This creates better-detailed ground bump mapping.
• Made it where you can adjust headlight brightness and even turn headlight lighting color into more modern, blueish, xenon-like color.
• Added a setup file to let you, the end-user, tweak things to your liking.

Issues

• Mud flung on the screen looks like gray squares. Not sure what I borked up to make it look like that, but it's broken. I'm still scratching my head on that one. I personally play with mud & water screen effects turned off, so this isn't exactly a priority in my book. But, it is a base feature of FUEL, so I'd like to get it figured out at some point.
• Some of the tire textures on some vehicles don't line up exactly right (eg: Deathgrin) leaving lines on the tread or inner wheel well where the mesh just starkly cuts off from shaded to unshaded, or the textures + normal / bump mapping looks ugly / low-res (eg: Psychotic Fox). It's not too noticeable unless pointed out, but it's annoying. I've stared-n-compared the scat_mesh files (which handle vehicle shading) of mine with the original FUEL ones, and can't figure out what's going on. I've isolated the spot that seems to be borking up, but everything looks like it should work fine. I'm thinking there's some other files (mesh, scat_skin) that impact vehicles some how. Just can't figure it out. (It's hard to tell what vertex shaders impact what at times). I replaced FUEL's sin/cos functions with intrinisic HLSL functions, but I didn't notice any problems with it when I did. So, I'm not sure if that's the issue or not.
• If you use the night darkening multiplier to darken nights, then the vehicles and player model in the menu screens will also get darker. For some reason pausing the game into the menu sets the "it's night time" flag to true, so the lighting model uses night multiplier to darken the lighting, which the menu models use, and makes them dark. I dont' know of a way to separate the menu lighting from game lighting. There's a "pause menu" flag that captures when the game menu is up. But, I tried using that to capture pause menu up and negate the night darknening. However, it didn't work. The pause flag must be getting triggered in post-processing after the game objects lighting has processed. This is the problem with working with mystery meat variables coming from the game engine, and not being able to know or see what they do or when they trigger in the graphics pipeline, aside from lots of experimenting and pulling your hair out.
• The enhanced rain effects make the light halos around checkpoint flags look like shimmery squares. This is an issue with Asobo creating one, massive, swiss-army-knife shader file to handle almost ALL vehicles and man-made objects in the game. Youd' think the light halos would be some sfx or somethign handled in another shader, but no... it's handled in the vehicle/building/etc shader. ugh. I tried using clip functions to cut out pixels that didn't have a certain trnsparency as a way to tone it down, but can't get that to work. So, for now checkpoint flags looks stupid in rain.
• When I first started messing with the code, I somehow turned off or ripped out code to do ambient occlusion under vehicles. This was a "dark spot" under cars that is supposed to blend with the shadow under the car to help darken the area under your car in shadows. You'll notice AI vehicles have just a dark patch under them as they travel. So, I koow this code is still in the shaders some where, but I can't get it to work for player vehicle yet.

Background

Long, stupid story... this all started when I dug into the shaders to turn off features I didn't like, (eg: bloom, dynamic luminance / eye-adapt effect, etc). I later realized I could design those with a setup file to toggle on/off. Then, I started ripping out unused code, code that was processing but not impacting anything (wasting processing cycles), then focused a lot on optimizing what code / math there was, and refactoring the code to make more sense. I then stumbled across unimplemented features, or had some in mind I wanted to try to implement. So, that was more coding and testing.

FUEL runs best at 60 FPS (vsync'ed / capped). My goal was to optimize the math & code as much as possible to keep that 60 FPS maxed as much as possible for smooth game play (even on older systems). And, with optimizations giving me a budget to work with, add some other features if I could.

This took an epic amount of time and frustration to do, because I was only using FUEL's built-in shader compiler, and it doesn't provide feedback on what caused shader compilation to blow up. (ie: game says "sorry, shaders didn't compile", but there's no error output file, so I couldn't easily tell which file was the problem). So, I had to be very meticulous change small chunks of code, start the game, let shaders compile, test in-game, exit game, make more changes, wash-rinse-repeat.

It's basically a lesson in insanity if you're not a bit OCD. I'm full-time in college after being in the working world doing database and coding for a living, so I adopted FUEL's shaders as a coding project to keep my coding skills sharp. It helped me learn C-style language, which helped me ace some college classes.

But, I've just grown frustrated with the limitations of the shaders, with the constant unknowing of what the game engine is doing, with realizations that one shader file impacts a ton of stuff so you can't just change "one thing" without messing up a bunch of stuff, I can't figure out how to implement some more complex stuff without access to the game engine's mystery meat code, I don't even have access to the game engines code (which would be great to optimize as well... if you're gonna do it might as well do it all, right? Well, I can't, so it's frustrating.) I can't crack into the game's asset files to correct erroneous bump maps and textures that are causing issues I can't fix in the shader files, etc, etc, etc.

So, it's time to just put this project to bed. I'll probably work on it here and there, but this project has really consumed a large part of my life, and the stress was not helping me with school and personal relationships. So, I have to put it aside. However, I wanted to share it with the FUEL community, as they may get some benefit from it...

Change Log

2016-Jul-26:

• Added ContrastAmount, which gives you better control over the contrast / brightness in post-processing. I added this to help get back to default FUEL look.
• Added instructions in "_setup.h" file on how to get back to the default look of FUEL by tweaking variables in the setup file.
• Made all comments in the "_setup.h" file use // to comment them out. This is so folks using a plain text editor like MS Notepad won't get confused on what is and isn't comments. (I had huge chunks of comments stuck between /* */, which act as large-area commenting structures in C-style languages. But,t hat meant that some comments looked as if they weren't commented out when looking via a black-n-white text editor. I don't want folks to feel overwhelmed with "holy crap, I feel like I need to be a coding expert to understand this" paranoia when they look at the setup file, so I'm trying to make it as simple and standardized as possible to use.)

2016-Jul-21: ... I keep saying "last update", but I'm actually playing FUEL: REFUELED now using the shaders, and just tweaking things here and there in the shaders...

• Tweaked sun orb to make it fade into sunrise / sunset better. (I'm also trying to find a way to get the day-to-night and vice-versa transitions to look nicer by trying to get the sunlight to drastically reduce more as it hits sunset or sunrise so it starts off dark to match the transition then brightens more sharply. Just not having much luck with the solution I've built yet. So, that's for another time).
• Corrected a mistake I made in tweaking some vertex code by normalizing all parts of a four-part variable (xyzw) when only 3 parts (xyz) needed normalization. I don't notice any visual impact from this, but it's better to have things correct then wrong. Plus, it saves 1 normalization operation per vertex running that code (ie: the normalization routine normalizes per part of the variable, so a 4-part variable gets 4 normalizations ran, one for each part. So, I killed that extra normalization that wasn't needed, but was my mistake in tweaking.)
• Tweaked a vertex sub-routine that several vertex shaders were using. It was fine for one vertex shader file, but for the other it was running a few unnecessary calculations to return a variable that wasn't needed. So, I split the function in two, creating a slimmer version for that other shader.
• FUEL game engine pipes in flags to make the shaders compile based on what it's doing. (This was actually one of the hard things I had to figure out early on, because they have flags all over the place in some shaders, and it's hard to tell what flags are piped in for what things, like vehicles vs buildings). I force-set the bEnvMap and bBlendScreen flags off in the shaders, because they don't seem to have much (if any) visual impact. (Really, they're used for vertex-lighting, and I think they were used heavily when Asobo was first building the game out and did a lot more vertex-lighting as a means to lighten the processing load on xbox and ps. I'm trying to push more lighting to pixel-side for better lighting quality).
• Added user variable MotionBlurUpper that lets you adjust how much motion blur you want to impact the top of the screen. As you ramp up MotionBlurAmount, then it impacts the bottom of the screen a lot, but also impacts the top. This gives a real sense of speed, but it can make the top of the screen too blurry to see what's coming or anticipate obstacles/turns. Plus, if you're like me, too much blur can give you a bit of a headache. I originally hard-set a value to tone it down by "MotionBlurAmount * 0.75" (so as you ramped up the motion blur amount it would automatically tone down the upper screen blur by an equal factor. But, I wanted to let the user control how much upper screen blur they had. So, I replaced the 0.75 with a user-set value MotionBlurUpper. I feel 0.5 makes things too visible and detracts from the sense of speed, but 0.75 is a bit too much blur up there for my taste. So, I default set it to 0.65, which I find to be a happy middle ground. You can adjust it as you see fit in the _setup.h file.
• Removed variable DoMotionBlurRadially, because it was a bit dumb. It basically just bypassed the upper-screen calculation. Since I now provide a variable that lets you decide how much upper screen motion blur you want, you can recreate that by just using a MotionBlurUpper amount of 1 or higher.

2016-Jul-20: ... last update for now...

• Incorporated the Exponential and Variance Shadow code that Asobo did, but didn't get working before FUEL was shipped. I have it incorporated, but can't get it working myself when I turn the flags on to make the game use either of them. That's sort of been my "elephant in the rooom" that I've been meaning to tackle for a while. The variables for it compile, but I'm not sure what values are being sent to them. Perhaps nothing. (Just because a variable compiles in the shaders doesn't mean its value is being updated from the game engine). So, I'm just going to give up on it for now. The code is a PITA to mess with, and I can't find very good examples online to see what's broken or if I can make it work. I've messed with the code, and it all seems to be coded properly, but the shaders don't compile if I have either Exponential or Variance Shadows turned on. (Both of these would perhaps make the shadows look better in FUEL, which is why I was trying to get them to work). Asobo's code says they were having a hard time getting them to work, hence their main code was sidelined in a separate file that's not used by the game, and all instances of their code attached to files that are used is switched off via flags. So, it's a conundrum.
• Being the last update for a while, I set a flag to disable the ambient occlusion lighting that should be showing up under cars on the ground. I don't know what I borked up to make it not work, but I put all the code back in place I thought I ripped out (even having to come up with some creative work-arounds to stuff the variable back in on some object code). I don't know why it's not working, so for now it's just wasting processing cycles. So, I set a flag to disable it in the _setup.h file (#undef bOmni). What's confusing is that they call the headlights lighting "omni" and this ambient occlusion under cars "omni" as well. I think it's because they both are just omnidirecitonal lighting. The headlights are an omnidirectional light "cone" projected out in front of vehicles. The "omni" for ambient occlusion is perhaps from a light object that follows the car inline with the sun and projects an invisible "darklight" onto the vehicle. Then the code makes it where only the shadow of the vehicle processes this as ambient occlusion. (It's common in some games to use "black lights" to handle shadowing). Anyways, can't get it working, so disabling so it won't waste processing for now.
• I was experimenting with water a bit, too. I was trying to see if I could overlay a real specular on top of the one FUEL has coded and tweaked in order to get some sparkle shimmers on the crest of some waves. Couldn't figure that out. So, the code was wasting processing cycles. Ripped it out. Also, set a couple of variables in river and puddle water back to what they used to be, so hopefully they'll have a bit more "body" to their waves now.
• I start back to school soon, so I need to put this project to rest. I guess that's why I rolled in a bunch of minor changes over the past week or so. I'm not sure where else I can go with the shader code. Stuff I try to change now either breaks something, or works in mysterious ways (ie: impacting something you wouldnt' think it would impact). I can't seem to get the shadows to work better. So, it's time to set it back on the shelf for now. Not sure if (or if ever) I will work on this again.

2016-Jul-18b: ... more changes...

• Made faded dirt tire tracks on dirt roads match underlying dirt road color. (The tire track overlays are a gray'ish base color. Textures are usually stored in grayscale when their end processing will make them incorporate something elses color. I'm not sure if that was the case here, and they forgot to mix in base color, but I got tired of the same white'ish faded tire tracks on every dirt road color. Made it look like chalk dust. So, incorporated the underlying color. On rocky roads the tire tracks don't show as much now, which makes sense, since it's a rockier road. On dirt roads they show as the color of the road.)
• Fixed issue I caused letting patches of vehicle damage show through on undamaged vehicles. (I thought that some vertex shaders that didn't do damage didn't need the damage value set. Turns out they were defaulting to damaged textures. Vehicles are made up of a patch-work of textures each using different routines for bump mapping and stuff, so it's a hot mess tweaking one thing and finding out it impacts somethign you think it shouldn't.)
• Rain now dampens fires & fire smoke (distant smoke on horizon, smoke emanating from burning logs, fire on burning logs, hazy smoke in smoldering forests that shows up if you sit in them long enough, flare smoke, etc) In rain storms, burning forests now just have orangish/black trees w/o fire or smoke coming from them. It's the best I can do, because I don't know how to isolate the organge/black texture on those trees to dim the orange as if rain was dampening it. (This is the problem that arises when a ton of unrelated objects are tied to a single shader file handling them all. Without flags or such to determine what's what, I can't isolate and control things better. The fire/smoke objects are their own shader files, so it's easy to jack with them. But, not the burning tree objects.)

2016-Jul-18a: ... small changes...

• Added specular to vehicle parts / man-made objects in game that didn't have any, and punched up the specular on non-vehicle-body parts and man-made objects. This is sort of like how I did it with ground and plants; adding some specular to ones missing it to help add body and shine to the scene in sunlight. You'll notice this on exposed tires in light, how they have shine. Metal ramps now have a specular shine in the light. Some wooden buildings have a slight shine now if looked at a certain way. Some metal buildings now shine a bit instead of looking flat. I had to be careful in adding / adjusting the shine, because vehicle bodies and things with cube-lighting (mirror reflections) already have enough specular. If I impacted their speculars then they end up looking like liquid metal mirrors. (Which is bad for vehicles, since it then coveres up the livery/color). So, I tested this to make sure I was impacting only the under-stated stuff in the game, then set it to a fairly discreet amount. I may adjust this amount depending on how much I'm annoyed with shiny rubber wheels reflecting too much light or not.
• For Motion Blur, I noticed that as you ramp up the blur amount the entire screen becomes hard to see at high speeds. This is because while the blur mostly impacts the bottom of the screen, it also impacts the top to a lesser extent. As you ramp up the motion blur amount > 1, then the top of the screen becomes more noticeably blurry. While it helps to give a real sense of speed, eventually it makes it very hard to see where you're going. So, I added some code that adjusts the blur at the top of the screen by 75% of the MotionBlurAmount user sets. This helps tone down the upper-screen blur to remain a manageble amount that you can still see through, while also it not being some hard-set amount that would look ok with one motion blur amount but not others. (This is the issue with adjusting things in the code. You impact one thing, then other things are impacted. So, you have to take the variable you use for impacting that one area, and find a way to impact the other area to balance things out again in a way that gets the desired end result. It's a huge balancing act.)

2016-Jul-17:

• Modified DoMotionBlurEnhanced, so if you turn it on or off it will keep the same speed blur velocity / amplitude amount set in MotionBlurAmount setting. (Basically, when you turn it on, it just cuts the velocity in 1/2, since it's doing 2x the amount of samples.) I also adjusted the MotionBlurAmount down to x1.5, b/c x2 was way way too much when speeding in very fast vehicles.
• Fixed vehicle dirt texture...Asobo was having dirt on your vehicle block out specular shine (which makes sense). However, they were using a formula like "specular * 1 - dirtiness". Via order of operation precedence in math, this meant specular was multiplying by 1 first THEN subtracting the dirtiness. This is wrong. What they were trying to do was invert the dirtiness (1- dirtiness) to make it an inverse ratio (percentage) to then multiply specular by ... so "specular * ( 1 - dirtiness )". I fixed the formula to do that properly, so now there's no underlying vehicle specular bleeding through the dirt.
• I also Optimized the vehicle dirt routine. Asobo decided to store the "how dirty is object" value inversely. IE: the lower the dirtiness value, the more dirty the object was. This means they had to inverse it (1 - value) to make it directly related. They were doing the "1 - value" in the pixel shader for every pixel (!). But, they were setting the dirtiness value in the vertex shader to pass to pixel shader. So, I just shifted the "1 - dirtiness" calculation to the vertex shader. No sense in wasting pixel-shader time doing the same forumula thousands of times when you can just have it done in the vertex shader before piping to pixel-shader.
• Adjusted rain sheen amounts on ground, plants and tire tracks more to let more of the darkened, wet ground color show through to match vehicle shading in storms. (Look more natural)
• Fixed moon to use proper lighting color for "fantasy" and "realistic". Actually, this is something I hosed up. Asobo's original code was using an alternate light color then the normal sun/sky colors. I liked using the sun color for the sun, so I swapped that in. But, it makes the moon look too blood red at times in cloud cover. (Moon and Sun use same texture/disc, then just overlay lighting). So, I made it where during day the sun uses sun color, and at night the moon uses that alternate color like FUEL default (but only if you have "DoRealisticMoon" off... if you have it on, then it'll use the moon's natural yellow color instead of applying the "fantasy" purplish sky color.). I also added logic branching to this to make either the sun or moon process, instead of making both process and having a lerp (interpolation) act as a logic branch at the end to pick the correct one based on night time variable. Hopefully the logic branching is helping and not hurting in this case. I don't have much way of testing other then running the game and checking an FPS counter. I'm still hitting a good 60FPS vsync capped most of the time.
• Tweaked water code a bit more. I experimented more with vertex sun / sky / shadow colors again, and just can't find it working. It seems anything on the ground (tire tracks, plants, water) need to use the pixel-shader generated sun/sky/shadow light color values in order to sync up well via how I updated the lighting model. (Other things, like wheel dust and stuff, can use vertex colors ok). I'm still not happy with the water color in some cases (puddles look a tad odd in shadows, and rivers are a bit blue'er then I'd like). Might mess with it later, but moving on for now. I added a little logic branching to the water code to make it pick day vs. night color / lighting. Again, not sure if that helps or hinders..

2016-Jul-16:

• Added "MotionBlurAmount" variable to make motion blur streaks more/less pronounced. As you make them more pronounced, you realize the default 8 samples of blur start to look gapped. So...
• Added "DoMotionBlurEnhanced" on/off flag, which doubles the motion blur samples to 16. This helps smooth out the gaps. Since I just kept the amplitude of the blur the same, and simply doubled the samples, by turning this on and leaving MotionBlurAmount the same value, you'll automatically see the motion blur stretched by 2x more. To get it back to normal (ie: like you don't have it on) then you can set MotionBlurAmount to 0.5. I personally like the extra-stretched motion blurring. However, it acts like extra anti-aliasing, so it + AA on can make the scene look a bit smudgy, especially with faster vehicles that cause more motion blurring. It can also cause a bit of tunnel vision.
• Darkened ground and plants in rain storms to help match how dark vehicles and player model are. Also toned down amount of rain sheen so things look more naturally covered in water instead of cooking oil.
• Added switch to turn FUEL's post-processing blue'ing tone-map on/off (DoBluerNight). This washes out colors a bit, and does it a bit more so at night. It's supposed to simulate how at night there's less red/green (since no sunlight), and thus things get more washed out and blue'ish looking. However, it dims the headlights some and washes out colors. I prefer brighter headlights and brighter colors. But, you might not. So, added a flag to turn it on/off.
• Corrected error in the vehicle dirt map calculation that wasn't letting dirt properly block specular lighting (ie: they had "specular *= 1 - dirtiness" ... which would multiply specular by 1, then subtract dirtiness. What it needed to be was "specular *= ( 1 - dirtiness )" which made the dirtiness % invert first, then apply to specular, which would make more dirtiness inversely lower specular shine amounts on those parts of vehicles. The smallest changes can make the biggest difference sometimes.

2016-Jul-15: I noticed I was getting a big of bog-down with FPS hitting 55 sometimes. So, I made some minor changes that impact a lot of stuff. I'm now running 59-60 FPS VSync'ed / Capped again, so I think it helped...

• Tweaked the night darkening routines to use dynamic logic branching (logic statements, eg: if/else) instead of calculating all values and then deciding which to use. Dynamic branching is a delicate balancing act in HLSL shaders, because in some cases using a branch to avoid processing a bunch of code is more efficient, while in other cases it's more efficient to simply calculate both sides of a branch and use a lerp funciton to interpolate to the correct one based on a deciding factor. Unlike CPU's, GPU's are not good at logic branching, and I noticed when I added some early in working on the shaders the compile time would increase to crazy amounts. Coming from a CPU programming world, where you use logic statements all the time to keep from processing code pointlessly, it seemed odd that in some cases it was more efficient to simply do all processing then use decision variables to flip between values as needed. But, this is because GPU's are designed with lots of mini-cores that do tons of parallel processing. So, it's easier for it to calculate a bunch of values then pick one sometimes then it is for it to do logic branching and then only calculate based on the branch it takes. Anyways, the logic branching seems to work well with the night darkening routines. Tried it with rain sheen / wetness effects to see if I could avoid calculating cubemaps for that when it's not "wet enough" to really see them, and that's when the logic branching bogged down again. Apparently logic branching in GPU shaders is an art rather then a science.
• Flipped all pixel-shader float variables over to half variables. This may not make a difference for AMD card users, but for Nvidia users you may see a performance improvement. Basically half variables are 16-bit variables where-as floats are 32-bit. By using half's, you cut down on the memory needed, and thus (hopefully) the processing power needed to process them. You don't want to do this to vector calculations, because those need to be precise (so those are left as floats). But, in pixel-shader calculations you're mostly deciding colors. And, the human eye can't tell the difference between colors ran through floats or half's (the human eye can only detect so much color variation, and even 16-bit half variables have way more color fidelity then the human eye can keep up with.) Half variables were Nvidia's "performance boosting" answer to cards that came out in DirectX 9 days as a response to AMD breaking industry standard specs and making all their cards process 32-bit floats as 24-bit. Nvidia needed a way to keep up, and so they made it where their cards could process 16-bit floats... and called them "half" variables (half of 32-bit = 16-bit). It's really just hack solutions, but I noticed Asobo coded some shaders to use halfs. When I read up on them, I figured it'd be worth a shot to flip all pixel-shaders over to use half's. I noticed better performance on my GTX760, so it seems even newer Nvidia cards can benefit from this (probably because it's all being piped through DirectX 9, since it seems to be what implements half vars). As I said, I don't think AMD cards will benefit. I think they convert all half vars they see to full float vars now, or perhaps to their 24-bit float var. If AMD cards are still using 24-bit floats, then they already get a boost in vertex shaders by converting all 32-bit floats to 24-bit. But, the vertex shaders aren't really what bogs down FPS. It's all the pixel-shader calculations. So, hopefully half vars will help in some cases.

2016-Jul-14: More minor things ... I'm playing Vetron's REFULED mod using my shaders, and doing a full playthrough again (or, at least, seeing how far I can make it... I've never completeled the entire game! LOL!) I'm noticing a few annoyances here and there, and fixing/tweaking them as I can:

• Corrected clouds to flash like they should when lightning flashes in storms
• Tweaked object/vehicle parts vertex shader to skip bump map matrix processing if the object/vehicle part is not using it (should be a slight performance improvement)
• Tweaked clouds in sky to add shading to the side that's opposite the sun in order to make them have more depth/volume and blend into the sky better and not be so flat

2016-Jul-13: Very minor update

• Some shaders use a matrix to do normal / bump-mapping in order to create the 3D volume/depth necessary to make it look volumetric. (EG: tire tracks use a bump map matrix to overlay the bump map texture on, in order to make the tire tracks look like they're sinking into the ground). Asobo coded the shaders to be swiss-army knives that would use flags to determine if things used a matrix or not, and they had 1 struct that was designed to either do a matrix or a flat texture. The way this struct worked was first it was altered based on what was calling it (ie: to have a matrix or not), but it didn't have a real matrix. It just had 3 variables that had 3 elements each. Vertex shaders would create a 3x3 matrix, then send it to this struct, and a routine would basically tear the matrix apart to store it in these 3 separate variables. Then the pixel shader would call another routine to reassemble the 3x3 matrix on its end. Since tire tracks, sand storm cloud and tornadoes always use a matrix, I had them skip all this and just use 3x3 matrices right in their own main structs and bypass using that secondary struct that needed tearing apart and reassembly. It's a bit of a minor thing, but it helps clean up the code a bit and streamlines what's going on with those. Sadly, I can't do the same for vehicle / building / object textures, because the super-swiss-army-knife scat_mesh code files are designed to handle a lot of different bump mapping types, from normal texture types to matrix types to ones that need to be applied to tires and rotate with the wheel. It's a hot mess, so I have to keep that as-is for now.
• I optimized the lighting on tornadoes and sandstorms to do most of it in the vertex shader. These are things that are massive, and don't have shadowing or specular, so they don't need a lot of extensive lighting. It's mostly the sun & sky color calculations I shoved back to vertex, that way if "DoSunShadow" is on then those calculations are done in the vertex shader which is then used for the pixel shaders, instead of calculating it per-pixel in the pixel shaders.

2016-Jul-09.b: Minor corrections, but they took some time to figure out..

• Got water to color correctly, mostly by putting all water lighting in the pixel-shader instead of some of it starting off in the vertex shader (default FUEL has light colors calculated in vertex shader, then pipes them to pixel shader for shadowing and application to water bump maps and textures. I moved those light color calculations to the pixel shader, and they're using the standardized pixel-shader light model I ended up with for most other pixel-shader lighted objects like ground, vehicles, etc). This adds more gpu processnig (since lighting is now all on a per-pixel basis instead of some being per-vertex), but it should make water look better. I may play around with trying to get the light colors offloaded to vertex-shader again, but for now water (puddles, rivers) finally looks decent in shadows.
• Corrected some vehicle textures shadowing improperly when damaged (this was something I was messing with to try to force things to use better bump-mapping, and it didn't seem to pan out. Forgot to change it back last time, so did so now.)
• Replaced a few if/else branching code parts with more gpu-compiling-friend code. Not sure if this provides a performance improvement, but gpu's are not good with logic branching (if/else statements). So, getting rid of them and replacing them with gpu-friendlier code sometimes helps.

2016-Jul-09.a: Some minor tweaks (for stuff I was experimenting with but not sure if screwed up). Other stuff...

• added better control over dynamic luminance / eye adapt now (can actually use it and it looks pretty good now)
• added color saturation as a value setting instead of just an on/off
• fixed grass color not matching ground color like it should
• tweaked lighting model (skydots seem to act as occlusion factors, not sky light luminance.. weird. Had to adjust the lighting model, and then mess with the mirror-like cubelighting on cars (eg: lighting that makes metal objects look shiney), b/c it was hosed up again.fixed it for now. feel like it needs more tweaking, though, because the shaows cause nasty splotches across mirror-like metalic surfaces now)
• forcing ground do bump map matrix math in pixel-shader going forward instead of giving option to do it in pixel shader or vertex shader (fuel default); ground has better bump-mapping and lighting with bump-map matrix calculations moved to pixel-shader, and graphics cards shouldn't have an issue
• more robust water lighting, which means more pixel-shader calculations but also more control over how it looks. still can't seem to get puddles to look right when in shadows around sunrise/sunset, though (they look too dark and stick out compared to surroundings. It's on my to-do list. I may just go full pixel-shader lighting for water to see if I can standardize it all.).
• added specular to plants/grass + a bit to ground that didn't have some, so there's a bit more sun detail. this is esp noticeable at dawn/dusk with bloom on when sun is shining almost level with landscape and the specular on grass/ground adds to the sun reflection "trail" pointing towards camera. Had to be careful not to add too much specular, though, or else ground would look wet.
• Misc, minor performance improvement tweaks to code.

2016-Jul-05: Corrected dynamic luminance and bloom to take night darkening into account, so those can be on while night darkening multiplier makes nights darker. Added flag to let user adjust how much bloom effect they want in addition to just turning it on/off. (I'd like to do something like that for dynamic luminance, but that's a bag of crazy that I'm still struggling with).

2016-Jul-04 : Minor correction to fx.phl scene post-processing file to keep dynamic luminance from being too bright (although it is still annoyingly bright). Added back in the blue'ing of night time scene to make nights look blue'er / richer. Was applying vehicle occlusion to sun-side of vehicle to help sun-side of vehicle have more depth/body, but it's causing some things to bee too dark sun-side (eg: monster truck wheel wells are dark gray instead of white, Spider Wraith's engine was super dark in sunlight, etc) so switched back to not having AO apply to sun-side of vehicles.

Future Desires

I don't call these "plans", because a plan is something you can implement. Instead, the things I desire (hope) to change/do in the future with the shaders are as follows:

• Implement Variance or Exponential Shadowing to make shadows even smoother. (Asobo has the code in the game for it, but I've never been able to figure it out and I think the times I've messed with it I realized certain things were broken, eg: values needed from the game engine weren't being piped to the shaders). This was one of the things I really wanted to change when I first started messing with the shaders, b/c I always found the shadows in FUEL to look chunky/tacky. My naive self thought it was just a simple matter of increasing some value to magically make it happen.. LOL ... nope. Now that I know more about HLSL, shaders and the FUEL shaders specifically, maybe I can tackle that challenge again some day.
• Better Ambient Occlusion on vehicles and buildings. They have a method implemented, but it leaves sun-side things flat-looking a bit. Would be nice to have sun-side of objects have some shadowing to add more body. I've stared at shader-only AO solutions, and it's quite a bit to wrap my head around.
• I'm sure there's more, but as my realizations of the limitations of what I can do with the shaders has set in, my fantasy option implementation list has gotten trimmed shorter and shorter.

Q&A (since they will be asked eventually)

Q: Will this work with Vetron's FUEL: REFUELED mod?

A: Yes, it should. I think his mod does a lot of code interception and injection. (IE: his mod is either rewriting the code of the game engine, or it's acting like an overlay that intercepts parts of the game running, modifies them, and then dumps out a result back tot he game engine to use.. sort of like how some "trainers" work on games that intercept snips of game code to then make you invincible or have unlimited ammo or whatever. The files I worked on are the graphics shaders. They're just the frosting to the cake (game engine). All they do is change how the game may look. I haven't tested the shaders with REFULED (I was trying to keep a pure copy of FUEL to work with while I made changes to reduce the variables if something blew up .. eg: I'd know it was something I did in the shaders, and not something another mod might be doing). I'd be tempted to try it with REFUELED, but haven't gotten around to it.

Q: There's some files missing in your shader download. There's like 94 shader files in original FUEL. You've got like 88, and that's including the _setup files, so really...there's like 86 shader files in your download. What's the deal?

A: Asobo wrote a bunch of shader files as they tested things, and essentially made a "library" of shader code for FUEL. Some of it was scrapped and not used as they went along, though. I think they initially started out with some very basic shaders and vertex lighting. Then, as time went on, they broke out some shaders to their own files and expanded to use more pixel-shader lighting for better detail. However, to do this they just coded more shader files and rewired the game engine to use the ones they needed, leaving the old shader files around (which makes sense... in case they need to roll back or reference... it's not uncommon for some games to give players options to use better or lower quality lighting, so having shader files that let you fall back on vertex-lighting only as low-quality would make sense. It's just Asobo didn't haev time to code options to let that happen). When I started tweaking the shaders, I spent hours messing with certain files thinking I was making improvements. Then I started setting up debug settings (eg: making a color on texture bright red) to see what I was impacting. As I realized some things didn't seem to do anything, I started by disabling the code (just having the routine send back a simple result and skip all calculations) and later just experimented with deleting whole shader files. The files left over are what are needed, and in some cases, aren't needed but the game blows up when compiling shaders if the file isn't there (eg: water.phl is useless... but the game won't compile without it). Also, as I refactored some things in base files (like VS_Const.h and VS_Config.h), certain files were no longer needed. I deleted them, and realized the game would compile and run, but it would compile very slowly... as if it was scratching its head on why a file wasn't there. So, some files are completely blank (as I refactored the code to more logical places), but kept around simply because FUEL seems to compile shaders faster with those blank files sitting around. tl;dr... if you toss my new shaders into your FUEL shader folder, and they compile... then things are working as they should. If FUEL blows up by saying it couldn't compile the shaders... THEN there's a problem. The amount of files is not something to worry about.

Q: I came here from the FUEL Wiki. Happyhamster posted a news blurb about this talking like he did all the work on it. But, the creator of this mod seems to be Tundrowalker. Why is Happyhamster trying to take credit for your work?

A: I'm one and the same. My Wiki name is Happyhamster. When I decided to upload the shaders to ModDB, the name Happyhamster was already taken (by someone in Russia, apparently). So, I decided to use an alt moniker.

Q: You're doing stuff with graphics! Can you add more vehicle liveries?

A: No. Those are texture assets in the game engine's asset files, which a) I can't figure out how to unpack (even using Vetron's instructions), and b) I think even Vetron looked into a way to add more liveries and found it impossible without having access to the game engine source code to code the new liveries in. So... yeah... still screwed in that department (because some of the liveries on the vehicles are really ugly. I'd love to crack open the textures and see if they can be made higher resolution or something, because an HD conversion of the game textures may help the game look better. Especially trees... ugh.)

Q: The game crashes after I play a level with tornados. Can you fix that?

A: No. It seems to be an issue with the game engine, which I can't tweak.

Q: The Mudhog buggies front shock absorbers change colors sporadically. What's the deal with that, and can you fix it?

A: No. Once again, something in the game engine is incorrect. What it's doing is flashing from normal texture to full, dirt-covered texture then back again. It may have something to do with viewing angle? I don't know. But, it's something inherent to the game engine. Once again, wish I had some source code to be able to fix those problems.

Q: Can you update this to DirectX (10/11/++)?

A: No. I'm pretty sure the DirectX version the game is stuck with is coded in the game engine. To swap over to a more modern DirectX version I'd once again need access to game engine source code. Then I'd have to tool around and figure out what flags need to be changed, figure out how to point it to a different version of DirectX... it's somethign I've never done, and so I have no clue what kind of nightmare that would be. But, supposedly versions of DirectX higher then 9 have faster shader compilers. Oh well.

Q: Can you strip out that annoying Games For Windows Live popup that shows up when the game starts.

A: No. Once again.. game engine stuff. I think there's some download on the net you can get to disable GFWL by using an altered xlive.dll file. I haven't tried it.

Q: Can you make the game multiplayer again?

A: Sadly, no. Again... game engine stuff I have no control over. This is the problem with developing games that have MP contingent on some service someone else controls (in this case, GFWL). So, when that 3rd party drops support... so long multiplayer. Basically, developers code games these days to use MP services, and someone else has control over when the plug gets pulled. You can't start local LAN games. You can't create your own server. It really sucks. Developers bought into this stuff, because it meant they didn't have to spend $ to run servers themselves. But, the catch-22 is customers get upset when part of their games functionality, which they paid for, is pulled out from under them. Anyways, I dont' know of a way to play FUEL in MP / online mode. Wish I did.

Q: Can you add (super awesome idea #435,862,475) I just came up with off the top of my head in like 5 seconds without thinking about how much time and effort or feasibility it may actually take YOU to implement?

A: No. The shaders are limited in what they can do. There's a lot of moving parts, and Asobo was really pushing the envelope of what they could do with DirectX 9's limitations. For starters, shaders can't change game engine stuff, like how vehicles perform. They can't change things hard-coded, like LOD settings in the game engine that dictate when LOD textures fade into near textures. Likewise, a lot of ultra-cool fancy stuff you see in games (like god rays) require being able to create a texture and have the game engine process and pipe it in for shader files to work with. I haven't been able to crack FUEL's asset files, and I don't have access to the game engine code to be able to tweak it to be able to do more awesome stuff. You see, graphics is a pipeline. The game engine does stuff, then pipes things to vertex shaders, then they pipe their results back to game engine, it does more stuff, then pipes to pixel shaders, they do stuff, then they pipe back to game engine, it does stuff, and then pipes results to final post-processing pixel shaders, then those go back in and the game engine finally spits something out for you to see. I only have access to the vertex and pixel shaders, which is a very narrow window of stuff to work on, and a lot of more advanced graphical stuff requires being able to tweak the game engine to do cpu calculations and DirectX flag setups to then setup the foundation for shaders to do their things. You can brute-force implement some things in shaders only (eg: I found a thing for Ambient Occlusion that seems to only be shader-side processing)... but it takes a lot of work to wrap your head around (or at least my head around...I'm a right-brained person that does data analysis and database work for a living that would rather be in social science...so math and advanced graphics concepts are a bit much for me). It's easy to come up with tons of ideas... ideas are a dime a dozen. But, the time, effort and feasability of making them possible is what matters. I'm not saying something is impossible. I'm saying I probably can't do it.. Plus, I've worked on enough mods for games that it tends to be insulting for folks to just drop massive atom-bomb ideas on a person like they would only take 2 seconds to implement. Chances are, as with most things in life, all the easy, good ideas are already implememented. If it's not implemented, it's because it's either not easy or it's not possible (for the person modding). So, I just want to cut this off before it starts... I'm not up for getting flooded with tons of "awesome ideas!", b/c people that dream them up are usually selfish and just thinking about their own gratification and not the blood, sweat and tears of the person doing the work.

Q: Can you fix "issue I'm having" with the graphics?

A: Issues ARE something I'd like to know about. If you spot errors, like a texture out of place, then, yes, let me know. There are some things that are inherently wrong that I can't fix. EG: the bump-mapping seems to be screwed up on some ground textures, making them look wrong at night in headlights (eg: they looked shaded correctly one way, then looking at them opposite direction they seem to be shaded completely wrong for how they should look). There are spots on the ground where texels don't mesh nicely causing stark distinctions between textures. There's just hodge-podge stuff you start to notice, then wonder if it's something wrong with the shaders... and a little messing around makes you realize it's something inherent to a texture (which I can't edit) or the game engine (ditto) or something "not shader related". But, I am up for hearing of issues. I made lots of "death of a thousand cuts" changes to the shaders. I can't possibly play-test everything and notice every little thing it may have screwed up. So, yeah, let me know.

Q: Can you fix "issue I'm having" with the game that's not graphics-related?

A: No... like I said, I don't have access to the source code for the game engine. If the issue you're having is AI vehicles and roaming trucks looking like they're flying down the road at 200mph when they gain enough distance from you... that's caused by too high of FPS. You need to go into your graphics card and setup a profile for FUEL that forces either VSYNC or an FPS cap of 60FPS. For some reason Asobo designed FUEL to use FPS as timing for some things. As vehicles get out to a certain range they move from "real time" to "FPS time", and a super-high FPS will make them skate around the game world at impossible speeds. Thus, you have to cap the game at 60FPS or so. Other issues that are game related... sound, whatever... you can try visiting the FUEL Wiki for trouble-shooting.

Q: Vetron hasn't updated REFUELED in a while. Can you make some changes to it?

A: No. There are some folks that think a person spending time modding a game is "free labor" to assign to other work. That's insulting when people think that. For starters, Vertron's mod is Vertron's mod. There are cases where people fork mods and create a branch, but I would never work on Verton's mod without his permission. I don't even have access to any source code for his mod. Even if I did it takes time to stare at code and get up-to-speed on what it's doing. If Vertron has fallen off the face of the Earth in regards to FUEL modding, and then I come along and do something for FUEL recently, that doesn't mean that I'm going to take over another person's mod and act like the new slave labor for it. It's sad that I have to say this, but I know I'm going to get someone asking this very question.

Q: You sound like kind of an asshole.

A: I've worked on game modding long enough to know that some people that use mods but don't code them can be assholes from the start. Not everyone, but a few apples definitely make you defensive. I've had questions like these on other games and other mods (mostly mod work I've done on Elder Scrolls games for Morrowind and Skyrim). I like working on what I want to work on. This is my free time I'm spending, after all. It's easy to dream up ideas. It's harder to make them happen. Some people think you should be so grateful for them to dump a ton of ideas on you that they thought up in 2 seconds without them realizing how difficult it would be to make happen. They have no clue how insulting it is. They get to kick back and enjoy life, but expect you to slave away on their ideas. Then they stop by and complain when either a) you haven't worked on their idea, or b) you're not making fast enough progress. They have this weird idea that modders are getting paid to work like an 8-5 job, and some folks treat modders like we're the Customer Service Department for a game and just s**t all over us with ideas and whip cracking. Like I said, not all mod users. I love it when someone uses a mod I did and says "this is great!" Makes me feel good. But, when someone says "you know, this wold be better if (here's a bunch of work I now expect you to do on your mod for me, slave)" it really just pisses me off to no end. So, yeah, I'm a bit of an asshole, because I have to be. I learned in it my professional life with 15 years in the IT/IS world dealing with people that had outlandish ideas with no concept of time or budget constraints, and I learned it by modding with people that didn't value my free time. So... yeah.