Quote: "Ah, got it"
Actually, what I said before was slightly misleading. While what I said was correct, I'd overlooked the fact that the original version you were using has the following line:
float4 Light=DiffuseLight*LightColor*IN.Diffuse * 2.0f;
I'd forgotten it used the final factor 2 to brighten the final result. I suggest you just play with the values of lightColour and ambientColour till you get the result you want. Ideally the individual colour values of lightColour and ambientColour should add to 1 to avoid oversaturated colours (unless you want that effect of course or if you just want to brighten everything). For example you might have lightColour = {0.8, 0.8, 0.8, 1.0} and ambientColour = {0.2, 0.2, 0.2, 1.0}, i.e. the two red components add to 1 and so on (they didn't in my demo
). I suggested keeping them in the range 0 to 1 - but you can go outside that range if you want a special effect. The final colour rendered to the screen will have values in the range 0 to 1.
Quote: "Is there some kind of reference to these internal variables (such as ambientColor, lightDirection, lightColor, etc.)?"
They are variable names I decided to use - and I've used them in such a way that the four components in each of them are interpreted as {red, green, blue, alpha}. For terrains you would usually keep alpha at 1 and adjust the others. This arrangement makes it easy to align my colour vectors in calculations with the final colour output by the pixel shader (which is always in the RGBA order with components clamped to the range 0 to 1).
Quote: "Also, new question: How would I go about painting one texture onto another a bit at a time (so it starts faded and the longer you hold it, the more it paints). I don't know how I'd get the current RGB values, and I assume I'd need them in order to change them by a small amount at a time."
Good question.
One way would be to use a "brush" that fades towards the edges - but that might be awkward to implement. Another way would be to use the
blur bitmap command. This would have the effect of blurring the joins between two adjacent textures and might be all you need. However, in my experience that is slow and slightly unpredictable as it seems to shift the whole bitmap by a few pixels in some ill-defined way. If you use it sparingly, after doing lots of other changes for example, you might find it works. A tailor-made blur bitmap command would be faster - for example why bother blurring (i.e. averaging) pixels which are the same? (Of course, by the time you've programmed that you could have used the slow blur bitmap command thousands of times over.
)
On balance I'd be tempted to go for a modified brush. For example, here's the painting bit of Omen's code:
for i = -size to size
for j = -size to size
imageX = (((objOffX*1.0)/(TER_SIZE)) * image width( myimageID )) + i
imageY = (((objOffZ*1.0)/(TER_SIZE)) * image height( myimageID )) + j
pixel = (imageY * memblock dword(mem, 0)) + imageX
write memblock dword mem, (12 + (pixel * imageBytes)), mycolor
next
next
That just uses a square "brush" which replaces the existing memblock colour value for a block of pixels with mycolor. You could use a blend of the existing colour and mycolor instead and adjust the blending by how far "i" and "j" are from 0. Actually, the more I think about it that's the way I would go.
I imagine you can get the current RGB values simply by using the
read memblock dword command which corresponds to your
write memblock dword command.
Quote: "Then there's also the issue of dealing with textures from two different masks."
Perhaps we can deal with that later.
