[GC / Wii] Desarollo, Info y Dudas..

¿Aquí tratamos el modo GC o también el Twilight?

Si es así, me gustaría ver una miniguía de qué librerías y tal hay para hacer un pequeño programilla y compilarlo, que igual me da por remakear un Asteroids que hice en su día

Me parece muy buena iniciativa.

Hola
De momento todo va en modo GC porque poco o nada se ha comentado de como hacer uso del exploit del TP pero en cuanto tenga algo en claro lo pondre aqui ademas de poco a poco ir añadiendo nuevo contenido, mini-guias etc para programar para GC/Wii y claro esta, toda ayuda sera agradecida que casi parezco un bicho raro por empeñarme en programar para Wii

una dudilla, como se añaden librerias al devkitPro?

es decir, que tendria que hacer para poder usar las iostream aqui? porque llevo ya rato probando y nose que hacer, ni de donde bajarlas ni nada...

Suelto la propuesta a ver qué os parece:

Como wikipedista aficionado y persona que empezó a programar cosillas aprendiendo de los tutoriales de asphyxia he pensado que se podrían colocar códigos a modo de tutorial como aquellos.
La plantilla habría de ser algo como esto. Empezando con una descripción de lo que se pretende conseguir, después el código y dejar un apartado más para apuntes y comentarios sobre detalles relevantes.

Los Asphyxia VGA demo trainers venían con txt explicativo con la teoría y unos códigos fuentes petados de comentarios.
Pienso que al menos la gente que se encuentre con el código por primera vez ya puede decir "esto vale para hacer esto", a partir de ahí que empiecen a preguntarse qué es un puntero o un array. En cierta forma es empezar a construir la casa por el tejado, pero si los nuevos interesados en la materia van viendo que compilando esos códigos castellanizados se van obteniendo resultados es muy probable que se animen a saber más.

Ahí lo dejo. Yo sólo no podría ponerme a hacer de instructor porque tengo bastante atrofiado el C, si a alguien le parece bien y se apunta yo me implico en lo que haga falta

Una cosa, esto va mejor en scene de wii, porque si te lees las normas de este foro, aqui no se viene a aprender (leelas si eso), por lo que se intuye que tutos no. Lo digo porque me paso algo parecido con los tutos de programacion en nds, los tuve que mover a scene de nds.

Salu2

Hombre, dado que este hilo va sobre programacion/desarrollo para las plataformas de Nintendo, esta en el foro correcto ademas de que en este mismo post podra todo quien este desarrollando algo para alguno de estos sistemas poner capturas, info, codigo y en general lo que quiera...vamos, que es como el hilo de todo lo poco que se hace relacionado con estos sistemas ya que hay muchos hilos de psp con manuales (por los que doy las gracias porque me los ley y son muy interesantes), otros muchos de dudas etc y no se los manda para la scene de cada uno puesto que este es el foro adecuado para el tema de la programacion. O por lo menos eso es lo que creo yo

Yo tengo una duda sobre la librería. Con la extensa documentación que tiene, no sé cuáles son las funciones gráficas. ¿Podríais darme las básicas? (Dibujar cuadrados, círculos, etc)

Supongo que será algo así, pero no estoy seguro

circle (x,y,radio,makecol(r,g,b));

Pero es más fácil preguntar xD

Y otra cosa. La resolución en pantalla es de 640x480, ¿no?

En cuanto a la resolucion solo he conseguido sacar esa y la verdad.... pero bueno, digamos que no es lo que me preocupa. Y en lo relacionado con las librerias graficas...pues de momento me sigo matando con los tiles pero como me ponga de mala leche me voy a ir directo a mirar las librerias e ir mirando a ver que leches tienen y si eso ya comentare.

PD: Y durante esta semana no creo que me ponga con el tema de GC/Wii porque me ha dado por una frikadita xD y es que ando programando para NES y nunca habia tocado ensamblador pero bueno, ya lo llevo bastante bien

Yo tengo una pregunta;

¿ Cómo puedo poner imagenes (sea en BMP o otro formato) en un archivo ?

Es mi unica duda, a ver si lo sabeis.

Un saludo !

Hola [chiu]

Ante todo, por mi puedes poner todas las dudas que quieras y te ayudare en todo cuanto pueda por lo que no te cortes y asi de paso igual se ayuda a otros que tenga la misma duda y decir que me alegra el ver que alguien mas se preocupa por este sistema.

Pues es mas facil de lo que parece, en lo referente a tu pregunta me refiero, el cargar una imagen y es gracias a un herramienta/mini_aplicacion que se llama "gfx2gc.exe" y que es muy sencilla de usar y facilita todo muy mucho.

