Revolution Engine

1, 2, 3, 4, 58
claro, pero como he pedido ase y han puesto ese link al codigo... he dicho eso para que no se piense nadie que estoy trabajando en un cargador de ase, solo es para mis pruebecillas :P Pero si alguien quiere cojer ese codigo y adaptarlo (si hace falta) y probarlo... es bienvenido, todo suma :)
technik escribió:PD: Me vendria bien que alguien me pudiese pasar un modelo en 3ds, sin textura, sin animacion, y sencillito. En unos dias pedire tambien la version animada y al version con textura


Te adjunto la navecilla en 3ds, si necesitas otro tipo de modelo dilo. Ahora ando liaillo asi que puedo dedicarle ratillos y si no es muy complicao os lo puedo hacer casi del tiron.

También voy a poner el modelo en ase, con una textura base sin detalle por si corre prisa.

P.D.- ANIMO ANIMO ANIMO xd

Adjuntos

Gracias amigo, es justo lo que necesito... pero no corre prisa :)
Ya he subido la nueva versión, ahora con acceso al lector SD frontal :-)

La he subido a mi blog, teneis el enlace en el hilo que creé en este mismo subforo para anunciar el port de libpng.

El nuevo conjunto de funciones de ayuda, a las que he llamado PNGU, ha quedado así:

int PNGU_Init ();
void PNGU_Release ();
int PNGU_SelectFileFromBuffer (const char *buffer);
int PNGU_SelectFileFromWiiSD (const char *filename);
int PNGU_GetImageProperties (PNGUPROP *fileproperties);
int PNGU_DecodeToYCbYCr (unsigned int width, unsigned int height, char *buffer, unsigned int stride);
int PNGU_LoadTo4x4RGB24 (unsigned int width, unsigned int height, char *buffer);


A partir de mañana me pondré con la interfaz genérica de acceso a la SD que os comenté antes.


Saludos!
Genial tio, eres un maquina ;) viene algun ejemplillo? voy a hecharle un vistazo y a modificar una demo de las que tengo para que cargue la textura de un png de la sd :)
Viene un ejemplo y también un fichero de texto con indicaciones.

De todas formas si te surge alguna duda aqui estoy ;)


Cuando modifiques la demo sería genial que me pasaras el código fuente para estudiarlo, porque las GX no se ni por donde cogerlas...
He completado el código de Davpk/Ti-Ra-Nog para hacer que cargue desde el Sd frontal un archivo de texto.

El texto está en la carpeta elf y se llama text.txt, he incluido tb un fichero nfo para pruebas, parece que se muestra bien (al renombrarlo claro está)

El programa usa el reset (no tenía ganas de usar el mando de cube xD)

Espero que os sea de utilidad. Ánimo y un saludo. [ginyo]

Adjuntos

¿Alguno habeis tocado el tema del sonido?

¿Hay alguna interfaz para eso en libogc?

¿Cuantos canales se pueden usar simultaneamente?

¿Que frecuencia y resolución tiene cada uno?

¿Hay librerías para reproducir de forma sencilla ficheros .wav o .mp3?


Agradecería cualquier indicación [tadoramo]
frontier escribió:¿Alguno habeis tocado el tema del sonido?

¿Hay alguna interfaz para eso en libogc?

¿Cuantos canales se pueden usar simultaneamente?

¿Que frecuencia y resolución tiene cada uno?

¿Hay librerías para reproducir de forma sencilla ficheros .wav o .mp3?


Agradecería cualquier indicación [tadoramo]
Mira a ver si alguno de los ejemplos de tehwii te puede servir.

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

hay ejemplos para cargar y reproducir OGG, MP3, WAV y MOD
frontier escribió:¿Alguno habeis tocado el tema del sonido?

¿Hay alguna interfaz para eso en libogc?

¿Cuantos canales se pueden usar simultaneamente?

¿Que frecuencia y resolución tiene cada uno?

¿Hay librerías para reproducir de forma sencilla ficheros .wav o .mp3?


Agradecería cualquier indicación [tadoramo]


en libogc hay modplay y mp3player.h, en los ejemplos de
http://tehwii.tehskeen.com/tehwii/examples.php usan librerias externas.
Nose si leen de la sd frontal ni nada de eso, cuando sepas algo no dudes en compartirlo ;)
frontier escribió:Sobre el problema de colores que mencionabais más arriba, ¿Habeis descartado que se deba al formato de palabra de la máquina (endianness)? Supongo que no tendrá nada que ver, pero es lo único que se me ocurre.


Lo acabo de descartar. Haciendo un byteswap extra, los colores se ven peor, y además ahora también falla sin necesidad de activar GL_LIGHTING.

Puesto que he leído que le pasa a más de uno incluso en la Wii, creo que ahora sí que se convierte en un problema "ontopic" ;)

A ver si alguien encuentra algo. De momento, la diferencia entre Wiis que funcionan bien y que no funcionan bien. (50/60 Hz? PAL/NTSC? Composite/Component/RGB? no se me ocurren más cosas...)
A mi me funciona bien en el emulador, pero en la wii original me va exactamente como tu dices.


EDIT:

Me estoy planteando si es buena idea lo de acelerar graficamente TinyGL, yo creo que seria mejor usar directamente GX.

Me lo he estado mirando y es muucho trabajo, mas trabajo que crear el motor en si y un juego que lo use xD Asi que yo por mi parte voto para hacer el engine sobre GX y me pongo a trabajar en esa direccion :)
Alguien sabe como podemos hacer que nuestros programas se adapten a las consolas que estan en panoramico? vendria bastante bien.
oyzzo escribió:Me estoy planteando si es buena idea lo de acelerar graficamente TinyGL, yo creo que seria mejor usar directamente GX.
Ya lo he dicho antes: accelerar la parte 2d de tinyGL es sencillo (el rasterizador de triángulos básicamente) -- sólo reescribiendo partes en assembler puedes ganar un 20%. Accelerar la parte 3d es demasiado complicado y no merece la pena; sale más a cuenta crear una desde 0.
oyzzo escribió:A mi me funciona bien en el emulador, pero en la wii original me va exactamente como tu dices.


EDIT:

Me estoy planteando si es buena idea lo de acelerar graficamente TinyGL, yo creo que seria mejor usar directamente GX.

Me lo he estado mirando y es muucho trabajo, mas trabajo que crear el motor en si y un juego que lo use xD Asi que yo por mi parte voto para hacer el engine sobre GX y me pongo a trabajar en esa direccion :)

