Talk:Damage: Difference between revisions

2,844 bytes added ,  28 February 2017
Line 124: Line 124:
:::::::::Thanks for testing. That's actually a neat way to find out whether something "affects damage" or "affects power" (although moderately hard to execute). I'm personally always interested in any explicit confirmation on which it is (for anything, especially on whatever wasn't there back in Gen V).
:::::::::Thanks for testing. That's actually a neat way to find out whether something "affects damage" or "affects power" (although moderately hard to execute). I'm personally always interested in any explicit confirmation on which it is (for anything, especially on whatever wasn't there back in Gen V).
:::::::::FYI, you can just manually adjust the power of any move within that calculator, so you can have a Thunderbolt with BP 40 or whatever you like. [[User:Nescientist|Nescientist]] ([[User talk:Nescientist|talk]]) 11:14, 17 December 2016 (UTC)
:::::::::FYI, you can just manually adjust the power of any move within that calculator, so you can have a Thunderbolt with BP 40 or whatever you like. [[User:Nescientist|Nescientist]] ([[User talk:Nescientist|talk]]) 11:14, 17 December 2016 (UTC)
== Regarding stacking "other" effects (attn: Nescientist) ==
On my talk page, while discussing this page before it was overhauled, [[User:Nescientist]] informed me of the exact formula used for applying multiple "other" effects in the damage calculation. A quote follows, for anyone else wanting to follow this conversation:
*FYI, the complex stuff is that those modifiers aren't really just decimals, but 16-bit integers that are then divided by 0x1000, and they are appended as M<nowiki>''</nowiki> = ((M * M') + 0x800) >> 12 (Quote from [[User:Nescientist]] taken from [[User talk:Felthry]])
I have done some analysis, and I am now reasonably certain that this is exactly multiplying the two numbers. Using sixteen-bit integers divided by 0x1000 is exactly equivalent to using Q3.12 fixed-point numbers to represent the data. This means that a value of 1 would be indicated as 0b0001 0000 0000 0000 (split into 4-bit blocks for readability), while 2 would be 0b0010 0000 0000 0000 and 1/2 would be 0b0000 1000 0000 0000. Multiplying these two numbers in the standard manner would be M<nowiki>''</nowiki> = (M * M') >> 12. This is true because each number is, in effect, X << 12, where X is the intended value; << 12 is equivalent to multiplying by 2<sup>12</sup>, or 0x1000. Now, if each number is represented as X * 0x1000, this means that multiplying M * M' would be the same as multiplying (X * 0x1000) * (Y * 0x1000). Dividing by 0x1000, equivalent to a right shift by 12 bits (i.e. >> 12), makes this into (X * Y) * 0x1000, which is exactly (X * Y) in the Q3.12 format.
Now for the interesting bit. What they have with the 0x800 here is actually to make the end result round properly, as opposed to simply truncating it as the normal method would. This is equivalent to adding 1/8192 to your final result; this number is used because the resolution of a Q3.12 number is 1/4096. If the bit in position 0x800 (i.e. the 12th bit from the right) is 0, adding 0x800 will do nothing, and this extra bit will be truncated off, thus rounding down, when the right shift occurs. If this bit is 1, adding 0x800 would have the effect of rounding up, adding 1/4096 to the truncated value, as the addition would cause a carry into position 0x1000.
Thus, the formula M<nowiki>'' = ((M * M') + 0x800) >> 12 is exactly the way to multiply two Q3.12 numbers or indeed any two Qn.12 numbers, while rounding in the conventional manner to be as accurate as possible.
Sorry for the impromptu lesson in fixed-point arithmetic; I wanted to prove this result rigorously so that we can be absolutely certain that it holds up! In fact, this also holds for 2's-complement signed fixed-point numbers, but I won't bother proving that as the "other" value is never negative. --[[User:Felthry|Felthry]] ([[User talk:Felthry|talk]]) 16:24, 28 February 2017 (UTC)
314

edits