Scrolling Game Development Kit Forum
SGDK Version 2 => Help, Errors, FAQ => Topic started by: Tanja on 2008-03-09, 08:00:48 AM
-
with some custom code i could change the alpha of tiles an a specific layer.
how would i start if i wanted to do the same for sprites?
i don't find the thread right now, here is the code from back then:
int overrideModulation = -1;
if (this is Spiel_Map.inventory_bg_Lyr)
{
overrideModulation = new ColorValue(255,255,255,Counter.AlphaMod2.CurrentValue).ToArgb();
}
for (int x = nStartCol; x <= EndCol; x++)
{
int[] SubFrames = GetTileFrame(x,y);
for (int nFrame = 0; nFrame < SubFrames.Length; nFrame++)
{
Frame f = m_Frameset[SubFrames[nFrame]];
spr.Transform = Matrix.Multiply(f.Transform, Matrix.Translation(
x * nTileWidth + CurrentPosition.X + ViewRect.X,
y * nTileHeight + CurrentPosition.Y + ViewRect.Y, 0));
spr.Draw(f.GraphicSheetTexture.Texture, f.SourceRect, Vector3.Empty, Vector3.Empty, overrideModulation==-1?f.Color:overrideModulation);
}
}
}
just in case: i know i could do it without creating custom code.
-
You'll want to find the other points where spr.Draw is called and insert the overrideModulation in there as well. There's one inside the if (Injected != null) block above the posted code, and one below it in the while (Injected != null) block.
-
thanks, i'll try that.
but here is another question about alpha.
i create some dynamic sprites, which alpha shall decrease. i made this rules:
do =
value: ModulateAlpha-10
output: ModulateAlpha
but the sprite doesn't become invisible, instead it flickers. i do not understand why.
-
After it gets to 0, it probably loops back to 255. You have to make it stop subtracting if the result would be less than 0.
-
i think you are right, the number is looping. i know how i can prevent it, but there is another problem. it loops very fast. it seems really that it decreases faster than my frame rate, is that possible?
anyway, i can't use counters (because they are many dynamic objects) to slow it down, and i can't use -0.1 because it accepts only whole numbers.
i had just the idea to use an expression for natural numbers, decreasing the alpha by 0.1 and round it up, but i realized right now it won't work.
i need to slow down the decreasing of modulateAlpha, help!
-
Use a counter that takes numbers up to 2550, then divide by 10 when applying the value in the code. Something like:
overrideModulation = new ColorValue(255,255,255,Counter.AlphaMod2.CurrentValue/10f).ToArgb();
(notice the f after 10 to ensure floating point division for better accuracy). You could also make a floating point value in the code, so that you don't have to worry about a counter in between, but that's a bit more difficult to explain.
-
do you mind to explain the other suggestion? i don't think i can use the counter, because it can happen that dozens of these sprites are on the screen at the same time. one counter would make them have all the same alpha, right?
-
Oh, I though this was still the same situation where the entire layer was being drawn this way.
Create parameters called AlphaFloat and init. Then create rules like this
if init == 0
do init = 1
do AlphaFloat = 2550
do AlphaFloat = AlphaFloat - 1
do ModulateAlpha = AlphaFloat / 10
The rules would be if ==, do =, do = (end if), do -, do /
-
thank you.
your script works. but now that everything is running slower, i can clearly see that ModulateAlpha is behaving really strange. instead of being 245 when AlphaFloat is 2450, it's -13 (or another silly number down from 0). i don't understand this. As long as the dynamic sprite lives, it's ModulateAlpha decreases in negative number room.
before that, as everything was faster, it was sometimes at -120 or so.
-
hm, just now i thought i had caught the error. i always write "do expression-10 = expression" instead of
do -
expression (value 1)
1 (value 2)
expression (output)
but i don't think that matters. btw, there is no way to multiply or divide at the do-rules (only minus, plus and the rest). why?
-
Well, I tested out what I said, and it works just fine. Are you sure there aren't other rules that also modify ModulateAlpha that conflict with this?
On a side note, you probably don't need all that. Just decreasing ModulateAlpha was slow enough to work just fine. The problem is probably that some other part of the system is changing the value incorrectly, making it flicker pseudorandomly.
-
i think i figured it out now. but the reason for that i don't understand.
if i execute the rule
copy 2450/10 to ModulateAlpha
the value ModulateAlpha gets is NOT 245. it is -10!
don't ask my why, but i debugged every little thing in this mini-script and that must be what happens.
(i copy the SAME value into another parameter and debug that: there is 245, so that works.)
-
I'm really not sure what's going on here. Just throwing out ideas:
There must be SOMETHING changing the value of ModulateAlpha at some point if you really do have do ModulateAlpha = 2450/10 and it changes between then and when you show the debug value.
Possibly you have simply typed in the /10 part wrong?
Look at the .cs file directly. Look for that bit in the ProcessRules function (or whatever it's called). Does it really look correct?
-
// if parameter init == 0
if (((init) == (0)))
{
// set parameter AlphaFloat to 2550
AlphaFloat = 2550;
// set init to 1
init = 1;
}
// decrement AlphaFloat
AlphaFloat = ((AlphaFloat) - (1));
// output AlphaFloat/10
FloatDividedByTen = AlphaFloat/10;
// copy AlphaFloat/10 to Alpha
ModulateAlpha = AlphaFloat/10;
well, there are a few rules additionally, but they are either suspended or something like: reactToSolid, and move or so.
-
Are there more rules after the last line you have there? Try doing the same thing in the sample project, and see if it works for you. If it does, then there's definitely some problem with the project itself.
-
There's a problem with reading the ModulateAlpha value because the C# ">>" operator didn't work the way I expected. You can make this change in SpriteBase.cs to fix it:
1) Find "public int ModulateAlpha"
2) Change the code in the get accessor from:
return color >> 24;
to:
return 0xFF & color >> 24;
-
Huzzah! Interesting that it worked just fine for me? Or is that only a fix for reading that value? The method I showed never actually reads that value.
-
It will only behave strangely if alpha is larger than 127, causing the overall color integer to be negative (by setting the sign bit). Apparently the right shift operator fills the emptied bits with the sign bit for signed integers. And yes, it only affects alpha because that's the high-order byte in the color integer.
-
thank you bluemonk, it works! i believed it must be something in the source code, and not my script. now is everything fine. ;D
now, if the zeppelin is flying through a cloud, it gets wet and drips. it looks fine. with a gravity which goes upwards one could make really cool looking bubbles if the player is under water.
and also thank you, durnurd, for your help. ;)