A mi me sigue pareciendo importante desarrollar encima de un estándar reconocido. Si hay que hacer una implementación de OGL desde cero más vale hacerla y ahorrarnos trabajar el doble en el futuro.

Además, como premio nos caería un port del Quake II :-P
Pues entonces deberiamos cojer OpenGX y continuar el proyecto... asi tendriamos una gran parte implementada, porque de otra manera lo tenemos que hacer de cero. Acelerar TinyGL con GX es realmente cojer las cabezeras y lo demas programarlo todo desde cero.
El problema es que GX no es un standard, y no es facil de entender la correspondencia de algunas cosas ya que no se corresponden de manera identica a las funciones de oGL...

No es tan duro portar TinyGL, dame un poco mas de tiempo...
Si necesitais un modelo sencillo, o al estilo nintendo 64 os puedo ayudar. [fumando]
Sasker escribió:El problema es que GX no es un standard, y no es facil de entender la correspondencia de algunas cosas ya que no se corresponden de manera identica a las funciones de oGL...

No es tan duro portar TinyGL, dame un poco mas de tiempo...


Claro, tu ves mirandolo y cuando lo veas claro me dices algo :) el problema tambien es que GX no esta documentado y es doble trabajo.
technik, podrias editar el primer post para recopilar todos los fuentes que tenemos, utilidades, etc... pq a veces que tengo que descargar algo desde varios PCs buscar en el hilo es tarea de chinos...
ok, ahora lo edito, a ver si puedo recopilarlo todo, avisadme si me dejo algo ;)

PD: sobre el uso de la SD, en los emuladores y demas hay para hacer savegames, por lo tanto hay soporte para escritura, ¿alguien podria poner un ejemplo de como hacer eso?
Explico porqué digo esto: Es que a la vez que en el cargador de 3ds, estoy trabajando en un editor 3D para la wii, para crear tus modelos en la misma wii, y hace falta un método de guardado, porque por el momento solo puedo hacer pruebas volátiles, y eso es poco productivo.
No tengo codigo delante, pero creo que leer era f_read con un apuntador de archivo de la SD abierto, para escribir f_write... no tiene misterio alguno... los 6 archivos de acceso a SD que rulan llevan las funciones de lectura y escritura.

Un editor 3d en wii? Poco util teniendo max o similares en PC.

Cuando necesitemos modelos mas complejos, para probar ya os pasare coches en alta calidad como turismos o formulas 1 a los que tengo acceso a sus fuentes de mods de GP4 y rFactor.
Es que en los source del ejemplo de la SD, solo vienen 3 funciones declaradas: SD_Init, SD_deinit y SD_Read, por eso lo digo.
Tiny-FatFs Copyright (C) 2007, ChaN [URL=http://elm-chan.org/fsw/ff/00index_e.html]Webpage[/URL]
Fichero tff.h

y estas son las funciones que habria que testear

/*-----------------------------------------------------*/
/* FatFs module application interface                  */

FRESULT f_mount (BYTE, FATFS*);                   /* Mount/Unmount a logical drive */
FRESULT f_open (FIL*, const char*, BYTE);         /* Open or create a file */
FRESULT f_read (FIL*, void*, WORD, WORD*);        /* Read data from a file */
FRESULT f_write (FIL*, const void*, WORD, WORD*); /* Write data to a file */
FRESULT f_lseek (FIL*, DWORD);                    /* Move file pointer of a file object */
FRESULT f_close (FIL*);                           /* Close an open file object */
FRESULT f_opendir (DIR*, const char*);            /* Open an existing directory */
FRESULT f_readdir (DIR*, FILINFO*);               /* Read a directory item */
FRESULT f_stat (const char*, FILINFO*);           /* Get file status */
FRESULT f_getfree (const char*, DWORD*, FATFS**); /* Get number of free clusters on the drive */
FRESULT f_sync (FIL*);                            /* Flush cached data of a writing file */
FRESULT f_unlink (const char*);                   /* Delete an existing file or directory */
FRESULT   f_mkdir (const char*);                    /* Create a new directory */
FRESULT f_chmod (const char*, BYTE, BYTE);        /* Change file/dir attriburte */
FRESULT f_rename (const char*, const char*);      /* Rename/Move a file or directory */


/* User defined function to give a current time to fatfs module */

DWORD get_fattime (void);   /* 31-25: Year(0-127 +1980), 24-21: Month(1-12), 20-16: Day(1-31) */
/* 15-11: Hour(0-23), 10-5: Minute(0-59), 4-0: Second(0-29 *2) */
Todavía no he hecho ninguna prueba de escritura en la SD, me imagino que será igual que leer pero invocando a f_write. De todas formas tengo pensado sacar de aquí a un par de días las 4 o 5 funciones básicas de escritura/lectura que os comenté.

De momento sigo depurando y creando mis rutinas PNGU de manejo de imágenes. He conseguido hacer un par de funciones bastante optimizadas que pasan una imágen a formato 4x4 RGB565 y 4x4 RGBA8. Como ya habreis supuesto sirven para cargar texturas. Si alguien tiene manejo con GX me gustaría que me dijera si, aparte de esos dos formatos, en la práctica se usa alguno más de entre los que soporta Wii (GX_TF_I4, GX_TF_I8, GX_TF_IA4, GX_TF_IA8, GX_TF_RGB5A3, GX_TF_C4, GX_TF_C8, GX_TF_CI4, GX_TF_CMPR).

También creo que sería buena idea que cada uno dijese a lo que se está dedicando, así no tendríamos gente haciendo trabajo repetido. Por supuesto cada uno es libre de decirlo o no...

Saludos!
frontier escribió:Todavía no he hecho ninguna prueba de escritura en la SD, me imagino que será igual que leer pero invocando a f_write. De todas formas tengo pensado sacar de aquí a un par de días las 4 o 5 funciones básicas de escritura/lectura que os comenté.

De momento sigo depurando y creando mis rutinas PNGU de manejo de imágenes. He conseguido hacer un par de funciones bastante optimizadas que pasan una imágen a formato 4x4 RGB565 y 4x4 RGBA8. Como ya habreis supuesto sirven para cargar texturas. Si alguien tiene manejo con GX me gustaría que me dijera si, aparte de esos dos formatos, en la práctica se usa alguno más de entre los que soporta Wii (GX_TF_I4, GX_TF_I8, GX_TF_IA4, GX_TF_IA8, GX_TF_RGB5A3, GX_TF_C4, GX_TF_C8, GX_TF_CI4, GX_TF_CMPR).

También creo que sería buena idea que cada uno dijese a lo que se está dedicando, así no tendríamos gente haciendo trabajo repetido. Por supuesto cada uno es libre de decirlo o no...

Saludos!


Pues las pruebas que yo he hecho con GX siempre he usado RGB 565 y ha ido perfecto, asi que no veo necesario soportar mas formatos.

Yo ahora mismo estoy haciendo pruebas con GX para acabar de aprender como funciona. Lo ultimo que he visto son normales y culling de GX, que en los ejemplos no sale nada de normales y sobre el culling decia que tenia que estar desactivado o se veia mal... pero el culling es necesario para optimizar asi que he visto como funciona y realmente va bien.

Aparte de eso estoy esperando que sasker me diga algo sobre lo de acelerar por hardware TinyGL o hacerlo directamente sobre GX.

Si a alguien le interesa y lo pide puedo ir haciendo unos tutoriales y ejemplos sobre GX al estilo NeHe mientras sasker me dice algo.


EDIT:
estaria bien que technik pusiera en el primer hilo quien esta haciendo que, para tener claro quien colabora y podernos pedir cosas entre nosotros y eso :)
oyzzo escribió:Si a alguien le interesa y lo pide puedo ir haciendo unos tutoriales y ejemplos sobre GX al estilo NeHe mientras sasker me dice algo.