Ahi van unas capturas para que quede todo mas bonito y didactico xD..
1º Primero lo mejor es meter todas las imagenes en una carpeta aparte en vez de ponerlas junto con el codigo todo ahi juntito y bien revuelto XD y yo siempre suelo hacer uso de una carpeta a la que llamo "gfx".

2º En ella tienes que meter dos cosas, las imagenes o la imagen en este caso para empezar y la mini_aplicacion ya nombrada ( y el tercer archivo es el que vamos a crear y el que se usara luego en el codigo/juego ).



3º Y despues tienes que crear un archivo *.bat mas que nada para facilitarte mucho la vida y es que sino tendras que andar tirando de consola de sistema y estar escribiendo lo mismo mil veces mientras que de esta manera con tan solo clickar, listo ;)

Este archivo bat yo lo suelo dejar en donde el codigo, manias vamos, pero tu lo podrias poner en la misma carpeta gfx y el codigo solo variaria en una chorradita.


* De optar por meter el bat en gfx pues tendrias que dejar unicamente la linea del centro :P
** Y en realidad, dado que dudo que lo ejecutes desde la linea de comandos, lo de "cd.." te da un poco igual [+risas]

4º En si lo que hace la herramienta esta es lo siguiente..

* Puedes convertir imagenes de incluso 24bits pero siempre han de ser en formato BMP.

Y al ejecutar el bat se realiza lo siguiente aunque no se vea..

* Advertencia: Las dimensiones si no recuerdo mal, han de ser siempre en multiplos de dos [risita]

5º Por ultima ya solo queda cargar el grafico en el codigo.
Pues es tan facil como en la parte inicial de codigo, donde se añaden todas las librerias que se vayan a linkar, definiciones globales etc.. poner -> #include ".\gfx\sprite.raw.c" (siendo "sprite" el nombre de tu imagen)

Seguido has de poner dos cosas importantes..
El color que va a hacer las veces de transparente para que tu sprite quede bien y no como una pegatina xD -> #define COLOR_TRANSPARENT COLOR_WHITE
* Y COLOR_WHITE viene ya declarado en las propias librerias al igual que otros colores pero ahora no me acuerdo cuales eran todos...tambien puedes poner el codigo del color en hexadecimal si no recuerdo mal.

Y el numero de frames que tiene el grafico que has cargado porque al igual que puede ser un fondo en que toda la imagen sea el grafico a cargar, puede ser la animacion de tu personaje para atacar que este compuesta por cuatro frames quedando la cosa asi -> #define NUM_FRAMES 0x4

Despues tienes que definir una estructura para controlar los diferentes aspectos de tu grafico cargado.

Y ahora viene lo mas "raspao" pero que en el fondo, con ponerlo la primera vez ya te servira para todo el resto de graficos del programa y con ello me refiero a la funcion de pintar los graficos en pantalla.
Por decirlo facil... en todo sitio donde ponga "sprite" en esta funcion tendrias que poner el nombre de tu imagen y pista... por lo que lo mejor seria hacer que esta funcion recibiese una cadena de caracteres que vendria a ser el nombre del grafico a usar y asi se podria usar la misma funcion para cualquier grafico.
* Editado: Uisss que me he colado xD y es que no es que tengas que poner el nombre de la imagen sino mas bien, el nombre que hayas dado a la variable de la estructura creada al inicio [ok] que en este caso es igual al nombre de la imagen.

Programa completo de ejemplo de como cargar un sprite -> Link
Mini aplicacion Gfx2gx -> Link

Ciao que ya hay sueño y espero te sirva de ayuda.

Esta tarde probaré, tengo un par de dudas más...

¿ Donde consigo el devkitcube ? Tengo el devkitPro (para PAlib; progrmación para NDS) y devkitPPC (para Wii) pero no sabía de la existencia de este, a ver si me ayudas.

Y otra cosa; ¿ la imagen puede tener el tamaño y peso (KB) que a mi me de la gana o hay límites ?

Nada más, gracias por la genial explicación.

EDITO: Otra cosa, el ultimo codigo tendría que copiarlo tal cual ?

Un saludo !

PiratePila escribió:¿ Donde consigo el devkitcube ?

En la seccion Links de Interes tienes un link a otro hilo mio ( SCENE GC: homebrew, media, modchips... ) y ahi tienes una link a una descarga directa

PiratePila escribió:Y otra cosa; ¿ la imagen puede tener el tamaño y peso (KB) que a mi me de la gana o hay límites ?

Si, puedes cargar desde un minisprite para hacer particulas o algo muy peque, hasta fondos para un scroll, solo que como he comentado creo recordar que siempre han de ser sus medidas en multiplos de 2.

