The documentation is nice and all, but it doesn't help when what the documentation says should happen and what actually happens doesn't match. All afterimage behavior in xnaMugen follows the documentation nearly perfectly.
Hmph. You're doing a bloody good job showing how much of mugen is broken. I know you wish to replicate mugens behaviour so obviously you're going to be replicating the brokenness. In some ways i'd prefer people to have to fix their characters so what happens in game is accurate to what the docs say should happen. Rather than XNA replicating the buggy stuff.
XGargoyle said, March 29, 2009, 10:26:08 pmIIRC, the PalFX parameters are buggy in mugen. The R component doesn't work as it should be.This is awesome information. Is there a list of bugs and quirks of the MUGEN engine somewhere? It would save me a lot of time.
http://mugenguild.com/forumx/index.php?topic=91743.0http://mugenguild.com/forumx/index.php?topic=70338.0
Back to the PalFX controller and how broken is it. According to the mugen docs, PalFX works this way:Quote add = add_r, add_g, add_b (int) mul = mul_r, mul_g, mul_b (int) Each add component is added to the appropriate component of the player's palette, and the result is multiplied by the appropriate mul component divided by 256. For instance, if pal_r is the red component of the character's original palette, then the new red component is (pal_r + add_r)*mul_r/256. The values for mul must be >= 0. The defaults for these parameters are for no change: add = 0,0,0 mul = 256,256,256That means for a given color spot of (246,238,230), we could plan the following scenarios:Scenario 1 add = 0,0,0 mul = 256,256,256(246 + 0)*256/256(238 + 0)*256/256(230 + 0)*256/256Mathematical result: 246,238,230Actual mugen result: 246,238,230Works perfect!Scenario 2 add = 0,0,0 mul = 0,0,0(246 + 0)*0/256(238 + 0)*0/256(230 + 0)*0/256Mathematical result: 0,0,0Actual mugen result: 0,0,0Works perfect!Scenario 3 add = 0,0,0 mul = 80,80,80(246 + 0)*80/256(238 + 0)*80/256(230 + 0)*80/256Mathematical result: 76.875, 74.375, 71.875Actual mugen result: 74,73,74WTF!!! G component which was greater than B result in a lower number. R and B result in the same number yet the original colors were completely different.Scenario 4 add = 0,0,0 mul = 128,128,128(246 + 0)*128/256(238 + 0)*128/256(230 + 0)*128/256Mathematical result: 123,119,115Actual mugen result: 123,117,115WTF!!! G component gives a different result.Scenario 5 add = 128,128,128 mul = 128,128,128(246 + 128)*128/256(238 + 128)*128/256(230 + 128)*128/256Mathematical result: 187,183,179Actual mugen result: 189,182,181WTF!!! Almost there, but still resulting numbers don't make much senseOk, now suppose our starting color is pure white (255,255,255) and you apply Scenario 5:Scenario 5b add = 128,128,128 mul = 128,128,128(255 + 128)*128/256(255 + 128)*128/256(255 + 128)*128/256Mathematical result: 191.5, 191.5, 191.5Actual mugen result: 189,190,189WTF!!! Please someone explain this to me...And this is only taking into account the add and mul parameters, you can guess how wrong the whole thing can result if you even add the rest of parameters such as sinadd or color
This. This is the exact problem I'm facing with both the PalFx family of state controllers & AfterImage.
I guess the general consensus is to ignore how mugen does it and do it as the docs say it should work.A small bug I found while testing my stuff.triggerall = comamnd = "y" && command = "b" is not triggering for some reason, that trigger won't work in dos mugen, but it works properly in winmugen.
Frederica Bernkastel~ said, March 31, 2009, 05:47:05 pmA small bug I found while testing my stuff.triggerall = comamnd = "y" && command = "b" is not triggering for some reason, that trigger won't work in dos mugen, but it works properly in winmugen.You typed this?