Magnífica idea [plas]
No se si os sirvira de algo, pero asi es como las librerias Grrlib crean un archivo en la tarjeta SD con el contenido del buffer que tiene, vamos que lo usa para hacer una "captura" de la pantalla en un archivo. Muy sencillo la verdad...

void GRRLIB_ScrShot(char* file){
SDCARD_Init();
sd_file *handle;
handle = SDCARD_OpenFile(file, "w");
SDCARD_WriteFile(handle, (u16*)GRRLIB_buffer, 640*480*2);
SDCARD_CloseFile(handle);
}

La llamada a la funcion seria algo asi como esto: (Ojo a la ruta)

GRRLIB_ScrShot("dev0:\\sshot.GRR");

P.D: oyzzo, yo por mi parte agradeceria cualquier tutorial que se hiciera. Estais haciendo un gran trabajo.
Kontakatilu, casualmente he estado viendo esa llamada, y me estoy planteando un par de cosas a partir de ello. Os comento:
Creo que llegados a este punto estaria bien que fijasemos unas bases de trabajo aunque sea temporal para trabajar de forma mas eficiente. Hay un par de tareas por definir. Ante todo creo que tendriamos que decidirnos de una vez por unas librerias en concreto y trabajar todos sobre lo mismo. Para empezar esta obviamente el tema de 3D, que aun hay dudas de si se acabara implementando por GX "a pelo" o por un port de TinyGL a basado en GX para aumentar la compatibilidad. Despues esta el tema de las SD, que son un recurso bastante versatil, y estaria bien que nos decidieramos por usar unas librerias fijas, por que aqui a veces se usa lo que trae GRRLib, otras veces las del ejemplo de carga de texto y otras se usan las de libogc. Yo personalmente optaria por aprender a usar las de libogc, porque probablemente tendran mas soporte en el futuro que las versione de terceros. Tambien esta el tema del control, wiimote y demas, pero eso aun no corre ninguna prisa y es suficiente (creo yo) con usar el mando de GC por ahora. Por último (si no me dejo nada en el tintero) esta por definir la forma en que se usara el engine, que es en si, y como estara enfocado su desarrollo. Ante esta ultima cuestion os cuento un poco lo que yo tengo en mente para que me digais que os parece:
Primero, esto es un motor gráfico, no un motor de gráficos. La diferencia es que este engine no sirve solo para mostrar imagenes (véase el Ogre3D) sino que es para el desarrollo integro de juegos (más al estilo neoaxis). Por tanto en el futuro debera proveer a los usuarios de las herramientas necesarias para poder crear sus juegos totalmente, tanto a nivel gráfico, como de sonido, física, etc.
Segundo, par este proposito el motor deberia incluir editores tanto de personajes como de niveles (ya sean para ordenador como para wii), y es aqui donde personalmente veo gran potencial, porque por ejemplo, un editor de personajes con la capacidad de visualizacion que nos ofrece el head-tracking y las facilidades a nivel de animacion que nos facilita el wiimote (captura de movimientos, etc...) seria una herramienta muy valorada por los desarrolladores. Por supuesto no deberia dejar de mantenerse la compatibilidad con los estándares externos para poder usar igualmente programas de modelado como Max, Blender, etc, editores gráficos como photoshop..y un largo etcétera de herramientas más que útiles.

PD: Si que es una buena idea que la gente diga en que está trabajando para poder mantenernos todos al día (Si quereis yo lo voy poniendo en el primer post) y asi organizarnos mejor.
technik escribió:Kontakatilu, casualmente he estado viendo esa llamada, y me estoy planteando un par de cosas a partir de ello. Os comento:
Creo que llegados a este punto estaria bien que fijasemos unas bases de trabajo aunque sea temporal para trabajar de forma mas eficiente...

...esta el tema de las SD, que son un recurso bastante versatil, y estaria bien que nos decidieramos por usar unas librerias fijas, por que aqui a veces se usa lo que trae GRRLib, otras veces las del ejemplo de carga de texto y otras se usan las de libogc. Yo personalmente optaria por aprender a usar las de libogc, porque probablemente tendran mas soporte en el futuro que las versione de terceros. Tambien esta el tema del control, wiimote y demas, pero eso aun no corre ninguna prisa y es suficiente (creo yo) con usar el mando de GC por ahora.


Hasta donde yo se no hay soporte para el lector frontal en libogc, por eso hay tanto caos con el tema de las SD. Estoy de acuerdo en que cuando lo haya será preferible usarlo en lugar de otras librerías externas. También sigo pensando que la solución pasa por definir nuestra propia interfaz de acceso a la SD, e implementarla temporalmente usando los archivos que rulan por ahí (wiisd). Cuando los desarrolladores de libogc le den soporte tendremos que cambiar nuestra implementación, pero no nuestra interfaz. Así cualquier cosa que hayamos hecho basada en ella seguirá funcionando. Como ya he dicho en un mensaje anterior, dentro de un par de días publicaré una primera versión de esa interfaz y espero que todos colaboreis dando vuestra opinión sobre que funciones sobran o faltan.