PiratePila escribió:EDITO: Otra cosa, el ultimo codigo tendría que copiarlo tal cual ?

Si y si miras al final de la explicacion tienes un link para descargarte un ejemplo con todo lo comentado en la explicacion.

Ok. De momento nada más, gracias por todo.

De nada y he actualizado el hilo principal ...a ver si este finde tengo tiempo para ponerme a saco con estas librerias que las voy a mirar de arriba a abajo.

Por cierto no veo el enlace para bajar el devkitcube solo veo el devkitPro, y ese ya lo tengo instalado.

Es que estas mirando en este hilo pero donde tienes que mirar es en este otro hilo

Vale ya tengo el devkitcube.

El problema ahora es que lo que yo busco (el programa de las imagenes) no viene ahí.

En el mensaje de la explicacion he añadido la descarga del programa ejemplo y de la herramienta

Una pregunta, que estoy ayudando a PiratePila. ¿Como puedo hacer que se vea la consola de texto y la imagen? Gracias.

No termino de entender bien tu pregunta la verdad...por lo que te pido que me la expliques mejor y perdona

Creo que se refiere a que se muestre en pantalla texto e imagenes a la vez.

PiratePila escribió:Creo que se refiere a que se muestre en pantalla texto e imagenes a la vez.

Eso.

Pues el texto la verdad que no he cargado nunca pero se puede hacer desde por sprites como las imagenes a por "consola" como comenta tu amigo y supongo que no sera sino printf o algo asi y enlazando la libreria que sea necesaria.

El problema es que no podemos sustituir el texto por imagenes ya que lee información desde una parte externa a la consola (llamalo tarjeta ) y no damos con la solución a que nos muestre texto e imagen a la vez.

A ver si tu sabes algo, voy a mirar a ver si encuentro la manera de solucionarlo.

Un saludo !

Ok, ya entiendo... pues si, lo que tendriais que hacer es leer dicho texto y pasarlo mediante un array de caracteres por ejemplo, a una funcion que lo escriba en pantalla y me juego el cuello a que seria mediante printf

Ya funciona, ibamos mal encaminados lo que estaba mal era la altura y anchura de la imagen por eso parecia que no mostraba nada. Todo perfecto por ahora entonces. Gracias por la ayuda.

Entonces al final era simplemente coger el texto y presentar en pantalla de la forma habitual no? pues mira, una cosa que no he probado pero gracias a vosotros se que funciona sin problems

Sí, todo igual lo unico que en anchura y altura la imagen tenía 100x100 y tenía que ser 400x200 (errores de novato ).

Por cierto, una pregunta, ¿ sabes cual es el tamaño maximo ?

Es que intento insertar una imagen de 600x600 y al compilar me da error en el BlitScreen...

Hombre...supongo que igual pasa eso dado que estas intentando meter con calzador una imagen superior a la superficie disponible ( la GC trabaja a 640x480 creo recordar ) aunque me suena raro dado que el propio compilador creo que recortaria la imagen...prueba a poner una con las medidas que te comento y despues otra con 640x490 por ejemplo, a ver que pasa

PD: Y mas que nadas vas a tener un problema y es que como no hagas uso de tiles, el framerate se va a resentir cosa mala porque se habra de refrescar todo en todo momento

Hola, ¿podriais ayudarme con el ejemplo de las imagenes que está puesto al pruncipio de hilo?

Si intento compilar el archivo que has puesto, me da un error de compilación, así que he copiado las funciones y el código en un template que tengo hecho para programar en wii. Si hago esto lo compila, pero en la wii se ve todo negro, no muestra ninguna imagen (y he hecho todos los pasos para convertir la imagen).

Pongo el código de la función main por si veis el error:


El resto fuera del main lo he dejado igual. Habreis notado que he eliminado la función para el controlador de GC, pero es que no quiero usarlo en este caso, solo quiero que muestre una imagen.

Gracias y saludos!

Una duda que es un u32?

Unsigned int 32 bits.
Es decir, entero sin signo de 32bits (4 bytes).
Valor máximo (2^32) -1 (mínimo 0).

¿Ninguno sabe porque no se pintan las imagenes en pantalla con el código que he puesto? ¿Que es lo que hace mal ese código?

Gracias!

a mi me pasa lo mismo...

Yo como curiosete andaba mirando unos enlaces para en un futuro portar el Pituka a la Wii y me encontré estos ejemplos, no se si os valdrán o los habéis visto ya, pero aquí los dejo:

http://tehwii.tehskeen.com/tehwii/examples.php

