YesNoOk
avatar

Build 23567 (3/24) (Read 30587 times)

Started by FrantzX, March 25, 2009, 03:16:29 am
Re: Build 23567 (3/24)
#21  March 29, 2009, 07:25:28 am
  • avatar
  • **
    • code.google.com/p/xnamugen/
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.
Re: Build 23567 (3/24)
#22  March 29, 2009, 07:44:03 am
  • ******
  • Legendary XIII
  • I am the eye of the storm to come!
    • New Zealand
    • network.mugenguild.com/cyanide/
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.


In M.U.G.E.N there is no magic button

They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.
Re: Build 23567 (3/24)
#23  March 29, 2009, 07:49:46 am
  • *****
  • DAT SAX
^ Agreed.

I've had no problems fixing my characters to be more compatible with XNAMugen so far.

                  ~*The Last Quincy*~         ~Sig by [TempesT]
My MUGEN shit:
MvC2 Tron Bonne, MvC Kim Kaphwan, Barns (Destruction Desire),
and Burai Yamamoto (Arranged)
Re: Build 23567 (3/24)
#24  March 29, 2009, 10:26:08 pm
  • *****
  • Hedgehog Whisperer
  • Red Bull addict
    • Spain
    • xgargoyle.mgbr.net
IIRC, the PalFX parameters are buggy in mugen. The R component doesn't work as it should be.
XGargoyle: Battle posing since 1979
http://xgargoyle.mgbr.net
http://www.pandorabots.com/pandora/talk?botid=e71c0d43fe35093a  <-- Please click that link
http://paypal.me/XGargoyle  <-- Donations welcome!
Re: Build 23567 (3/24)
#25  March 30, 2009, 04:33:20 am
  • avatar
  • **
    • code.google.com/p/xnamugen/
IIRC, 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.
Re: Build 23567 (3/24)
#26  March 30, 2009, 04:38:18 am
  • *****
  • ロッキングガール
  • 「目指すはクールでロックなアイドル!」
    • twitter.com/c001357
Re: Build 23567 (3/24)
#27  March 30, 2009, 10:18:53 pm
  • *****
  • Hedgehog Whisperer
  • Red Bull addict
    • Spain
    • xgargoyle.mgbr.net
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,256

That 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/256

Mathematical result: 246,238,230
Actual mugen result: 246,238,230
Works perfect!

Scenario 2
    add = 0,0,0
    mul = 0,0,0
(246 + 0)*0/256
(238 + 0)*0/256
(230 + 0)*0/256

Mathematical result: 0,0,0
Actual mugen result: 0,0,0
Works perfect!

Scenario 3
    add = 0,0,0
    mul = 80,80,80
(246 + 0)*80/256
(238 + 0)*80/256
(230 + 0)*80/256

Mathematical result: 76.875, 74.375, 71.875
Actual mugen result: 74,73,74
WTF!!! 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/256

Mathematical result: 123,119,115
Actual mugen result: 123,117,115
WTF!!! 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/256

Mathematical result: 187,183,179
Actual mugen result: 189,182,181
WTF!!! Almost there, but still resulting numbers don't make much sense

Ok, 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/256

Mathematical result: 191.5, 191.5, 191.5
Actual mugen result: 189,190,189
WTF!!! 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
XGargoyle: Battle posing since 1979
http://xgargoyle.mgbr.net
http://www.pandorabots.com/pandora/talk?botid=e71c0d43fe35093a  <-- Please click that link
http://paypal.me/XGargoyle  <-- Donations welcome!
Last Edit: March 30, 2009, 10:23:10 pm by XGargoyle
Re: Build 23567 (3/24)
#28  March 31, 2009, 11:08:05 am
  • avatar
  • **
    • code.google.com/p/xnamugen/
This. This is the exact problem I'm facing with both the PalFx family of state controllers & AfterImage.
Re: Build 23567 (3/24)
#29  March 31, 2009, 05:47:05 pm
  • ******
  • [E]
    • Mexico
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.
Re: Build 23567 (3/24)
#30  March 31, 2009, 08:43:54 pm
  • ******
  • In after lock
    • mugenguild.com/~messatsu/index.html


Many people risk their lives everyday by having Mugen.
Re: Build 23567 (3/24)
#31  March 31, 2009, 10:22:05 pm
  • ******
  • [E]
    • Mexico
oh, sorry, that's a typo, the triggers are properly typed in the cmd files.