En el asunto del wiimote pienso igual que tu. La librería que hay actualmente tiene fallos y el mando de GC funciona bien y hace el apaño, así que no veo donde está la prisa.
Estoy deacuerdo con lo de usar el mando de game cube de momento.
También estoy deacuerdo con lo de usar las librerias wiisd para hacer las funciones de lectura y escritura en la SD y asi podemos ir implementando ya la carga de modelos.
Me parece bien usar el port de libpng con las funciones de soporte pngu que esta creando nuestro compañero frontier para cargar texturas de la SD.

Lo de usar GX o TinyGL depende de lo que diga sasker.
Si en libogc no hay soporte para la SD frontal que es entonces lo de la carpeta libogc/include/sdcard ? [agggtt]
oyzzo escribió:Estoy deacuerdo con lo de usar el mando de game cube de momento.
También estoy deacuerdo con lo de usar las librerias wiisd para hacer las funciones de lectura y escritura en la SD y asi podemos ir implementando ya la carga de modelos.
Me parece bien usar el port de libpng con las funciones de soporte pngu que esta creando nuestro compañero frontier para cargar texturas de la SD.

Lo de usar GX o TinyGL depende de lo que diga sasker.


TinyGL.

Yo me encargo que en el futuro, TinyGL internamente convierta las llamadas en GX y por lo tanto sea acelerado por hardware.
Ademas, el global de nuestro motor, para usarlo en otras cosas, usaria estandard openGL (tinyGL) y seria muchisimo mas facil de usar para la gente...

frontier escribió:Todavía no he hecho ninguna prueba de escritura en la SD, me imagino que será igual que leer pero invocando a f_write. De todas formas tengo pensado sacar de aquí a un par de días las 4 o 5 funciones básicas de escritura/lectura que os comenté. De momento sigo depurando y creando mis rutinas PNGU de manejo de imágenes. He conseguido hacer un par de funciones bastante optimizadas que pasan una imágen a formato 4x4 RGB565 y 4x4 RGBA8. Como ya habreis supuesto sirven para cargar texturas. Si alguien tiene manejo con GX me gustaría que me dijera si, aparte de esos dos formatos, en la práctica se usa alguno más de entre los que soporta Wii (GX_TF_I4, GX_TF_I8, GX_TF_IA4, GX_TF_IA8, GX_TF_RGB5A3, GX_TF_C4, GX_TF_C8, GX_TF_CI4, GX_TF_CMPR). También creo que sería buena idea que cada uno dijese a lo que se está dedicando, así no tendríamos gente haciendo trabajo repetido. Por supuesto cada uno es libre de decirlo o no... Saludos!


Ya le dare un ojo cuando lo publiques a la optimizacion de rutinas, pues es mi especialidad ;).
De momento me centrare en GX, y no conozco lo suficiente el assembler de Wii (PowerPC) para optimizar en ensamblador diversas rutinas de copia de datos.


Frontier, supongo que acabaras dedicandote tu por similitud de los proyectos que vas haciendo, necesitamos un interfaz de pintura 2D, para modificar texturas en tiempo real o para crearlas dinamicamente, en caso que sea necesario cambiar cosas o escribir en pantalla. Algo como la GRRLIB pero bien programado.
Si como veo, ya almacenas todo en 4x4, las funciones de pintura seran mas complejas, pq tendran que decodificar los pixels para pintar bien en el 4x4...
Sasker, si tu dices que te encargas de acelerar TinyGL, yo me encargo de usarlo jeje.
Por el momento he dejado un poco de lado el cargador de modelos desde la SD hasta que vea que es todo un poco mas estable y tengamos claro un standar con el que trabajar. Sigo esperando que alguien confirme si el libogc/include/sdcardn permite realmente utilizar la SD frontal, en cuyo caso creo que esta seria la mejor opcion.
Mientras tanto estoy trabajando en la estructura del motor en si, que de momento adelanto que se compondra de un editor de niveles (quiza tenga version wii y version PC), un visualizador (quiza tambien editor) de modelos y personajes (si, hay diferencia, no son lo mismo) y me estoy planteando añadirle una especie de compilador sin escribir codigo. Intentare implementar mi sistema de head-tracking (rudimentario por ahra) a todas las partes del motor. En el editor de niveles habra una forma de previsualizacion para poder jugarlos y testearlos con facilidad. Esta es la idea basica, un poco al estilo del GameStudio de conitec.
technik escribió:Sasker, si tu dices que te encargas de acelerar TinyGL, yo me encargo de usarlo jeje.
Por el momento he dejado un poco de lado el cargador de modelos desde la SD hasta que vea que es todo un poco mas estable y tengamos claro un standar con el que trabajar. Sigo esperando que alguien confirme si el libogc/include/sdcardn permite realmente utilizar la SD frontal, en cuyo caso creo que esta seria la mejor opcion.