[UPDATE]
En lugar de usar un gráfico insertado en el src podéis probar con las nuevas libjpeg que han preparado aquí:
http://www.tehskeen.com/forums/showthread.php?t=6634

Un Saludo!

Gracias D_Skywalk, esta tarde probaré a ver si lo consigo con esas librerias y ejemplos que has puesto.

saludos!

Tengo una duda, me da que un poco tonta.

Tenía instalado el devkitpro de cuando miraba cosas para NDS, así que he ejecutado la herramienta de actualización y lo he puesto a la última. Supongo que estará bien porque en la carpeta libogc me sale una subcarpeta lib/wii.

La pega es que el archivo make.bat de tu ejemplo del sprite llama a algunos ejecutables que no tengo en mi instalación, como bin2dol y powerpc-eabi-elf-gcc. ¿Es que hay que instalar algo además de la última versión del devkitpro? He mirado también en devkitppc/bin y no están.

He usado muchos compiladores a lo largo de mi vida, con mayor o menor éxito, pero eso de que falten ejecutables no se como resolverlo...

¿Se podría poner una miniguía donde se explique como escribir y compilar un hello world desde cero?

Muchas gracias.


PD: Enhorabuena por el hilo KFR.

frontier eso es porque el ejemplo hace uso del compilador devkitcube que ya he comentado en el mensaje principal del post que lleva mucho mucho sin actualizarse y no tiene pinta de hacerlo nunca mas pero en si lo que tienes que hacer es usar ese mismo codigo pero compilandolo con el make que trae el propio devkitpo ya creado en la seccion/carpeta examples o ejemplos o como ponga, entras en Gamecube o Wii y tienes una plantilla de proyecto con su make y el programmer's notepad ya configurado para darle a Make y pista

Ostia que fallo más tonto.

Muchas gracias, siento haberte hecho perder el tiempo.

KFR escribió:frontier eso es porque el ejemplo hace uso del compilador devkitcube que ya he comentado en el mensaje principal del post que lleva mucho mucho sin actualizarse y no tiene pinta de hacerlo nunca mas pero en si lo que tienes que hacer es usar ese mismo codigo pero compilandolo con el make que trae el propio devkitpo ya creado en la seccion/carpeta examples o ejemplos o como ponga, entras en Gamecube o Wii y tienes una plantilla de proyecto con su make y el programmer's notepad ya configurado para darle a Make y pista

Pues yo no consigo compilar ese código y que funcione. No me muestra la imagen en la Wii.

Tambien lo he intentado haciendo uso de la libreria libjpeg para wii que sacaron hace poco, pero el ejemplo que hay en el wiki de EOL está también mal. Hay algunos errores en el nombre de algunas variables, y despues de arreglar eso, da el siguiente error compilando:



Llevo dos dias intentando cargar una imagen en wii y no puedo

No te partas mucho la cabeza JumpingJack. Para que ese código compilase habría que cambiar un montón de cosas.

He estado trasteando y la manera de acceder al pad y a la pantalla varía entre el devkitpro y el devkitcube. Hay que cambiar tantas cosas que creo que es mejor tirar el ejemplo y elegir otro.

Hay uno perfecto en el devkitpro en la carpeta "devkitPro\examples\gamecube\graphics\fb\pageflip". Compila a la primera y lo he podido lanzar con el twilight hack sin problemas. Se trata de un cuadrado blanco que rebota por la pantalla sobre un fondo de cuadros azules que también se mueve.

Para compilarlo simplemente abrimos una ventana de comandos, vamos a la carpeta pageflip y desde allí tecleamos "C:\devkitPro\msys\bin\make". Suponiendo que la carpeta del devkitpro sea "c:\devkitpro" claro...

Deberían crearse los archivos pageflip.elf y pageflip.dol. El elf lo renombramos a boot.elf para usarlo con el twilight hack y a tirar millas.

Esta noche cuando tenga más tiempo voy a postear las averiguaciones que he hecho sobre el código del ejemplo, a ver si entre todos nos enteramos bien de lo que hace.


A todo esto... ¿Alguien sabe como podría cargar el ejemplo sin utilizar el twilight hack? Tengo chip, por lo que supongo que se podría grabar en un DVD con alguna herramienta (¿trucha y alguna mas?) para ejecutarlo directamente.

Pregunta tonta y sencillota.

Si yo tuviese un proyecto hecho en SDL, se podría portear a Wii. Sinceramente, es que no se como funciona la Wii internamente en cuanto a graficos, sonido y demás.

Saludos y disculpad si es una pregunta demasiado tonta

Me parece que el linux de GC trae una implementación de las SDL. Al de Wii no se si la han hecho ya...

