Patch for GroundDecals.fp

[Argh]

I've fixed the fragment shader for GroundDecals, so that they no longer glow when shadows are turned on and behave correctly. Tested, working correctly in all tests. Only affects GroundDecals, and works properly with shadows- no black.

Please commit this. Here's how it looks in-game, on a night map:



And on day maps, it is also behaving correctly.

[Beherith]

That looks real sweet. Is it auto placed by your world builder? Does it need to have ground decals enabled to be visible?

I recall doing the buildings ground decals baked on to the textures... That was a massive pain.

[Warlord Zsinj]

argh's features are spawned using worldbuilder and belong to the gaia side, iirc. So they aren't 'features' in the classic sense, but more like actual buildings and units.

[Peet]

I suggest you submit this as a .diff if it has not already been committed.

[lurker]

Nah, it's just a single couple-hundred byte text file. I would commit but I'm unable to test it and don't understand the algorithm.

[Argh]

To test it... just replace current springcontent.sdz with this one. Sorry, I didn't realize that most of you guys don't ever mess with the fragment programs (which is a "duh", because they're not much fun to mess with).

It's not a very complex program- all it does is get the texture, get the light value for groundSunColor, and apply the shadow texture, which is colored groundAmbientColor, and uses an alpha value of groundShadowDensity, IIRC. Ground Decals use alpha, but they don't do reflectivity or blinn stuff, so it was Easy Enough for Argh® - really, it was just monkey work, figuring out how the parts interrelated, and the only confusing part is that groundFPshadow.fp, which I based it on, uses slightly different math for the end, because of the funky texture system for unit trails.

In fact... hey... why don't we replace groundFPshadow with this, and then we can finally have unit Footprints that are in full color, and use a normal alpha channel?

Previously, it wasn't applying the light value first, and the previous version had some comment about how they'd left it that way because otherwise the shadows were black, which was because it wasn't correctly applying the alpha or color. I figured out where they'd gone wrong, and fixed it, by comparing with groundFPshadow.fp, so it's quite similar now.

At any rate, I'd appreciate it if somebody could find the time to test and commit this, it fixes a "minor bug" that's actually pretty important in terms of look-and-feel, and I can't see how there could be any serious bugs associated with it- fragment programs either run or crash, there really isn't a lot of wiggle-room.

[lurker]

I'm perfectly capable of making a zip; this laptop can't do shadows.

[Argh]

Er, that wasn't what I was trying to imply. Just that other people might want to test it, so I packed it up so it'd be easy to verify my results...

[lurker]

You can take a joke better than that.

[Argh]

Not when I'm in the middle of making 80-some-odd new buildpics

[zerver]

Real sweet... night maps, we need more of those imo.

[Hoi]

Real sweet... night maps, we need more of those imo.

I think he has the night widget on.

[Kloot]

It looks like all you did was remove

Code: Select all

MOV shadeTex, {1, 1, 1, 1};

so that the linear interpolation between shadeTex and groundAmbientColor
(shadeColr = shadow.x * shadeTex + (1 - shadow.x) * groundAmbientColor)
does not start fully saturated. I don't see the connection to groundSunColor
(which isn't even passed to the shader, nor does it need to be), but that line
was indeed bogus.

[Argh]

I don't see the connection to groundSunColor
(which isn't even passed to the shader, nor does it need to be)

Oh. My bad, I thought that was the value being passed. Anyhow, it works.

[smoth]

Real sweet... night maps, we need more of those imo.

after christmas I resume work on a tweaked version of islands at war. Then I am making a desert night map.

[Argh]

Yay, it's been applied. Thank goodness, it makes a huge difference.