No, creo que esos includes son de la SDGecko...
Para SD Frontal se usan los WiiSD (como los llamaron en snes9x).
Efectivamente, libogc/include/sdcard sólo da acceso al SDGecko. :(


Necesito vuestra ayuda con un tema que me está volviendo loco. Como os dije he terminado las dos rutinas que pasan las imágenes de RGB8 a 4x4 RGB565 y 4x4 RGBA8 respectivamente. Lo siguiente que quiero hacer es modificar el ejemplo de libogc "texturetest" para que en lugar de incluir la textura ya convertida en el mismo ejecutable la cargue desde un fichero y la convierta sobre la marcha.

El problema es que "alguien" está escribiendo datos en la memoria que reservo para descomprimir las texturas, de modo que me salen corruptas en algunos puntos. He hecho mil pruebas y nada más terminar mi función de descodificación las imágenes están correctas. Para colmo, durante la ejecución del programa, la primera vez que pulso cualquier botón del pad se corrompen algunos píxeles de una de las texturas, siempre los mismos.

Estoy reservando la memoria para los búferes así:
// Textura de 100x100, a descomprimir en RGBA8
texture_data1 = MEM_K0_TO_K1(memalign (32, imgProp1.imgWidth*imgProp1.imgHeight*4));

// Textura de 100x100, a descomprimir en RGB565
texture_data2 = MEM_K0_TO_K1(memalign (32, imgProp2.imgWidth*imgProp2.imgHeight*2));


Lo he comprobado y tanto imgProp1 como imgProp2 están correctamente inicializados y contienen los valores correctos para el ancho y el alto. También he comprobado empíricamente que si no uso MEM_K0_TO_K1 la GPU no puede acceder a la memoria, supongo que será porque sólo tiene acceso a la zona no cacheable.

Otra prueba que he hecho es sustituir las llamadas a mis funciones de descodificación por llamadas memset para llenar los búferes con el valor 0xFF, lo que produciría dos texturas blancas. El resultado final no varía, las texturas salen corruptas en los mismos puntos :-(

Parece como si alguien estuviera gestionando la memoria por su cuenta a espaldas de memalign o como si memalign me asignase memoria de una zona ya usada... ¿la pila tal vez?

Supongo que será algo muy obvio que me estoy saltando, os dejo el código a ver si detectais que es lo que hago mal:
#include
#include
#include
#include
#include
#include "libpng/pngu/pngu.h"
#include "logo.h"

#define DEFAULT_FIFO_SIZE (256*1024)

typedef struct tagcamera {
Vector pos;
Vector up;
Vector view;
}camera;

s16 squares[] ATTRIBUTE_ALIGN(32) =
{
// x y z
-90, 30, 0, // 0
-30, 30, 0, // 1
-30, -30, 0, // 2
-90, -30, 0, // 3
30, 30, 0, // 0
90, 30, 0, // 1
90, -30, 0, // 2
30, -30, 0, // 3
};

// color data
u8 colors[] ATTRIBUTE_ALIGN(32) = {
// r, g, b, a
0, 255, 0, 0, // 0 purple
240, 0, 0, 255, // 1 red
255, 180, 0, 255, // 2 orange
255, 255, 0, 255, // 3 yellow
10, 120, 40, 255, // 4 green
0, 20, 100, 255 // 5 blue
};


static float rotby=0;
static void *xfb = NULL;
static u32 do_copy = GX_FALSE;
GXRModeObj *rmode;
GXTexObj texObj1;
GXTexObj texObj2;
camera cam = {{0.0F, 0.0F, 0.0F},
{0.0F, 1.0F, 0.0F},
{0.0F, 0.0F, -1.0F}};

void draw_init();
void draw_vert(u8 pos, u8 c, f32 s, f32 t);
void draw_square1(Mtx v);
void draw_square2(Mtx v);
static void copy_to_xfb(u32 count);
void movecamera(float speed);

void *texture_data1 = NULL;
void *texture_data2 = NULL;
PNGUPROP imgProp1;
PNGUPROP imgProp2;


int main() {
Mtx v,p; // view and perspective matrices
GXColor background = {0, 0, 0, 0xff};

VIDEO_Init();

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;
}

PAD_Init();
xfb = MEM_K0_TO_K1(SYS_AllocateFramebuffer(rmode));

VIDEO_Configure(rmode);
VIDEO_SetNextFramebuffer(xfb);
VIDEO_SetPostRetraceCallback(copy_to_xfb);
VIDEO_SetBlack(FALSE);
VIDEO_Flush();
VIDEO_WaitVSync();
if(rmode->viTVMode&VI_NON_INTERLACE) VIDEO_WaitVSync();

void *gp_fifo = NULL;
gp_fifo = MEM_K0_TO_K1(memalign(32,DEFAULT_FIFO_SIZE));
memset(gp_fifo,0,DEFAULT_FIFO_SIZE);

GX_Init(gp_fifo,DEFAULT_FIFO_SIZE);

GX_SetCopyClear(background, 0x00ffffff);

GX_SetViewport(0,0,rmode->fbWidth,rmode->efbHeight,0,1);
GX_SetDispCopyYScale((f32)rmode->xfbHeight/(f32)rmode->efbHeight);
GX_SetScissor(0,0,rmode->fbWidth,rmode->efbHeight);
GX_SetDispCopySrc(0,0,rmode->fbWidth,rmode->efbHeight);
GX_SetDispCopyDst(rmode->fbWidth,rmode->xfbHeight);
GX_SetCopyFilter(rmode->aa,rmode->sample_pattern,GX_TRUE,rmode->vfilter);
GX_SetFieldMode(rmode->field_rendering,((rmode->viHeight==2*rmode->xfbHeight)?GX_ENABLE:GX_DISABLE));

if (rmode->aa)
GX_SetPixelFmt(GX_PF_RGB565_Z16, GX_ZC_LINEAR);
else
GX_SetPixelFmt(GX_PF_RGB8_Z24, GX_ZC_LINEAR);

GX_SetCullMode(GX_CULL_NONE);
GX_CopyDisp(xfb,GX_TRUE);
GX_SetDispCopyGamma(GX_GM_1_0);

guPerspective(p, 60, 1.33F, 10.0F, 1000.0F);
GX_LoadProjectionMtx(p, GX_PERSPECTIVE);

// Load image data
PNGU_Init ();
//PNGU_SelectFileFromWiiSD ("logo.png");
PNGU_SelectFileFromBuffer (logo);
PNGU_GetImageProperties (&imgProp1);
texture_data1 = MEM_K0_TO_K1(memalign (32, imgProp1.imgWidth*imgProp1.imgHeight*4));
PNGU_DecodeTo4x4RGBA8 (imgProp1.imgWidth, imgProp1.imgHeight, texture_data1, 0xFF);
//PNGU_SelectFileFromWiiSD ("logo.png");
PNGU_SelectFileFromBuffer (logo);
PNGU_GetImageProperties (&imgProp2);
texture_data2 = MEM_K0_TO_K1(memalign (32, imgProp2.imgWidth*imgProp2.imgHeight*2));
PNGU_DecodeTo4x4RGB565 (imgProp2.imgWidth, imgProp2.imgHeight, texture_data2);
PNGU_Release ();

draw_init();

while(1)
{
guLookAt(v, &cam.pos, &cam.up, &cam.view);

GX_SetViewport(0,0,rmode->fbWidth,rmode->efbHeight,0,1);
GX_InvVtxCache();
GX_InvalidateTexAll();
GX_SetTevOp(GX_TEVSTAGE0, GX_DECAL);
GX_SetTevOrder(GX_TEVSTAGE0, GX_TEXCOORD0, GX_TEXMAP0, GX_COLOR0A0);

GX_SetNumChans(1);

GX_LoadTexObj(&texObj1, GX_TEXMAP0);
draw_square1(v);

GX_LoadTexObj(&texObj2, GX_TEXMAP0);
draw_square2(v);

GX_DrawDone();
do_copy = GX_TRUE;
VIDEO_WaitVSync();

PAD_ScanPads();

int stickY = PAD_StickY(0);

if( stickY > 18 || stickY < -18)
movecamera((float) stickY/-18);

if(PAD_ButtonsDown(0) & PAD_BUTTON_START) {
void (*reload)() = (void(*)())0x80001800;
reload();
}
}
return 0;
}


void draw_init() {
GX_ClearVtxDesc();
GX_SetVtxDesc(GX_VA_POS, GX_INDEX8);
GX_SetVtxDesc(GX_VA_CLR0, GX_INDEX8);
GX_SetVtxDesc(GX_VA_TEX0, GX_DIRECT);

GX_SetVtxAttrFmt(GX_VTXFMT0, GX_VA_POS, GX_POS_XYZ, GX_S16, 0);
GX_SetVtxAttrFmt(GX_VTXFMT0, GX_VA_CLR0, GX_CLR_RGBA, GX_RGBA8, 0);
GX_SetVtxAttrFmt(GX_VTXFMT0, GX_VA_TEX0, GX_TEX_ST, GX_F32, 0);

GX_SetArray(GX_VA_POS, squares, 3*sizeof(s16));
GX_SetArray(GX_VA_CLR0, colors, 4*sizeof(u8));

GX_SetNumTexGens(1);
GX_SetTexCoordGen(GX_TEXCOORD0, GX_TG_MTX2x4, GX_TG_TEX0, GX_IDENTITY);

GX_InvalidateTexAll();
GX_InitTexObj(&texObj1, texture_data1, imgProp1.imgWidth, imgProp1.imgHeight, GX_TF_RGBA8, GX_CLAMP, GX_CLAMP, GX_FALSE);
GX_InitTexObj(&texObj2, texture_data2, imgProp2.imgWidth, imgProp2.imgHeight, GX_TF_RGB565, GX_CLAMP, GX_CLAMP, GX_FALSE);
}

void draw_vert(u8 pos, u8 c, f32 s, f32 t)
{
GX_Position1x8(pos);
GX_Color1x8(c);
GX_TexCoord2f32(s, t);
}

void draw_square1(Mtx v) {
Mtx m; // model matrix.
Mtx mv; // modelview matrix.
Vector axis = {0,0,1};

guMtxIdentity(m);
guMtxRotAxisDeg(m, &axis, rotby);
guMtxTransApply(m, m, 0, 0, -100);

guMtxConcat(v,m,mv);
GX_LoadPosMtxImm(mv, GX_PNMTX0);


GX_Begin(GX_QUADS, GX_VTXFMT0, 4);
draw_vert(0, 0, 0.0, 0.0);
draw_vert(1, 0, 1.0, 0.0);
draw_vert(2, 0, 1.0, 1.0);
draw_vert(3, 0, 0.0, 1.0);
GX_End();
}

void draw_square2(Mtx v) {
Mtx m; // model matrix.
Mtx mv; // modelview matrix.
Vector axis = {0,0,1};

guMtxIdentity(m);
guMtxRotAxisDeg(m, &axis, rotby);
guMtxTransApply(m, m, 0, 0, -100);

guMtxConcat(v,m,mv);
GX_LoadPosMtxImm(mv, GX_PNMTX0);

GX_Begin(GX_QUADS, GX_VTXFMT0, 4);
draw_vert(4, 0, 0.0, 0.0);
draw_vert(5, 0, 1.0, 0.0);
draw_vert(6, 0, 1.0, 1.0);
draw_vert(7, 0, 0.0, 1.0);
GX_End();
}

// copy efb to xfb when ready
static void copy_to_xfb(u32 count) {
if(do_copy==GX_TRUE) {
GX_SetZMode(GX_TRUE, GX_LEQUAL, GX_TRUE);
GX_SetColorUpdate(GX_TRUE);
GX_CopyDisp(xfb,GX_TRUE);
GX_Flush();
do_copy = GX_FALSE;
}
}

void movecamera(float speed) {
Vector v;

v.x = cam.view.x - cam.pos.x;
v.y = cam.view.y - cam.pos.y;
v.z = cam.view.z - cam.pos.z;

cam.pos.x += v.x * speed;
cam.pos.z += v.z * speed;
cam.view.x += v.x * speed;
cam.view.z += v.z * speed;
}
No entiendo pq te pide hacer un MEM_K0_TO_K1, no deberia ser necesario, en todos los codigos que tengo la memoria reservada para textura es 'a pelo' con malloc o memalign...

Algo que veo que te falta es que tu primero cargas la textura, y luego inicializas el objeto de textura. Yo lo hago al contrario, primero reservo memoria, inicializo el objeto de textura (textobj) y luego cargo la textura en el memoria correspondiente a ese objeto, finalmente no haces un DCFlushRange de la memoria de textura...

Mira a ver si es por no seguir el orden correcto...

1-. Reserva
2-. Inicia objeto
3-. Usa la memoria de textura
4-. DCFlushRange (para que no se quede en cache)
5-. Usa la textura en los modelos...
Sasker escribió:Mira a ver si es por no seguir el orden correcto...

1-. Reserva
2-. Inicia objeto
3-. Usa la memoria de textura
4-. DCFlushRange (para que no se quede en cache)
5-. Usa la textura en los modelos...

¡Has dado en el clavo, ahora funciona a la perfección! ¡Mil gracias! [tadoramo] [tadoramo] [tadoramo]

Todo lo que pasaba es que no estaba usando DCFlushRange (ahora ya no hace falta MEM_K0_TO_K1) y que tenía el orden de inicialización del objeto y la carga de datos cambiados. La culpa la tiene el puñetero ejemplo "texturesample" que no usa DCFlushRange!!!! ratataaaa ratataaaa ratataaaa

P.D: Más de 4 horas he perdido por esa tontería hasta que me he decidido a pedir ayuda :(


EDIT:

He seguido dándole vueltas al tema y tengo una duda: ¿Los punteros que devuelven malloc y memalign que base tienen, 0x00000000, SYS_BASE_CACHED o SYS_BASE_UNCACHED?

Suponiendo que devuelvan en base 0x00000000 (memoria física), ¿Se podría pedir la memoria con MEM_PHYSICAL_TO_K1(memalign(32,x)), de modo que después no haría falta llamar a DCFlushRange? Claro, que el tiempo que se ahorraría no llamando a DCFlushRange se perdería al acceder al búffer sin pasar por la caché...

Me gustaría tener claro si la memoria de Wii funciona de esa forma.


EDIT 2:

Ya he publicado la última versión de PNGU. He corregido algunos bugs, optimizado varias cosas y añadido soporte a más formatos gráficos de Wii/GC. La interfaz ha quedado tal que así:

int PNGU_Init ();
void PNGU_Release ();
int PNGU_SelectFileFromBuffer (const void *buffer);
int PNGU_SelectFileFromWiiSD (const char *filename);
int PNGU_GetImageProperties (PNGUPROP *fileproperties);
int PNGU_DecodeToYCbYCr (PNGU_u32 width, PNGU_u32 height, void *buffer, PNGU_u32 stride);
int PNGU_DecodeToRGBA8 (PNGU_u32 width, PNGU_u32 height, void *buffer, PNGU_u8 default_alpha);
int PNGU_DecodeTo4x4RGB565 (PNGU_u32 width, PNGU_u32 height, void *buffer);
int PNGU_DecodeTo4x4RGB5A3 (PNGU_u32 width, PNGU_u32 height, void *buffer);
int PNGU_DecodeTo4x4RGBA8 (PNGU_u32 width, PNGU_u32 height, void *buffer, PNGU_u8 default_alpha);

En futuras versiones espero ampliarla con más formatos de textura, soporte para guardar capturas de pantalla en PNG y posibilidad de leer las imágenes desde DVD y SDGecko, este último muy útil para los usuarios de GC.


EDIT 3:

También he trasteado un poco con el tema del sonido. Concretamente he conseguido reproducir un MP3 usando "mp3player.h", para lo que he tenido que modificar ligeramente el ejemplo de tehwii, que estaba obsoleto. La verdad es que reproducir un mp3 con mp3player es muy sencillo, básicamente llamar a cuatro funciones, pero también muy poco útil. Según he leido en tehskeen, las funciones de mp3player hacen un uso exclusivo del hardware de sonido, por lo que no se pueden reproducir efectos al tiempo que suena la música. En cuanto tenga un rato trataré de confirmar esa información y buscar soluciones. Mientras tanto, para el que esté interesado, adjunto el código fuente:

mp3play.c escribió:#include <gccore.h>
#include <ogcsys.h>
#include <mp3player.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

extern u8 mp3data[];
extern u32 mp3length;

GXRModeObj *vmode;
u32 *xfb = NULL;

int main ()
{
VIDEO_Init ();

PAD_Init ();

switch (VIDEO_GetCurrentTvMode ())
{
case VI_NTSC:
vmode = &TVNtsc480IntDf;
break;

case VI_PAL:
vmode = &TVPal528IntDf;
break;

case VI_MPAL:
vmode = &TVMpal480IntDf;
break;

default:
vmode = &TVNtsc480IntDf;
break;
}

VIDEO_Configure (vmode);

xfb = (u32 *) MEM_K0_TO_K1 (SYS_AllocateFramebuffer (vmode));
console_init (xfb, 20, 64, vmode->fbWidth, vmode->xfbHeight, vmode->fbWidth * 2);

VIDEO_ClearFrameBuffer (vmode, xfb, COLOR_BLACK);
VIDEO_SetNextFramebuffer (xfb);
VIDEO_SetBlack (0);
VIDEO_Flush ();

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

MP3Player_Init ();

MP3Player_PlayBuffer (mp3data, mp3length, NULL);

while (MP3Player_IsPlaying ());

while (1);

return 0;
}


mp3file.s escribió:.rodata
.globl mp3data
.globl mp3length
.balign 32
mp3length: .long mp3end - mp3data
mp3data:
.incbin "../song.mp3"
mp3end:


Hay que modificar el makefile para incluir la librería mad, y como siempre el orden de inclusión de las librerías es importante para evitar errores de linkado. A mi me ha funcionado con el siguiente orden: -lmad -logc -lm

Saludos!
Bueno, una pequeña novedad, como estaba atascado con el tema de las SD y el cargador me he puesto a trabajar sobre mi sistema de Head-tracking y tengo lista (creo) la primera prueba del sistema, sin embargo no puedo compilar el codigo por que tengo que actualizar las librerias de libOGC por CVS.
He intentado seguir el tutorial ese que enlazan en este foro pero cuando intento meter el primer comando de CVS me salta un error del Application loader: "Couldn't find Application loader. Check your installation" Y No se que hacer por que la instalacion era tan simple como descomprimir unos archivos.
Yo obtuve la versión CVS usando el CVSNT. Me lo instaló el TortoiseCVS y como éste último me petaba usé el siguiente comando para bajarme libogc usando el CVSNT a pelo:
"C:\Archivos de programa\CVSNT\cvs.exe" -z3 -d:pserver:anonymous@devkitpro.cvs.sourceforge.net:/cvsroot/devkitpro co -P libogc
pause

Lo suyo es crearse una carpeta y dentro un archivo .bat que contenga el comando.
De todas formas si quieres te puedo pasar la versión CVS ya compilada que ocupa unos 2 megas y pico...

Por mi parte sigo trabajando en el tema de la SD. Espero tener novedades muy pronto :)
yo soy miembro de un grupo de programación. estábamos pensando en meternos en desarrollo para iphone, xo esto es muucho más interesante.

por favor, hazme saber tus planes, si los tienes (me refiero a coste de desarrollo, tiempos...)

un saludo.
La verdad es que este es un proyecto totalmente amateur, que empezo por pura experimentacion. Toda ayuda es bienvenida, pero hasta verano no creo que pueda dedicarle suficiente tiempo como para convertirlo en un desarrollo estable (por los examenes mas que nada). Con esto lo unico que quiero decir es que aun no puedo dar datos seguros de la duracion del proyecto o de cuando saldra alguna demo, ni nada por el estilo. Sin embargo os animo a que os unais a nosotros porque estoy seguro de que cuando empecemos a mostrar resultados mucha gente se interesara, y sobretodo porque pocas plataformas hay como la wii para desarrollar ideas innovadoras (yo tengo en mente ya varias aplicaciones bastante atractivas, basadas en las posibilidades del wiimote y del bluetooth de la wii, poco a poco ire diciendo algunas de ellas. De momento a ver si consigo compilar de una vez el ejemplo de head-tracking que tengo programado. Si funciona aceptablemente lo pulire un poco y lo publicare.
technik escribió:La verdad es que este es un proyecto totalmente amateur, que empezo por pura experimentacion. Toda ayuda es bienvenida, pero hasta verano no creo que pueda dedicarle suficiente tiempo como para convertirlo en un desarrollo estable (por los examenes mas que nada). Con esto lo unico que quiero decir es que aun no puedo dar datos seguros de la duracion del proyecto o de cuando saldra alguna demo, ni nada por el estilo. Sin embargo os animo a que os unais a nosotros porque estoy seguro de que cuando empecemos a mostrar resultados mucha gente se interesara, y sobretodo porque pocas plataformas hay como la wii para desarrollar ideas innovadoras (yo tengo en mente ya varias aplicaciones bastante atractivas, basadas en las posibilidades del wiimote y del bluetooth de la wii, poco a poco ire diciendo algunas de ellas. De momento a ver si consigo compilar de una vez el ejemplo de head-tracking que tengo programado. Si funciona aceptablemente lo pulire un poco y lo publicare.


Yo me comprometo a hacer un CVS/SVN si fuera necesario, ya que seria una forma de organizar todo. Lo suyo seria preparar una pequeña web donde colgar cualquier novedad por muy mínima que sea y que cualquiera pudiese acceder y colaborar :D

PD: He estado varios días sin PC y por eso no contestaba sorry :P, ahora estoy de nuevo con un pc que me he montado a base de piezas que tenia por casa tiradas xD, estoy con el nuevo Ubutu, que la verdad me está gustando mucho, solo que ahora a ver como me las monto para meterle el devkitppc y la libogc ratataaaa.

PD2: Gracias jamaya por completar el miniprogramilla de lectura en la sd :D, si tengo tiempo y consigo meter la libogc en ubuntu le meteré una rutina mas para escribir un archivo.

PD3: Animo que esto avanza!! :D

Un Saludo ;)
Llevo siguiendo este hilo desde que empezó, y la verdad es que estáis haciendo un gran trabajo. Seguid así. [beer]

En cuanto tenga tiempo voy a hacer alguna chorradita con 3D + wiimote.
technik escribió:Bueno, una pequeña novedad, como estaba atascado con el tema de las SD y el cargador me he puesto a trabajar sobre mi sistema de Head-tracking y tengo lista (creo) la primera prueba del sistema, sin embargo no puedo compilar el codigo por que tengo que actualizar las librerias de libOGC por CVS.
He intentado seguir el tutorial ese que enlazan en este foro pero cuando intento meter el primer comando de CVS me salta un error del Application loader: "Couldn't find Application loader. Check your installation" Y No se que hacer por que la instalacion era tan simple como descomprimir unos archivos.





En windows podeis usar wincvs, es parte de cvsgui.sf.net.

Descargais la ultima version de libogc del cvs.
La colocais en C:\devkitPro\msys\home\libogc

Dentro de wincvs:
Menus-> Admin -> Login
En CVSROOT poneis:
:pserver:anonymous@devkitpro.cvs.sourceforge.net:/cvsroot/devkitpro

aceptais, os pedira password, le dais a aceptar sin poner nada.

Menus->Remote->Checkout Module.
En el desplegable de cvsroot, podreis elegir el que antes hemos creado, lo selecionais.
En 'Local folder to checkout to:' poneis
C:\devkitPro\msys\home\
Y mas arriba hay que escoger la libreria, poneis: libogc (Si pulsais el boton de puntos para buscar, os listara todas las librerias posibles, tendreis que hacer doble click en libogc)
Aceptar y se pondra a actualizar, cuando se este quieto estaremos listos...


Abris la ventana de msys desde programas,
cd ..
cd libogc
make clean
make

tarda un rato.

luego teneis que copiar desde dentro de C:\devkitPro\msys\home\libogc
el contenido de la carpeta lib a C:\devkitPro\libogc\lib
el contenido de la carpeta include a C:\devkitPro\libogc\include
(Si teneis todo bien configurado, este ultimo paso se puede hacer auto con 'make install', si os diese algun error, a mano se hace como explico).

Ya teneis la nueva libogc lista para compilar
En cuanto llegue a mi casa volvere a probar a ver si consigo actualizar las librerias. Mientras tanto sigo trabajando en el source. He estado mirando en las wiiuse y me he dado cuenta de que el algoritmo que usan para el track de IR es bastante pachanguero cuando se trata de puntos multiples, asi que estoy desarrollando el mio propio. Creo que voy a sobreescribir ese algoritmo, luego creare uno independiente para el head-traking(de momento uso el original, aunque se que es una solucion muy cutre y poco optimizada) y probablemente cree 2 o 3 mas para otras aplicaciones que tengo en mente con el wiimote. Con lo que si he podido ir trabajando es con el tema de editores y demas, no tengo aun mucho codigo escrito pero si voy teniendo mas clara la estructura que llevara. Se que hay gente que no ve muy util un editor para la wii habiendo max y todo eso pero esto es cuestion de gustos, quien quiera (y sepa) se puede escribir un plugin para el Max que soporte GlovePie y use el wiimote, y quien no pues podra usar el editor de su propia wii, y aun mas si de lo que hablamos es de un editor de escenarios y no de modelos. Total, que esta tarde vere que tal funciona mi aun primitivo sistema de 3D, y luego intentare sustituire el tracking de IR de wiiuse basado en hacer medias por el mio basado en el algebra lineal y la geometria de subespacios.

EDIT: ya esta solucionado, tengo las librerias nuevas ya instaladas y voy a probar a ver si funciona mi ejemplo.

EDIT2: Nada, no hay forma, ahora me da errores de linking... como si no encontrase la libreria bte que acabo de instalar...
¿Qué aspecto gráfico tendría el motor que vais a programar?¿Como la N64 o mejor?
Como te lo curras technik!

Si necesitais algún modelo de algún personaje o cualquier cosa para ir trasteando, me gustaría colaborar. Eso sí, no me gano la vida con esto ni mucho menos, pero me gustaría ir pillando experiencia en el tema y empezar a colaborar en algún proyecto "amateur", como dices. Así que tampoco espereis unos modelos del copón... [+risas]

Utilizo principalmente el Max para modelar y Maya para animar.

Un saludo y a darle caña al tema!
palote07, aun es muy pronto para saber eso, pero si hay suerte y conseguimos utilizar las GX a un buen nivel podriamos tener potencia de gameCube o incluso de Wii, otra cosa es el nivel de optimizacion que consigamos en nuestro propio código y demaás, pero en principio seria como mínimo una N64, seguro.
technik... ¿Te da errores de linking en TODO? o sólo en las bte?

Si te da errores en TODO, comprueba que hayas hecho el make install-headers despues de haber compilado las libogc (si... a mi me pasó eso... :()
388 respuestas
1, 2, 3, 4, 58