Yo de tí consultaría con Núvalo que ha portado el MFE a Wii y seguro que de esto entiende.


EDIT: Señores he estado trasteando y después de algunos intentos fallidos he conseguido entender más o menos como poner texto en pantalla y leer los pads de gamecube. Para ello me he basado en el único ejemplo específico de Wii que viene en el devkitpro.

Os adjunto el fuente de un programa que detecta cuando se pulsa el botón A del mando 1 e imprime un mensaje en pantalla. A su vez mientras esté pulsado el botón B imprime los valores de los dos joysticks y de los pulsadores analógicos R y L. También enciende la vibración del mando al pulsar X y la apaga al pulsar Y o Z.

wiisample.zip

Para compilarlo copiais la carpeta "..\devkitPro\examples\wii\template" a alguna otra localización, la renombrais por ejemplo a "wiisample" o lo que querais, borrais el archivo "template.c" y lo sustituís por mi archivo "wiisample.c". Después desde una ventana de comandos entrais en la carpeta que habeis copiado y ejecutais "..\devkitPro\msys\bin\make.exe". Una vez creados el .elf y el .dol los lanzais con vuestro método de carga favorito. Yo he usado el twilight hack.


EXPLICACIÓN DEL CÓDIGO:

#include
#include
#include
#include
#include
#include

Inclusión de librerías estándar de C y las específicas de wii (las dos últimas)

static void *xfb = NULL;
static GXRModeObj *rmode = NULL;

Declaración del puntero que posteriormente se inicializará con la dirección del framebuffer y del puntero que contendrá la estructura que la librería usa para almacenar información sobre el modo de video.

