Wii...

[SplinterGU]

no hace falta otro dato mas, con eso que me dices, tiene logica ahora... creo que me olvide de los lens en los varspace... todavia no lo revise, en un rato lo hago...

muchas gracias a vos y a tu hno por el debug...

saludos.

[DCelso]

¿como es que en wiz no se detectó?
¿Mismo bit endian que en PC?

[josebita]

La versión para la Wiz hace un apaño para trabajar en little-endian.

[SplinterGU]

wiz usa los mismos endian que pc...

los arm los podes setear por soft que bitendian usar...

[DCelso]

ok, oído cocina.

[BoMbErLiNk]

He estado mirando la WPAD con resultados curiosos..

Supongo que solo sirve para el wiimote no ?
Como se accede a la información del acople con joystick que también tiene acelorometro ?

La vibración no me ha parecido ir en el mando de gamecube.
WPAD_Z no devuelve nada, siempre a 0.

ACELOROMETROS
Se mueve entre valores de 400 a 650 sin menearlo

Pero hay que tener en cuenta que al mover el mando también crecen los otros valores de X Y o Z, parecen fiables valores por encima de 820, el valor máximo llega a 1000 pero hay que dejarse el brazo  ;D.

WPAD_ROLL, WPAD_PITCH me parece que funcionan muy bien

[josebita]

Tengo que comprobar las salidas, pero en general los acelerómetros siempre te van a dar una lectura que corresponderá con la gravedad terrestre. Te interesa mirar aceleraciones relativas.
En cuanto a los valores extraños: lo miraré. A ver si esta noche puedo.

[SplinterGU]

Splinter, te cuento lo que he podido encontrar con respecto al bug de save. Como he dicho parece un error de endianes, así que supongo que aplica a Bennu.
El bug (load tiene un bug similar, que supongo que proviene del mismo sitio, aunque no lo he podido comprobar aún) está en la forma en que se leen las variables de los dcb; en particular alrededor de la línea 234 del fichero common/varspace_file.c el valor de la variable count no está swappeado (o lo está de más) de forma que en el ejemplo en lugar de valer 7 (como lo hace en un sistema little-endian) vale el swappeado de 7.

Por lo que mi hermano ha podido averiguar, el problema viene del fichero core/bgdrtm/src/dcbr.c (función dcb_load_from, alrededor de la línea 293) no se tiene en cuenta el endianess cuando se leen los datos globales.

La versión que he sacado no arregla esto sino que guarda en el dcb esas variables en el formato nativo de la máquina, a la espera de que implementes (Splinter) un arreglo real del bug. Si necesitas algún detalle más, puedo intentar dártelo.

estoy revisando el asunto, en el fuente common/varspace_file.c no hay error... ahora estoy revisando el dcbr.c creo que algo de eso hay ahi, si mal no recuerdo lo deje pendiente porque queria debuguearlo con una plataforma que tenga el endian correcto para esto... fijate que ambos tienen una marca "/* **** */"

fijate que el dcbw tampoco hace el arreglo del byteorder y tiene la marca /* ****** */... entonces esto deberia funcionar si se compila el dcb en la misma plataforma que se usa...

por ahora el tema creo que no viene por ahi...

[BoMbErLiNk]

Josebita por cierto tienes mal el BAT para convertir ogg y wav masivos :

REM Create the output directory, if it doesn't exist
IF NOT EXIST %OUTWAV%\NUL MD %OUTWAV%
REM Try to recode OGG and transcode MP3 & WMA files
FOR %%i in (*.wav) DO CALL %VLC% %%i --sout=#transcode{vcodec=none,acodec=s16l,ab=%RATE%,channels=%CHANNELS%,samplerate=%FREQ%}:duplicate{dst=std{access=file,mux=wav,dst='%OUTWAV%/%%i'} vlc://quit
IF NOT EXIST %OUTWAV%\NUL (
CD %OUTWAV%
REN *.* *.wav
)

[SplinterGU]

esto necesita mucho mas tiempo de analisis... pero estas estructuras si se guardan/cargan en la misma plataforma no tienen que tener problemas...

sin wii o plataforma con el mismo endian que la wiz... cuesta mucho resolver esto...


EDIT: Estas seguro que esta incluido el "arrange.h" en todos los files donde se usa las funciones de byteorder?

[josebita]

esto necesita mucho mas tiempo de analisis... pero estas estructuras si se guardan/cargan en la misma plataforma no tienen que tener problemas...

sin wii o plataforma con el mismo endian que la wiz... cuesta mucho resolver esto...


EDIT: Estas seguro que esta incluido el "arrange.h" en todos los files donde se usa las funciones de byteorder?

Entiendo que donde dices "wiz" quieres decir "wii", ¿verdad?. Pero vamos, la wiz en ppio. debería poder funcionar en modo bigendian tb, ¿no?. ¿No podrías forzar la compilación en modo bigendian y ejecutarlo ahí?

En cuanto al problema en sí, el fichero dcbw.c guarda count teniendo en cuenta endianess, si no me equivoco. Mira las líneas 147 y 158. No conozco a fondo el funcionamiento de este código (es decir, no estoy seguro de si esas líneas aplican a nuestro caso o no) pero yo diría que ahí las variables se swappean y luego al leer en dcbr.c no se tiene en cuenta endianess.

[SplinterGU]

si, wii...

no puedo forzar la wiz... eso se hace switcheando el modo de procesador... todo esta swapeado, solo no se swapean las globals y las locals... ni en la escritura ni en la lectura...

ademas, esos son las definiciones de tipos... y su homologa en el read es read_and_arrange_varspace...

[josebita]

Con respecto al tema del Wiimote:
Las lecturas de las aceleraciones son consistentes con las que da el ejemplo de wiibrew de uso del Wiimote.
El WPAD_Z lo he implementado de forma distinta al resto, puede que esa sea la razón por la que no te da lecturas. Eso sí: no te dará lectura si no estás apuntando a la pantalla.

[josebita]

[...]
no puedo forzar la wiz... eso se hace switcheando el modo de procesador... todo esta swapeado, solo no se swapean las globals y las locals... ni en la escritura ni en la lectura...

ademas, esos son las definiciones de tipos... y su homologa en el read es read_and_arrange_varspace...

Necesariamente ha de swappearse la variable count en algún momento (ya sea compilador o intérprete) porque el código tal y como está ahora no funciona en la Wii y yo diría que no se me ha olvidado ningún "arrange.h". El código que hace eso está inmaculado con respecto a la versión oficial.

PD: He probado un ejemplo simple de save y load y parece funcionar correctamente con los últimos binarios que he subido.

[SplinterGU]

seguramente algo se esta escapando, pero es dificil verlo...