Wii Development

[msmalik681]

. . .

 

[DCurrent]

I'm on a phone, so no code work for me until Monday, but I'll see what I can figure out then.

 

[msmalik681]

Ignore me I set the X value to a fixed figure for a test and forgot to change it back.

Also I fixed the issue with the wii port I will upload a test build tomorrow. Just need to fix them 16 bit samples now.

 

[msmalik681]

Here is a test Wii build with the velocity fixed please test and report any issues.

This annoying bug seemed to be where the temporary variable was holding garbage data so I used memset to clear it and it worked as expected.

Edit: Back to the drawing board. This velocity bug will be the end of me.

 

[kimono]

Thanks for your hard work, I've got a Wii and a WiiU and it will be a pleasure to play with others through this platform. 

 

[msmalik681]

Finally pin pointed the problem but fixing it is another thing as this openbor script library is very complicated.  So the issue is when you use "velocity" command with the first argument as a non rounded number the Wii port detects it as some crazy number.

Test on windows recording the incoming integer value to X. first facing right then left with x=1. performed another move first right then left x=1.5:

varlist[2]->lVal = 1
varlist[2]->lVal = -1
varlist[2]->lVal = 0
varlist[2]->lVal = 0

Here is the same test for the Wii:

varlist[2]->lVal = 1
varlist[2]->lVal = -1
varlist[2]->lVal = 1073217536
varlist[2]->lVal = 1074266112

I thought about rounding up or down the number but that input value does not make sense.  But still the moves seem to be OK when performed facing right it's just minus figures that are the issue also Y and  Z are fine with non rounded minus numbers so it is not a Wii limitation. I failed maths and here we are dealing with floating point numbers and PI I don't think this is something I can fix but I just can not give up  .

 

[msmalik681]

@DC

Will you still be looking into this.  If you are just to confirm the only problem is when you pass the first argument (token) of "velocity" and it is a un-rounded minus figure ( example: -0.4 ) the Wii will not get the correct figure rounded fugues (example: -2) are OK.  I am currently looking over axis.c but I can't figure out what I am looking at lol.

@White Dragon

@cmd changeentityproperty getlocalvar("self") "velocity" -0.8 0 0

The fact that this above code works perfectly proves the argument is being corrupt when taken from a animation script like this:

void dasher( float Vx, float Vy, float Vz )
{// Dash with desired speed!
    void self = getlocalvar("self");

    getentityproperty(self,"direction") == 0 ? Vx = -Vx:"";

    changeentityproperty(self, "velocity", Vx, Vz, Vy); //Move!
}

Here is a very small mod to use when running tests just attack ( X=0.1 ) or run attack ( X=1.8 ) and the dasher animation script ( "velocity" ) will run issue will only show on wii when facing left : http://www.mediafire.com/file/bjy08h2x0rerjt6/DDBL.pak/file

 

[White Dragon]

@DC

Will you still be looking into this.  If you are just to confirm the only problem is when you pass the first argument (token) of "velocity" and it is a un-rounded minus figure ( example: -0.4 ) the Wii will not get the correct figure rounded fugues (example: -2) are OK.  I am currently looking over axis.c but I can't figure out what I am looking at lol.

@White Dragon

@cmd changeentityproperty getlocalvar("self") "velocity" -0.8 0 0

The fact that this above code works perfectly proves the argument is being corrupt when taken from a animation script like this:

void dasher( float Vx, float Vy, float Vz )
{// Dash with desired speed!
    void self = getlocalvar("self");

    getentityproperty(self,"direction") == 0 ? Vx = -Vx:"";

    changeentityproperty(self, "velocity", Vx, Vz, Vy); //Move!
}

mmm.. are poritive values ok? like +0.8 or just 0.8?

 

[msmalik681]

yes 0.8 will work as expected.  but when the script reverses it to -0.8 that is the issue or even it you manually type any negative decimal placed value.

 

[White Dragon]

yes 0.8 will work as expected.  but when the script reverses it to -0.8 that is the issue or even it you manually type any negative decimal placed value.

ok BTW this line is wrong!!
getentityproperty(self,"direction") == 0 ? Vx = -Vx:""; // IS WRONG!! (bad use of ternary operator)
Vx = (getentityproperty(self,"direction") == 0) ? -Vx : Vx; // IS RIGHT!!

or just
if (getentityproperty(self,"direction") == 0) Vx = -Vx;
or
if (getentityproperty(self,"direction") == 0) Vx *= -1;

 

[msmalik681]

@WD
thanks for the pointer (no coding joke intended) it was one of my many tests to fix this issue.

 

[DCurrent]

@DC

Will you still be looking into this.  If you are just to confirm the only problem is when you pass the first argument (token) of "velocity" and it is a un-rounded minus figure ( example: -0.4 ) the Wii will not get the correct figure rounded fugues (example: -2) are OK.