int main(int argc, char **argv) {

VIDEO_Init();
PAD_Init();
PAD_Sync ();

Inicialización del sistema de vídeo y de los pads. Al parecer es muy importante llamar siempre a VIDEO_Init() antes de usar ninguna otra función. La llamada a PAD_Sync() la he añadido yo, aunque no se para que sirve realmente. Tal vez se use para resincronizar los Pads después de que el usuario los desconecte y los vuelva a conectar a la consola. ¿Alguna idea?

switch(VIDEO_GetCurrentTvMode()) {
case VI_NTSC:
rmode = &TVNtsc480IntDf;
break;
case VI_PAL:
rmode = &TVPal528IntDf;
break;
case VI_MPAL:
rmode = &TVMpal480IntDf;
break;
default:
rmode = &TVNtsc480IntDf;
break;
}

Este código comprueba el tipo de TV conectada a la Wii y selecciona un modo de vídeo compatible. Aunque aquí sólo aparecen 3 modos de vídeos la lista es mucho mayor y puede consultarse en el archivo "video_types.h":

extern GXRModeObj TVNtsc240Ds; /*!< Video and render mode configuration for 240 lines,singlefield NTSC mode */
extern GXRModeObj TVNtsc240DsAa; /*!< Video and render mode configuration for 240 lines,singlefield,antialiased NTSC mode */
extern GXRModeObj TVNtsc240Int; /*!< Video and render mode configuration for 240 lines,interlaced NTSC mode */
extern GXRModeObj TVNtsc240IntAa; /*!< Video and render mode configuration for 240 lines,interlaced,antialiased NTSC mode */
extern GXRModeObj TVNtsc480IntDf; /*!< Video and render mode configuration for 480 lines,interlaced,doublefield NTSC mode */
extern GXRModeObj TVNtsc480IntAa; /*!< Video and render mode configuration for 480 lines,interlaced,doublefield,antialiased NTSC mode */
extern GXRModeObj TVNtsc480Prog; /*!< Video and render mode configuration for 480 lines,progressive,singlefield NTSC mode */
extern GXRModeObj TVMpal480IntDf; /*!< Video and render mode configuration for 480 lines,interlaced,doublefield,antialiased PAL mode */
extern GXRModeObj TVPal264Ds; /*!< Video and render mode configuration for 264 lines,singlefield PAL mode */
extern GXRModeObj TVPal264DsAa; /*!< Video and render mode configuration for 264 lines,singlefield,antialiased PAL mode */
extern GXRModeObj TVPal264Int; /*!< Video and render mode configuration for 264 lines,interlaced PAL mode */
extern GXRModeObj TVPal264IntAa; /*!< Video and render mode configuration for 264 lines,interlaced,antialiased PAL mode */
extern GXRModeObj TVPal524IntAa; /*!< Video and render mode configuration for 524 lines,interlaced,antialiased PAL mode */
extern GXRModeObj TVPal528Int; /*!< Video and render mode configuration for 528 lines,interlaced,antialiased PAL mode */
extern GXRModeObj TVPal528IntDf; /*!< Video and render mode configuration for 264 lines,interlaced,doublefield antialiased PAL mode */
extern GXRModeObj TVPal574IntDfScale;

El modo por defecto que la librería escoge para PAL mi TV lo identifica como 480i. De todos esos no se cual será el modo 480p, si es que la librería lo soporta. Por cierto, al parecer MPAL es un sistema de TV que se usa en Brasil nada más. Que exclusivos.

xfb = MEM_K0_TO_K1(SYS_AllocateFramebuffer(rmode));

Aquí se solicita un trozo de memoria lo suficientemente grande como para alojar un frame del modo de vídeo que se ha seleccionado.

console_init(xfb,20,20,rmode->fbWidth,rmode->xfbHeight,rmode->fbWidth*VI_DISPLAY_PIX_SZ);

Función que inicia la consola de texto. Los dos primeros parámetros son las coordenadas X e Y donde comenzará el primer carácter. Los dos siguientes son el ancho y el alto en píxeles de la pantalla. El último es el tamaño en bytes que ocupa en memoria una línea horizontal. No es más que el ancho en píxeles multiplicado por 2. En la estructura GXRModeObj hay varios campos relativos al alto de la pantalla. ¿Alguien tiene idea de en que se diferencian?

VIDEO_Configure(rmode);
VIDEO_SetNextFramebuffer(xfb);
VIDEO_SetBlack(FALSE);
VIDEO_Flush();

Las dos primeras líneas le comunican al hardware que inicie el modo de vídeo seleccionado y que lea los gráficos de la zona de memoria que previamente hemos reservado. La tercera línea por más que lo pienso no se que hace. Creo que la cuarta línea se encarga de hacer efectivos todos los comandos de vídeo anteriores.

VIDEO_WaitVSync();
if(rmode->viTVMode&VI_NON_INTERLACE) VIDEO_WaitVSync();

Estas tres líneas son una incógnita. Supongo que la primera espera hasta que se produce la señal de retrazo vertical, pero ¿Y las otras dos? Por algún motivo si estamos en un modo de vídeo progresivo hay que esperar un segundo retrazo vertical...

printf("Hello World!\n");

El típico hola mundo.

console_setpos(40,120);
console_setcolor(COLOR_RED, COLOR_BLUE);
printf("And Good Bye!\n");

Estas tres líneas son de mi cosecha. La primera establece la posición en la que se imprimirá el siguiente carácter y la segunda indica que se imprimirá en azul sobre fondo rojo. La lista completa de colores predefinidos puede verse en el archivo "ogc\color.h". Finalmente se imprime un mensaje.

while(1) {

VIDEO_WaitVSync();

Inicio del bucle principal del programa. Antes de hacer nada se espera a la señal de retrazo vertica. Supongo que la última línea podría quitarse sin mayores consecuencias.

PAD_ScanPads ();

Lo que viene a partir de aquí hasta el final del programa es de mi cosecha. Esta función hace una lectura asíncrona de los pads y hay que llamarla para que las funciones PAD_* que vienen a continuación no fallen. Devuelve un u32 que no se que rayos contendrá, así que no lo uso.

if (PAD_ButtonsDown(PAD_CHAN0) & PAD_BUTTON_A)
printf("Button A Pressed!\n");

Si se ha pulsado el botón A del mando 1 desde la última llamada a PAD_ScanPads() imprimir un mensaje. Se pueden leer 4 pads, dede PAD_CHAN0 hasta PAD_CHAN3. La lista completa de botones que se pueden leer de cada pad figura en el archivo "ogc\pad.h".

if (PAD_ButtonsHeld(PAD_CHAN0) & PAD_BUTTON_B)
{
printf("Button B Held!\n");
printf("StickX: %d; StickY: %d\n", (s32)PAD_StickX(PAD_CHAN0), (s32)PAD_StickY(PAD_CHAN0));
printf("SubStickX: %d; SubStickY: %d\n", (s32)PAD_SubStickX(PAD_CHAN0), (s32)PAD_SubStickY(PAD_CHAN0));
printf("TriggerL: %u; TriggerR: %u\n", (u32)PAD_TriggerL(PAD_CHAN0), (u32)PAD_TriggerR(PAD_CHAN0));
}

Si se está pulsando el botón B del mando 1 ¿dede la última llamada a PAD_ScanPads()? imprimir un mensaje y la información de las coordenadas del Stick (mando analógico izquierdo), Substick (mando analógico derecho) y pulsadores R y L. Como todos sabreis los pulsadores R y L tienen un recorrido y se puede detectar como de pulsados están. Adicionalmente tienen una pulsación final (se nota un click) que habría que leer de forma análoga a como se leen los botones normales (A, B, X, Y, etc...).

if (PAD_ButtonsDown(PAD_CHAN0) & PAD_BUTTON_X)
PAD_ControlMotor (PAD_CHAN0, PAD_MOTOR_RUMBLE);

if (PAD_ButtonsDown(PAD_CHAN0) & PAD_BUTTON_Y)
PAD_ControlMotor (PAD_CHAN0, PAD_MOTOR_STOP);

if (PAD_ButtonsDown(PAD_CHAN0) & PAD_TRIGGER_Z)
PAD_ControlMotor (PAD_CHAN0, PAD_MOTOR_STOP_HARD);

Si se pulsa X activar el motor del mando. Si se pulsa Y desactivarlo. Si se pulsa Z desactivarlo "a lo bruto". No se en que situaciones conviene desactivarlo con PAD_MOTOR_STOP y cuando debe usarse PAD_MOTOR_STOP_HARD. ¿Alguna sugerencia?

}

return 0;
}

