Wii Development

So I have investigated the pull to the right bug and here is what I found:

Tested on this move
anim runattack
loop 0
delay  7
offset  35 73
@cmd dasher 1.8 0 0
frame data/chars/0_billy/runatk101.png
frame data/chars/0_billy/runatk102.png
attack 41 7 36 29 10 1 1 0 0 0
delay 15
frame data/chars/0_billy/runatk103.png
attack 0 0 0
@cmd dasher 1 0 0
frame data/chars/0_billy/runatk104.png
Click to expand...

the script behind dasher is:

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!
}
Click to expand...

I changed the source code on openborscript.c to record the x value when changed by "velocity" script:

    case _ep_velocity:
    {
        if(SUCCEEDED(ScriptVariant_DecimalValue(varlist[2], &dbltemp)))
        {
            ent->velocity.x = (DOUBLE)dbltemp;
printf("ent->velocity.x = %d \n",(DOUBLE)dbltemp);
        }
Click to expand...

I performed the attack on the PC version first facing right then facing left here are the results:

ent->velocity.x = -858993459  //when facing right
ent->velocity.x = 0
ent->velocity.x = 858993459  //when facing left
ent->velocity.x = 0
Click to expand...

Now I did the same thing on the Wii:

ent->velocity.x = -2143659032
ent->velocity.x = -2143659016
ent->velocity.x = -2143659032
ent->velocity.x = -2143659016
Click to expand...

As you can see the Wii figures are completely wrong I need to work out at what point the animation script takes the input figures and starts to calculate them as something is incompatible with the Wii port.

I will keep searching @DC if you can give any insight it would be much appreciated.
 
The upside is that good or bad, you're at least getting consistent results. That's a starting point. There is clearly something odd about the way Wii handles floating points, but just from eyeballing this I couldn't say what. You might try taking it to one of their forums.

DC
 
But jumpframe works fine but I think that uses a float value where velocity uses a double value.

I will try asking at GBAtemp and see if they can help.
 
Nice find @msmalik681!
Can you please link me to the thread in GBAtemp once you create it?
I want to follow up and read if you dont mind. I found and followed the thread.
I find this all very interesting.
 
OK, so looking again at a desk and not a phone early in the morning... duh, doubles. So here's where the problem likely lies. Doubles are twice the size of floats (64 bits vs. 32). My guess the Wii simply can't work double values as is, and so they're going out of bounds. That's where the 214... is coming from.

It's an educated guess at best, but I bet the Wii folks can confirm.

DC
 
Is there any possible work around like using float values instead of doubles for the Wii port ?

What part of the source code handles all the script types I am guessing Parser.c ?
 
Before we do any of that, I want a second pair of eyes to have a look - someone who really knows their way around Wii coding. Plombo would be a great asset here if he could be contacted.

DC
 
So I have to ask after having read your findings and just out of my own curiosity.

The code for all builds should be the same right?
But these values behave differently in Wii and that is the result of the bug and not a difference in the Wii build code?
Very interesting.
 
Exactly. And this is why I don't want to go messing around until we find out for sure from Wii experts. Modifying engine logic to satisfy the needs of a port is a slippery slope and not something I'm prepared to do.

DC
 
Damon Caskey said:
Exactly. And this is why I don't want to go messing around until we find out for sure from Wii experts. Modifying engine logic to satisfy the needs of a port is a slippery slope and not something I'm prepared to do.

DC
Click to expand...

Specially when its not one of main ports, after the PC.
 
Damon Caskey said:
Exactly. And this is why I don't want to go messing around until we find out for sure from Wii experts. Modifying engine logic to satisfy the needs of a port is a slippery slope and not something I'm prepared to do.
Click to expand...
I may not know code but I do understand everything has its natural working process and jumping the gun may even brake more things, so I completely agree.
I hope Plombo or maybe someone from GBATemp comes through with some answers.
 
I was not suggesting we break or even change the windows port in any way.  If there is a way to read scripted floats (if needed) as floats a simple "ifdef wii" statement would be enough.

@ilu
There are no main ports after windows all ports come second.
 
@ilu
There are no main ports after windows all ports come second.
Click to expand...
heheh it's not the first time you have a hard time understanding what I say. Maybe it's a language barrier in action.

But it was pretty much this:
I think O means android port is priority as it is most accurate/stable to the PC version of Openbor.
Click to expand...
I don't consider the Windows version a "port". Is the main system. The main "port", to me, is Android for sure - and its something we should never ignore.

After android port all other ports are equally ignored lol.
Click to expand...
Honestly speaking? They should be ignored. They come from an old era and are not relevant anymore, in my point of view.
I would even say they could be deprecated, like DC port was - specially the very old ones like WII and PSP.
There once a time I wanted to compile the OSX version, but OpenBOR runs perfectly on Mac using Wine, so it's not worth.


 
O Ilusionista said:
I would even say they could be deprecated, like DC port was - specially the very old ones like WII and PSP.
There once a time I wanted to compile the OSX version, but OpenBOR runs perfectly on Mac using Wine, so it's not worth.
Click to expand...

We still have quite a few PSP players out there, and though it's been a pain, I don't think we should drop the Wii soon. But I agree about Mac port. It's a waste of space and on my list of things to eliminate.

DC
 
While it is true that Wii port is old it simply suffers from 1 technical issue which is the bug in recent discussion and also a memory issue that you are all aware of that could also be improved upon with a cache to sd method as pointed out in a thread referenced by msmalik in the first post.

I wouldn’t go far to call the Wii port irrelevant as it recently got a huge update regarding more freedom of wireless access with Wii U Pro controller compatibility (Wii U controller that can actually work with Wii through its homebrew integration) something that could have been added two years ago had it gathered the interest, and interest in the Wii port is exactly what this thread is about. At least 2 developers seem interested enough in it and progress has indeed been made.

If Demothens or msmalik were to figure out how to implement vc gamepad support for Wii U compatibility then this port would see an increase in performance like it could never perform on a Regular Wii, so there is still very much room for improvement and the documentation and tools as well as the interest are there. If all this goes well, then this community might as well see the best port since the android port.
So please, don’t kill it just yet when it has plenty of potential good in it.

That’s just my two cents to the matter.
 
People like myself use psp and wii for retro emulation and homebrews.  Openbor can make great modern games but there are a lot of retro classic remakes so it is very appealing  to retro games.  And this is not just a Wii port its unofficially a Wii-U port as it can run Wii homebrew.

I love all the ports for openbor.  Personally I hate macs and everthing about them.  But I think the mac port could lead to a iphone port as they both use x-code.

Would dropping support for any system improve the engine in anyway ? Dreamcast was dropped but it was never removed from the source code.
 
msmalik681 said:
Would dropping support for any system improve the engine in anyway ? Dreamcast was dropped but it was never removed from the source code.
Click to expand...

Err what? There might be remnants here and there, but dropping the DC took about 50 megs of crap out of the toolchain.
 
So please, don’t kill it just yet when it has plenty of potential good in it.
Click to expand...
The only person who have enough power to do this is Damon, so you are safe :)

Would dropping support for any system improve the engine in anyway ?
Click to expand...
More ports = more people needed = more work.
To make a new port is one thing. To actually support it is a different animal. Just look at some ports, like XBOX and MAC.
People had ported to those systems, but they are gone and now we have nobody to maintain them.
And some people won't undestand it and will start to blame the actual devs or even the engine itself - I've saw this happen a lot of times.

That is why.

Hehehe I will start to look as the bad guy soon, so I think I will stay away from this topic :)
 
You must log in or register to reply here.
Back
Top Bottom