Yes I am. Classes are starting and I'm also in and out of the hospital lately (not for me), so I'm a bit sporadic, but look at it in small bits as I get moments.

I am currently looking over axis.c but I can't figure out what I am looking at lol.

Don't bother looking here. Axis.c is part of my property project - it part of the new entity property system and has nothing at all to do with the current getentityproperty() function.

...

WD is right, but you also need eliminate those magic numbers for direction. Normalize them with the available direction constants, like this:

int direction;

// Get current direction.
direction = getentityproperty(self, "direction");

// Reverse the X velocity adjustment if facing left.
if (direction == openborconstant("DIRECTION_LEFT"))
{
    Vx = -Vx;
}

DC

 

[White Dragon]

@WD
thanks for the pointer (no coding joke intended) it was one of my many tests to fix this issue.

Well I found the issue and fixed!!
Please test this build:
https://www60.zippyshare.com/v/6MOQhMqZ/file.html
wii test build with issue fixed and compiled with latest devkitpro.

Given the heavy issue, frankly, it is strange that it has worked on any port so far, indeed, it may have been just one case due to larger Wii memories.
Issue was on parser (pushing op on stack) and scriptvariant... :-\

 

[msmalik681]

I will test as soon as i get home i am stuck at work thanks for your help on this.

 

[msmalik681]

As expected you fixed completely it now are you willing to share the source code for the fix and if you have upgraded the wii port to work with the latest DevkitPPC (r32 i think) that was also be a nice asset.

If you are still happy to share your work I give full credit to you on github but it is up to you.

Edit: come on guys I know how to make a if statement for direction that last code was just for a quick test  ???

 

[MaxBeta]

Wait. So you guys finally managed to fix the directional bug???

OH HAPPY DAY! Congratulations to both of you!

I cannot wait to get home to test!

 

[msmalik681]

Wait. So you guys finally managed to fix the directional bug???

OH HAPPY DAY! Congratulations to both of you!

I cannot wait to get home to test!

Nope White Dragon fixed I just complained about it

 

[MaxBeta]

Wait. So you guys finally managed to fix the directional bug???

OH HAPPY DAY! Congratulations to both of you!

I cannot wait to get home to test!

Nope White Dragon fixed I just complained about it

LOL But you did the research and found the potential problem.
Thank you for all your work Malik and thank you White Dragon for kicking this nasty bug in the butt.  8)

 

[White Dragon]

Wait. So you guys finally managed to fix the directional bug???

OH HAPPY DAY! Congratulations to both of you!

I cannot wait to get home to test!

Nope White Dragon fixed I just complained about it

LOL But you did the research and found the potential problem.
Thank you for all your work Malik and thank you White Dragon for kicking this nasty bug in the butt.  8)

Thanks to Malik to investigate!!

well..

Parser.c
change line 1817 from:

            Parser_AddInstructionViaToken(pparser, NEG, (Token *)NULL, NULL );

to:

            Parser_AddInstructionViaToken(pparser, NEG, (Token *)NULL, NULL );
            Parser_AddInstructionViaToken(pparser, SAVE, pInstruction->theToken, NULL );
            Parser_AddInstructionViaToken(pparser, LOAD, pInstruction->theToken, NULL );

ScriptVariant.c
change lines 927 from:

    case VT_DECIMAL:
        svar->dblVal = -(svar->dblVal);
    case VT_INTEGER:
        svar->lVal = -(svar->lVal);

to:

    case VT_DECIMAL:
        svar->dblVal = -(svar->dblVal);
        break;
    case VT_INTEGER:
        svar->lVal = -(svar->lVal);
        break;

I'm sorry not to be in the team anymore ...
So it was chosen.. Byeee

 

[MaxBeta]

I can confirm no directional bug observed while running White Dragon's test version with Nightslashers X which was the mod that would display all sorts of issues. Now they are all gone!
Thank you White Dragon!

However @Malik, for some odd reason this test version no longer loads your edited Lite version of Super Final Fight Gold plus.pak which is very odd. It crashes after 1% so not sure if something broke??

Here's the mod in question:
http://www.mediafire.com/file/td51k08nnzzu9ir/FFGoldPLUSREV3_LITE.zip/file

OpenBOR log says the following:

Script compile error in 'data/scripts/f_drago.c': line 0, column 0
Script error: failed to import 'data/scripts/f_drago.c': failed to compile

************* An Error Occured ***************
*                Shutting Down                          *

Can't Compile script 'Cody' data/chars/cody/cody.txt
Total Ram: 75497471 Bytes
Free Ram: 59383839 Bytes
Used Ram: 16113632 Bytes

I will test more of the working mods to see if it happens with any others.