Se acabó lo que se daba.

He probado el programa con un wavebird de Nintendo y con un mando cutre del Game y ha funcionado correctamente con los dos. Tened en cuenta que el wavebird no tiene vibración. También he notado que los dos mandos tienen sus controles analógicos exactamente en el mismo rango: Los pulsadores R y L van de 0 a 150, el stick de -74 a 74 y el substick de -59 a 59. Que bien copian estos del Game...

Si consultais "ogc\pad.h" os dareis cuenta de que hay otras muchas funciones para acceder al pad. Algunas me imagino para que sirven, ya os comentaré cuando las pruebe. Las funciones PAD_SetSpec, PAD_Clamp, PAD_Reset, PAD_Recalibrate y PAD_SetSamplingCallback o no se cuando hay que usarlas o directamente no tengo ni idea de que hacen. Espero que entre todos lo podamos ir averiguando


Saludos.

Hola

He hecho mi primer programa para GC/Wii, el buscaminas.

Quiero compartirlo para que lo probarais y confirmar si funciona o no (solo lo he podido probar en emulador y si que va).

Con la cruceta se selecciona el numero deseado (izquierda y derecha) y con el boton A se confirma. Dada la baja resolucion de pantalla (640x480) elegid un tablero pequeño para que se vea bien (5x5).

Este codigo tendra bastantes cosas mal, es un primer paso, asi que cualquier critica es bien recibida. Una vez que entienda bien el funcionamiento me pondre con graficos, jejeje.

Saludos!!

jomofer escribió:Hola

He hecho mi primer programa para GC/Wii, el buscaminas.

Quiero compartirlo para que lo probarais y confirmar si funciona o no (solo lo he podido probar en emulador y si que va).

Probado en wii con el twilight hack y funciona. Enhorabuena

Algunos comentarios:

- Al compilarlo la primera vez me ha dado un error de una regla que supuestamente hace falta para procesar el archivo "buscaminas.o". Lo he solucionado borrando la carpeta build y volviendo a compilar. Supongo que se deberá a que estamos usando versiones distintas del devkitpro.

- Cuando el número de minas es igual o mayor al de casillas totales creo que el programa peta. Al menos a mi me ha pasado una vez.

-De vez en cuando da una excepción al mirar en una casilla. También me ha pasado una sola vez.

-Te sugiero que uses la instrucción "void console_setpos(int x, int y)" para imprimir los datos de entrada del usuario siempre en la misma posición. Así la pantalla no se desplazará verticalmente y te quedará más profesional. También podrías usar "void console_setcolor(unsigned int bgcolor,unsigned int fgcolor)" para darle un poco de colorido al tablero.

-Creo que te has liado un poco con los bucles del principio. He hecho otra versión del bucle que le pregunta al usuario el número de minas. Creo que es más simple ya que tiene menos instrucciones y te ahorras la variable "flag1":

//do {
printf("Introduce el numero de minas\n");
int /*flag1=0,*/ aux=0, buttonsDown = 0;
printf("\n%d\n",aux);

while(/*flag1==0*/ 1)
{
VIDEO_WaitVSync();
PAD_ScanPads();
buttonsDown = PAD_ButtonsDown(/*0*/ PAD_CHAN0);
if(buttonsDown & PAD_BUTTON_RIGHT)
{
aux++;
printf("%d\n",aux);
}
if(buttonsDown & PAD_BUTTON_LEFT)
{
aux--;
printf("%d\n",aux);
}
//PAD_ScanPads();
//buttonsDown = PAD_ButtonsDown(0);
if(buttonsDown & PAD_BUTTON_A)
{
//flag1=1;
minas = aux;
break;
}
//minas=aux;
}
//}

He comentado las instrucciones innecesarias en vez de borrarlas para que sea más facil ver los cambios.


Gracias a tu demo me he dado cuenta de que no hace falta llamar a PAD_Sync() después de PAD_Init()... ¿Entonces cuando demonios se usa PAD_Sync()?

Saludos.

frontier escribió:Probado en wii con el twilight hack y funciona. Enhorabuena

Algunos comentarios:

- Al compilarlo la primera vez me ha dado un error de una regla que supuestamente hace falta para procesar el archivo "buscaminas.o". Lo he solucionado borrando la carpeta build y volviendo a compilar. Supongo que se deberá a que estamos usando versiones distintas del devkitpro.

- Cuando el número de minas es igual o mayor al de casillas totales creo que el programa peta. Al menos a mi me ha pasado una vez.

-De vez en cuando da una excepción al mirar en una casilla. También me ha pasado una sola vez.

-Te sugiero que uses la instrucción "void console_setpos(int x, int y)" para imprimir los datos de entrada del usuario siempre en la misma posición. Así la pantalla no se desplazará verticalmente y te quedará más profesional. También podrías usar "void console_setcolor(unsigned int bgcolor,unsigned int fgcolor)" para darle un poco de colorido al tablero.

-Creo que te has liado un poco con los bucles del principio. He hecho otra versión del bucle que le pregunta al usuario el número de minas. Creo que es más simple ya que tiene menos instrucciones y te ahorras la variable "flag1":
He comentado las instrucciones innecesarias en vez de borrarlas para que sea más facil ver los cambios.


Gracias a tu demo me he dado cuenta de que no hace falta llamar a PAD_Sync() después de PAD_Init()... ¿Entonces cuando demonios se usa PAD_Sync()?

Saludos.

Muchas gracias por los consejos, de verdad. Intentare "limpiar" el codigo (que me hace falta practicar C, soy aun novato en esto, jejeje).

Lo de PAD_Sync no se tampoco para que es. Habra que seguir haciendo pruebas...

Saludos!!

Edito. ¿Sabeis alguna instruccion que borre la pantalla? Seria algo parecido a la instruccion system("cls") que en el devkitpro no me deja usar...

Para limpiar la pantalla en el ejemplo "sprite" que posteó KFR esta hecho así:

void ClearScreen(int color){ // Clear the screen in a certain color
int x,y;

for(y=0;y<480;y++){
for(x=0;x<320;x++){
fb[x+320*y]=color;
}
}
}

Se supone que "fb" es el puntero a la memoria de video, que en tu demo se llama "xfb". No lo he probado pero apostaría a que funciona.

Otra opción, tal vez más apropiada, es usar la función de libogc

void VIDEO_ClearFrameBuffer(GXRModeObj *rmode,void *fb,u32 color);

Tampoco la he probado aún.

Espero que te sirva. Avísa si fuciona


En otro orden de cosas me gustaría sumarme a la propuesta que ya hizo Plata para mover este hilo a scene de wii o de gc. Es que me da la sensación de que en este subforo no entra ni Dios... Además, existiendo un foro específico para wii (en el que seguro que hay más tránsito) no se que hacemos en "otras consolas".

frontier escribió:Para limpiar la pantalla en el ejemplo "sprite" que posteó KFR esta hecho así:

Se supone que "fb" es el puntero a la memoria de video, que en tu demo se llama "xfb". No lo he probado pero apostaría a que funciona.

Otra opción, tal vez más apropiada, es usar la función de libogc Tampoco la he probado aún.

Espero que te sirva. Avísa si fuciona


En otro orden de cosas me gustaría sumarme a la propuesta que ya hizo Plata para mover este hilo a scene de wii o de gc. Es que me da la sensación de que en este subforo no entra ni Dios... Además, existiendo un foro específico para wii (en el que seguro que hay más tránsito) no se que hacemos en "otras consolas".

Me ha funcionado de maravilla la funcion de libogc.

Ahora tengo un problema en mi programa, pero que ya no tiene que ver con compilar para GameCube. A ver si doy con el fallo que creo que es uno de los que decias antes (en segun que situaciones, introduces unas coordenadas y se cuelga el programa).

Saludos y gracias!!

Por cierto, lo que preguntabas en posts mas arriba (sobre esperar dos veces si la imagen es en modo progresivo) supongo que sera para que el retraso tanto en un modo de video como en otro sean iguales (en progresivo la imagen se refresca por completo a 60Hz mientras que en entrelazado a 30Hz).