Revolution Engine

Gracias Rmn por la info ;)

Al fin he entendido lo de las texturas de 4x4, es como trabaja la gpu y por tanto cuando usemos GX para acelerar los graficos tenemos que tenerlo en cuenta, pero no con TinyGL.
He probado los ejemplos que ha puesto realbrucest y ya voy teniendo mas idea de como usar GX.
Ademas estoy casi seguro de que también se la solución al problema de texturas en TinyGL no es por lo de 4x4, sinó porque el formato de pixel de wii es un poco raro, y en lugar de ser RGB o algo parecido es Y1CbCr, y GRRLIB usa RGB de esta manera:

imagen.h (rgb) -> usando GRRLIB (rgb) -> GRRLIB a pantalla (rgb -> Y1CbCr)

y al usar TinyGL se hace asi:

imagen.h (rgb) -> usando TinyGL (rgb) -> TinyGL a pantalla (rgb)

La solucion que veo mas simple es hacer que TinyGL convierta de rgb a Y1CbCr antes de volcar a pantalla. Aunque no se si relentizará aun mas TinyGL.

Cada vez veo mas factible usar GX en lugar de TinyGL xD las pruebas del cubo y el plano texturizado me dan un 1000% mas de velocidad usando GX que TinyGL y seguramente sea mas diferencia con escenas mas complejas con mas polígonos y texturas....

Enfin que son las 7 de la mañana y no he dormido con la tonteria xDD pero almenos ha sido productiva la noche y tengo todo el dia para dormir en classe

openGX no es lo que necesitamos, es lo que tenemos que hacer...
El problema de openGX es que corre bajo linux encima de las SDL, por lo que necesitamos linux (fase alpha), necesitamos SDL (en wii no se ha probado)...

Estamos haciendo un motor de juegos, somos nosotros los que tenemos que crear las funciones para realizar las cosas, no querais encontrar todo hecho...
Nosotros vamos a tener que crear nuestro 'openGL' que se traduzca a llamadas hardware.

Si frontier, las texturas se colocan como dices, GRRLIB hace la transformacion internamente, si miras los fuentes podras sacar cosas en claro...


Veo claras similitudes entre openGL y la implementacion GU/GX del libogc, por lo que seria bastante facil crear las fnciones basicas de un port de openGL, o transformar tinyGL para que use hard en la medida de lo posible.
El GU.c de libogc tiene implentaciones matematicas de matrices y vectores, por lo que tambien esta realizado todo el trabajo de matrices...

Por supuesto oyzzo, soft contra hard en tema 3d no hay color.



Propongo, usar TinyGL, y tener ya una implmentacionGL, mientras algunos nos dedicamos a portarlo a hardware, otros pueden ir realizando funciones de alto nivel sobre ese motor...

oyzzo escribió:Ademas estoy casi seguro de que también se la solución al problema de texturas en TinyGL no es por lo de 4x4, sinó porque el formato de pixel de wii es un poco raro, y en lugar de ser RGB o algo parecido es Y1CbCr, y GRRLIB usa RGB de esta manera:

imagen.h (rgb) -> usando GRRLIB (rgb) -> GRRLIB a pantalla (rgb -> Y1CbCr)

Mande?? Esto donde lo hace?
GRRLIB trabaja en rgb 16bits, R5G6B5 en el formato de textura.
La pantalla la crea en formato RGB8_Z24 (24Bits de color, ZBuffer de 24bits).
Pero no hace ningun tipo de transformacion RGB -> YUY2 o RGB Y1CbCr... (almenos que yo haya visto...)

Miremos la funcion Render de GRRLIB:
PArte encargada de copiar transformar la imagen plana en bloques 4x4: Trabajando en u64 (4 pixels de 16bits R5G6B5).

for (h = 0; h < vheight; h += 4) {
for (w = 0; w < (vwidth >> 2); w++) {
*dst++ = *src1++;
*dst++ = *src2++;
*dst++ = *src3++;
*dst++ = *src4++;
}

src1 += rowpitch;
src2 += rowpitch;
src3 += rowpitch;
src4 += rowpitch;
}

No realiza ningun tipo de transformacion.

Creo que esta es la funcion mas optima de toda la GRRLIB, me hubiese esperado que copiase pixel a pixel de u16 (16 copias por bloque 4x4), pero lo hace una tacada usando u64...


Normalmente usan 16bits en texturas, pero creo que se pueden soportar 32bits sin problemas en las texturas, en pantalla segurisimo... mirare un poco mas las GX para ratificar estos datos...

Sasker escribió:Propongo, usar TinyGL, y tener ya una implmentacionGL, mientras algunos nos dedicamos a portarlo a hardware, otros pueden ir realizando funciones de alto nivel sobre ese motor.

LLevo un rato mirando las GX de libogc y me parece una buena idea, antes no estaba seguro, pero despues de ver un poco mas como funcionan las GX me parece bien.
Decid los demas si tambien os aprece bien.
En tal caso habria que decir quien quiere trabajar en la parte de portar a Hardware y quien a todo lo demas. Y luego a partir de eso habria que definir los requisitos que queremos que cumpla la primera version del motor (ya que los que yo tenia pensados se quedan cortos a la vista de que ya no hay que codear desde cero todo) y empezar por fin a trabajar en ello.
Yo no tengo mucha idea de ports y adaptaciones de librerias, asi que me dedicaria a la parte de alto nivel (que de esto si se algo mas). Cuando llegue a mi casa(alli tengo la wii, ahora estoy en la uni) empezare a trabajarme los ejemplos de tinyGL, a ver que tal.

Yo me decanto por bajo nivel... darle a tinyGL soporte hardware...

oye sasker, he dado un repaso al hilo y me he dado cuenta de que ha habido un mal entendido con lo de la matriz de proyeccion. A ver si ahora puedo explicarme mejor: Has visto el project of the month de wiibrew donde se usa un wiimote para hacer head-traking y con esto crear la ilusion de 3D en la pantalla? Para crear ese efecto, el plano de proyeccion debe ser movil, no fijo. La posicion de la camara con respecto al plano de proyeccion debe ser igual a la posicion de la cabeza con respecto a la pantalla para dar la sensacion de 3D inmersivo. En los graficos tradicionales, el plano de proyeccion se situa a una cierta distancia de la camara y es siempre perpendicular a la linea de vision, igual que se supone que el jugaor esta mas o menos fijo y justo delante de la pantalla. Si quieres 3D inmersivo el plano de proyeccion debe poder moverse y girarse con respecto a la camara igual que la pantalla de la tele se mueve con respecto a la cabeza. Eso es lo que creo que no tiene openGL y que habria que implementar. Es en realidad cuestion de cambiar el tratamiento a un par de matrices. Lo que habria que hacer es proporcionar una funcion alternativa para crear la matriz de proyeccion, que nos permitiese modificarla dinamicamente. Creo que como tinyGL es por software, no seria dificil modificarlo para tener estas funciones, y luego ya veriamos hasta que nivel se puede soportar esto por hardware, no?

Esto va viento en popa , esto si que es scene .

A ver si entre todos logramos un motor bueno para poder crear juegos

technik escribió:oye sasker, he dado un repaso al hilo y me he dado cuenta de que ha habido un mal entendido con lo de la matriz de proyeccion. A ver si ahora puedo explicarme mejor: Has visto el project of the month de wiibrew donde se usa un wiimote para hacer head-traking y con esto crear la ilusion de 3D en la pantalla? Para crear ese efecto, el plano de proyeccion debe ser movil, no fijo. La posicion de la camara con respecto al plano de proyeccion debe ser igual a la posicion de la cabeza con respecto a la pantalla para dar la sensacion de 3D inmersivo. En los graficos tradicionales, el plano de proyeccion se situa a una cierta distancia de la camara y es siempre perpendicular a la linea de vision, igual que se supone que el jugaor esta mas o menos fijo y justo delante de la pantalla. Si quieres 3D inmersivo el plano de proyeccion debe poder moverse y girarse con respecto a la camara igual que la pantalla de la tele se mueve con respecto a la cabeza. Eso es lo que creo que no tiene openGL y que habria que implementar. Es en realidad cuestion de cambiar el tratamiento a un par de matrices. Lo que habria que hacer es proporcionar una funcion alternativa para crear la matriz de proyeccion, que nos permitiese modificarla dinamicamente. Creo que como tinyGL es por software, no seria dificil modificarlo para tener estas funciones, y luego ya veriamos hasta que nivel se puede soportar esto por hardware, no?

Tanto Direct3D como openGL que son los entornos en los he programado, directamente sobre ellos, sin usar motores, tienes 2 matrices.
La matriz de proyeccion, lo que llamariamos la camara o punto de vision. y la matriz de modelos, que es la matriz en la cual se establecen la transformacion de los modelos que se dibujan en el univeso.
Ademas estas matrices de proyeccion y modelo, pueden cambiar cuatnas veces quieran durante el proceso de dibujando antes de hacer un flush (hacer que se dibujen en pantalla).
Por ejemplo es muy comun en GL trabajar sobre perspectiva, dibujar los objetos 3d, cambiar a proyeccion ortogonal y dibujar textos, menus, etc... 2D...

Nosotros podemos move un objeto 3d en el univeso y tambien podemos mover al mismo tiempo la camara que enfoca ese objeto (lo que vemos por pantalla), por lo que se pueden crear esos 'head-tracking' sin demasiados problemas... incluso creo que en la web de Nehe (te la recomiendo en cuanto a tutoriales y sitios de referencias sobre como programar openGL) hay alguna chorrada de esas...

Despues de echar un vistazo al codigo de johnny chung lee (Lo implemento en Direct3D) creo que lo que yo decia se puede hacer en OpenGL manipulando a la vez la posicion de la camara y el aspect ratio. Ahora me pondre a hacer mas pruebas, que tengo un rato, ya os cuento

technik, eso que dices se puede hacer en OpenGL ya que yo lo hice para un proyecto de estereo visión para la uni y es como dice Sasker, modificando a mano la matriz de proyeccion.

Pues lo del formato ese raro de color igual me he confundido con algo de gamecube xD

mirad este hilo, http://www.tehskeen.com/forums/showthread.php?t=3177
ahi tratan el tema de las texturas, lo unico que las convierten a .S y las incluyen en el binario... y luego mas adelante usan texturas comprimidas para que los binarios no se acaben la ram. Aunque yo veo mas simple tener las texturas en disco en jpeg por ejemplo y usar libjpeg-wii para cargarlas.

Yo prefiero programar la parte de bajo nivel, acelerando graficamente TinyGL... pero tampoco me importaria programar algunas cosas del motor, como la carga de jpegs y bmp, deteccion de colisiones y cosas así...

ya ya, ya se que se puede hacer a mano, incluso he estado mirando que componentes habria que modificar, pero es mas comodo si encontramos la forma de hacerlo mediante la funcion habitual, no?

Yo estoy haciendo pruebas con GX intentando entender como funciona, porque eso de que no haya ningun tutorial ni nada... solo dos ejemplos muy simples... pues cuesta entender que hace y porque xD Ademas de que mi experiencia de programacion es amplia pero en apilcaciones con GUI, o modulos de kernel y sistemas operativos en programacion grafica soy un poco novato y me tengo que acostumbrar

Si alguien tiene experiencia programando con GX en gamecube o wii seria de mucha ayuda un texto o algunos ejemplos mas avanzados comentados

Por lo que he visto oyzzo, las GX se usan como openGL, dibujas caras y a correr...

Intenta seguir los ejemplos de Nehe http://nehe.gamedev.net/
PAra ir aprendiendo poco a poco ciertas cosas sobre programacion 3D... son muy interesantes, aunque no los hagas en GX, hazlos en openGL bajo windows o linux para PC...

Gracias sasker, esos tutos ya los hice hace tiempo y de hecho he portado los primeros a TinyGL-wii, los conceptos basicos y eso lo tengo claro, mis dudas estan en algunos temas mas concretos, por ejemplo, como funciona la iluminacion en GX?

muy interesante esta el hilo, controlo algo de opengl con lo que aunq no tenga muxo tiempo quiza puedo hacer alguna cosilla de alto nivel, aunq tb me parece muy interesante todo lo que seria la adaptación al hardware de las librerias, aunq mi conocimentos en ese campo son casi nulos o eso creo (me gustan los retos jeje).

Un saludo y muxo animo, seguire este hilo asiduamente y espero poder programar alguna cosilla sobre o para ese motor que vais a montar.

Una pregunta para los que entendeis de esto, como veis en el futuro la posibilidad de ejecutar algun shader sobre la grafica de la wii?

pink_chocobo gracias por interesarte, seguro que technik te puede asignar alguna parte para que vayas programando, un cargador de modelos seria interesante por ejemplo de todas formas te puedes bajar TiniGL-Wii que colgé algunos posts mas atras en este hilo y ver los ejemplos y hacer alguna prueba.


Sobre las GX voy avanzando... si no hay documentacion siempre se puede aprender trasteando a modo prueba-error xD He hecho una prueba de un cubo en movimiento texturizado y control de la camara con el mando de gcube ampliando los ejemplos que habia. Cuelgo aqui el binario por si alguien quiere probarlo

Descarga:
http://d01.megashares.com/?d01=d5edc77


EDIT:

He visto que la version de TinyGL-wii que subí no compila porque le faltan cabezeras, lo he arreglado... aqui esta:

Descarga:
http://d01.megashares.com/?d01=d57326a

Siguen sin funcionar las texturas, pero ya se pueden ir haciendo pruebas

Veamos, a mayores de la librerias Tiny-GL y las demas propias de la Wii y Game cube que me imagino estaran en la pagina Wibrew en su CVS o similar, que mas necesitaria bajarme para empezar a compilar algo, que entorno seria el mas adecuado desde windows?dev cpp?

pink_chocobo escribió:Veamos, a mayores de la librerias Tiny-GL y las demas propias de la Wii y Game cube que me imagino estaran en la pagina Wibrew en su CVS o similar, que mas necesitaria bajarme para empezar a compilar algo, que entorno seria el mas adecuado desde windows?dev cpp?

Pues lo que necesitas seria:

1) devkitPPC y libogc de http://www.devkitpro.org
2) TinyGL-wii del post que he puesto mas arriva
3) leete el readme que puse en TinyGL-wii y mira los ejemplos de examples.

Nada mas, es muy sencillo

(TinyGL-wii lo porté yo hace un par de dias, por eso solo está en este hilo, y aun no se ven bien las texturas... estamos trabajando en ello xD)

Ok muchas gracias Oyzzo, los ejemplos los mirare aunq si son los de nehe portados seguramente me suenen pq esa pagina fue una muy buena referencia en mi aprendizaje de opengl.

Estupendo trabajo oyzoo, voy a pergarle una miradita haber si yo tambien puedo hacer algo. Gracias por el aporte

Edito: Por cierto he estado mirando los ejemplos, concretamente el ejemplo example4.c donde crea un cubo y una piramide y le da vueltas, y tengo una duda, al parecer para dibujar el cubo, debes indicarle las coordenadas de cada vertice
glVertex3f( 0.0f, 1.0f, 0.0f); que supongo que seran (x,y,z), lo que no entiendo es los valores que se le dan 0.0f a que coordenada corresponde? Como se representan estos valores estan en hexadecimal o algo?

Creeis que se podria llegar a cargar un modelo 3d creado por ejemplo con el 3d studio? tendria que estar en algun formato en concreto para ello?

Muchas Gracias.

Kontakatilu escribió:Estupendo trabajo oyzoo, voy a pergarle una miradita haber si yo tambien puedo hacer algo. Gracias por el aporte

Edito: Por cierto he estado mirando los ejemplos, concretamente el ejemplo example4.c donde crea un cubo y una piramide y le da vueltas, y tengo una duda, al parecer para dibujar el cubo, debes indicarle las coordenadas de cada vertice
glVertex3f( 0.0f, 1.0f, 0.0f); que supongo que seran (x,y,z), lo que no entiendo es los valores que se le dan 0.0f a que coordenada corresponde? Como se representan estos valores estan en hexadecimal o algo?

Creeis que se podria llegar a cargar un modelo 3d creado por ejemplo con el 3d studio? tendria que estar en algun formato en concreto para ello?

Muchas Gracias.

Pues esos valores corresponden a x,y,z como dices, y el formato en el que estan es Float por eso la f de glVertex3f. Esos valores son esos y no otros porque estan puestos ahi a mano calculando el cubo de cabeza. Se puede cargar un modelo 3D creado con cualquier aplicación, eso es lo que vamos a hacer, añadir funciones para hacer la programación mas facil.

Los ejemplos corresponden a las lecciones del curso de opengl de Nehe, te recomiendo que te mires esas lecciones que explican muy bien como funciona todo y asi entenderas el codigo. Las lecciones estan en : http://nehe.gamedev.net/lesson.asp?index=01

He portado libpng para usarlo en wii. Me puse anoche y he acabado hace un rato, pensaba que sería más complicado pero afortunadamente esa librería está muy bien documentada

La he portado porque hoy por hoy creo que PNG es el formato que ofrece más prestaciones: Color de fondo, color de transparencia, canal alpha, compresión sin pérdida, es un formato libre... Creo que es la elección ideal para almacenar texturas y sprites. (Que voy a cecir yo )

Ahora estoy un poco cansado pero dentro de un rato postearé un archivo con la librería ya compilada, algunas funciones de ayuda que he creado y un ejemplo de uso.


EDIT: Este es el hilo que he creado para anunciarlo.

Jurjur ANIMOS CAMPEONES D, si quereis algun modelo en 3d pa trastear decid el que querais, en el formato que lo querais y con el tipo de text que querais ... que lo hago en un plis.

Bueno, pues otro por aqui que estara enganchado a este hilo (aunque se hable de algunas cosas que aun no entiendo).

Yo queria preguntar si vale la pena aprender a usar el GX para programar graficos o le dedico ese tiempo a OpenGL.

Estoy siguiendo unos videotutoriales (de OpenGL) que, aunque esten en ingles, son comprensibles y te proponen hacer ejercicios al final de cada leccion.

Tambien decir que le he echado un vistazo a un ejemplo (el que viene con el devkitpro, el triangulo) y me parece mas complicado para lo poco que se. Ademas se hace mencion a una web con un tutorial, pero ya no existe o no la encuentro.

Saludos!!

akram04 escribió:Jurjur ANIMOS CAMPEONES D, si quereis algun modelo en 3d pa trastear decid el que querais, en el formato que lo querais y con el tipo de text que querais ... que lo hago en un plis.

Pues ahora que lo dices me vendria bien un modelo muy simple de nave tipo f-zero pero sobre todo muy simple, lo mas simple que puedas, si son 6 poligonos mejor xD primero sin textura, y luego el mismo modelo exactamente con una textura, la textura que sea en png y da igual el tamaño. El formato me vendria bien que fuera ASE en ASCII así puedo empezar a hacer pruebecillas ya


jomofer, si estas empezando no vale la pena aprender GX, mejor aprende openGL que es mas util. Mira en este hilo un mensaje donde pongo TinyGL-wii y con eso puedes programar en OpenGL para wii, es muy sencillo.
Nosotros nos encargamos de hacer que TinyGL use GX para ir mas rapido, y ademas añadiremos funciones para programar 3D incluso sin saber openGL.

No me he leido el hilo entero, pero veo que alguien ha portado TinyGL y ha probado glxgears.

Al que lo haya probado, ¿te pasa también que los colores de los engranajes están mal? (concretamente, parece que estén muy saturados y brillantes).

En X11 me salen rojo, verde y azul (como tiene que ser) pero usando TinyGL me sale uno amarillo, otro azul y el otro blanco.

Al principio le echaba la culpa al algoritmo para la raíz cuadrada que uso (pues lo he picado en asm para aprovechar ciertas capacidades de la plataforma sobre la que trabajo) ya que jugando con el resultado es muy fácil hacer que me salga mucho menos saturado sin que el resto del modelo se rompa. Lo curioso del caso es que comprobando los resultados, FALLA cuando los resultados son correctos y FUNCIONA cuando los resultados están ligeramente truncados.

Luego vi que en algunos ports para la GP2x tambien pasaba, así que seguramente no es solo problema mio.

¿Pasa en la Wii?

Por cierto, buena suerte con el port. Si váis a accelerar parcialmente TinyGL casi sale más a cuenta rehacerla de 0. Accelerar el rasterizado es bastante fácil a la mínima que el hardware soporte 4 operaciones 2d, pero hacer algo más probablemente vayas a reescribir demasiado trozo.

Pues lo cierto es que no me pasa eso de los colores en wii. se ven perfectos... Le indicas a TinyGL el formato de pixel correcto? se que es una pregunta tonta, pero nunca se sabe... de todas formas yo probé TinyGL en GP2X y se veia bien, lo que pasa es que era tremendamente lento porque la GP2X no tiene FPU. Para GP2X se hizo una capa openGL acelerada por el segundo procesador, se llama gpu940 y portaron egoboo con ella, iva bastante bien.

Sí, el formato de píxel creo que es correcto. Además, sin GL_LIGHTING todo va perfecto.

Buscando en Google Images "tinyGL" sale varias veces resultados como el siguiente:




Que es exactamente lo que produce mi port, y que es incorrecto.

Incluso el icono de la TinySDGL (que no es la que he portado yo, sinó un port usado para la GP) utiliza el resultado malo:


Este es el resultado correcto:


Tambien pensaba que podía ser un problema de profundidad de color pero tampoco parece, ya que el clásico triángulo con smooth shading sale bien con todos los colores.


¿Entonces en la Wii sale el resultado correcto? Lamento preguntarlo pero no puedo probar el ELF, no estoy metido en el tema.

Pues en wii lo acabo de comprobar otra vez y se ve perfecto, como se tiene que ver :S nose que puede ser, a mi nunca me ha pasado eso de verse asi... en realidad ni sabia que existia ese problema

oyzzo escribió:
Pues ahora que lo dices me vendria bien un modelo muy simple de nave tipo f-zero pero sobre todo muy simple, lo mas simple que puedas, si son 6 poligonos mejor xD primero sin textura, y luego el mismo modelo exactamente con una textura, la textura que sea en png y da igual el tamaño. El formato me vendria bien que fuera ASE en ASCII así puedo empezar a hacer pruebecillas ya

Aqui tienes, esta sin textura solo la geometria, lo acabo de hacer en 10 minutillos, como has dicho que no me pasase de poligonos la he hecho de 110, asi que si luego quieres puedo darle mas.

Esta exportado a .ASE.

Pues ahora que lo decís a mi si que me salio ese problema cuando cargue el elf en mi wii, lo que pasa es que yo supuse que esos eran los colores de los engranages, no sabia que no eran asi en realidad.

A ver si alguien puede ayudarme...

Necesito leer datos desde la SD frontal y no se por donde empezar. En libogc he visto muchos .h relacionados con la SD pero no se si valen para el lector frontal de wii o son para el adaptador gekko de cube.

Sólo necesito un punto de partida para investigar por mi cuenta, aunque no desdeñaría una explicación exhaustiva jejeje.

El objetivo es poder cargar archivos .png desde la tarjeta para usarlos con la librería que he compilado. Si lo consigo escribiré una función de ayuda que reciba el nombre del fichero y deje la imagen ya descomprimida en un buffer.

Por cierto, estoy trabajando con la versión libogc del CVS.


Gracias.

frontier escribió:A ver si alguien puede ayudarme...

Necesito leer datos desde la SD frontal y no se por donde empezar. En libogc he visto muchos .h relacionados con la SD pero no se si valen para el lector frontal de wii o son para el adaptador gekko de cube.

Sólo necesito un punto de partida para investigar por mi cuenta, aunque no desdeñaría una explicación exhaustiva jejeje.

El objetivo es poder cargar archivos .png desde la tarjeta para usarlos con la librería que he compilado. Si lo consigo escribiré una función de ayuda que reciba el nombre del fichero y deje la imagen ya descomprimida en un buffer.

Por cierto, estoy trabajando con la versión libogc del CVS.


Gracias.

Buenas, me interesa mucho el proyeto que teneis entre manos, he estado mirando el tinygl-wii y está muy bien, me gustaria colaborar

Por otra parte he "quoteado" tu mensaje porqué he visto que también has portado la libpng, que es justo lo que necesitaba!! xD
Si necesitas info para manejar el sd frontal agregame al messenger (en mi perfil está) y ya hablamos por ahí

Un Saludo

Tengo una duda, he creado mi primer modelo en 3d (una piramide truncada con la cara de arriba extruida), he colocado todos los vertices formando las diferentes caras. la duda que tengo es que si los puntos de las caras los tengo que poner en algun orden en concreto, yo lo los he puesto en sentido antiohorario, pero cuando he probado el programa, las caras no me aparecian enteras, me quedaban a triangulos con agujeros triangulares, no se si me explico.

Tambien me he fijado que al dibujarlo, me ha quedado la Z en posicion horizontal, como si las coordenadas de los pixeles no fueran xyz, igual es cosa del programa.

Este es el fichero por si alguien lo quiere ver:
http://www.mediafire.com/?hufmygp3cw8

P.D.: A mi tambien me sale el engranaje grande amarillo.

He pensado que podeis hacer una aplicación demo como la de correr que hay en Wiifit con un personaje en pantalla y luego un gran campo alrededor, el wiimote en el bolsillo y a contar la distancia que recorres...

He encontrado el codigo fuente de un cargador de ficheros .ASE y tambien algunos tutoriales de opengl.

Esta es la web:
http://usuarios.lycos.es/andromeda_studios/paginas/principal.htm

Haber si se puede portar el cargador a la wii y podemos hacer experimentos mas interesantes

Saludos...

Kontakatilu escribió:He encontrado el codigo fuente de un cargador de ficheros .ASE y tambien algunos tutoriales de opengl.

Esta es la web:
http://usuarios.lycos.es/andromeda_studios/paginas/principal.htm

Haber si se puede portar el cargador a la wii y podemos hacer experimentos mas interesantes

Saludos...

Buenas, he estado mirando la web que mencionas y no he sido capaz de descargarme el susodicho SRC

La mayoria de links están rotos y los que no lo están no son nada referente a lo que has mencionado...

Un Saludo

Con respecto a cargador de modelos, yo estoy implementando uno de 3ds, usando el tinyGL, para asi poder utilizarlo conforme se valla haciendo la compatibilidad por hard. Por cierto, ¿que tal va esa compatibilidad tinyGL-GX para usar la aceleracion hardware?

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.

Davpk te agrego y a ver si puedes ayudarme con lo de la SD.

Aqui teneis el source del cargador de ficheros ASE que os decia, haber si alguien se anima a portarlo a la wii.

Archivo: http://www.mediafire.com/?tezqty82j9i


Saludos...

El tema de las SD, por que no lo tratais aqui en el foro? Seguramente sera util en varias ocasiones (Probablemente desde ahi cargue todos los modelos, texturas, scripts y demas el motor) y asi aprendemos a usarlo todos

technik escribió:El tema de las SD, por que no lo tratais aqui en el foro? Seguramente sera util en varias ocasiones (Probablemente desde ahi cargue todos los modelos, texturas, scripts y demas el motor) y asi aprendemos a usarlo todos

Sería interesante que alguien se curre una libreria y que con un par de lineas de código se pueda escribir en la SD.

Gracias por el modelo en ASE compañero! ahora la version con textura del mismo modelo me vendria bien

Sobre el cargador de ASE... Pues nose si es necesario, eso es technik quien lo tiene que decir si el esta con el de 3ds se usará 3ds, yo pido ASE para hacer pruebas, ya que es en ascii, es comodo para probar y me he hexo un parser de ASE a .h pero eso no quiere decir que el motor use formato ASE.

sobre lo de TinyGL-GX aun no me he puesto, estoy metiendole mano a GX para poder acabar de entenderlo bien, pero cuando acabe de probar este fin de semana el ASE y en GX me pongo a añadir GX al TinyGL. Lo estoy probando todo en la wii, que hasta ahora lo habia probado en el emulador que no es lo mismo

palote07 escribió:
Sería interesante que alguien se curre una libreria y que con un par de lineas de código se pueda escribir en la SD.

Acabo de hacer un ejemplillo de como leer desde la SD frontal, en breve lo subo (aun no lo he testeado).

He cogido directamente la parte de lectura del MAGLoader (proyecto en el que estoy como dev por si alguien no lo sabia xD), con lo cual en principio lo que hace es abrir la carpeta "elf" y te dice los nombres de los archivos que hay dentro y nada mas xD, bueno si aprietas B en el wiimote recarga el loader.

PD: En cuanto lo pruebe y corrobore que funciona lo subo .

Un Saludo

Davpk muy bien compañero, será muy util para empezar a hacer los cargadores de modelos y texturas.

Acabo de probar todos los ejemplos en la wii, Todo va perfecto, menos lo de los colores de TinyGL y las texturas en TinyGL. Colores y texturas en GX van perfectos, asi que no veo necesario reparar TinyGL para luego deshechar el codigo y pasarlo a GX, directamente me pondre meter el codigo para que TinyGL use GX así todo irá bien y además acelerado

Las pruebas que estoy haciendo con GX van mejor de lo que esperava, seguramente me ponga hoy mismo a meter GX en TinyGL.

Triunfazo!!!


Gracias a la info que me ha proporcionado Davpk y a una tarde de sábado encerrado en casa he conseguido cargar archivos .png desde la SD frontal y mostrarlos en pantalla

Tadavía quiero meterle algunas mejoras al invento, pero mañana lo subiré para quien le interese.


Supongo que con el ejemplo que va a poner Davpk quedará claro como funciona el tema de la SD, ya que no es muy dificil. De todas formas si estais investigando otras cosas es mejor que no perdais el tiempo con esto porque el autor del código que estamos usando dice que tiene bugs y que sólo es un apaño provisional mientras le añaden soporte SD a libogc. Cuando eso ocurra tendremos que rehacer nuestros programas para adaptarlos a la nueva interfaz.

Mientras tanto me ofrezco a realizar una interfaz sencilla para acceder a la SD, por si alguien necesita carga de ficheros y no quiere perder el tiempo aprendiendo algo que pronto quedará obsoleto...

Sería algo como:

int SD_ReadFile (const char *filename, void *buffer);
int SD_GetFileSize (const char *filename);
int SD_GetFirstFileInDir (const char *dirname, char **filename);
int SD_GetNextFileInDir (const char *dirname, char **filename);

Creo que con esas 4 funciones se podría hacer casi todo. ¿Qué opinais?

Me parece estupendo, pero teneis que saber una cosa, en el momento que se sincronizan los wiimotes, el acceso a la ranura frontal del sd empieza a dar problemas y no se accede correctamente, es un bug que hay con las librerias y que se tiene que solucionar.

Saludos.

Kontakatilu escribió:Me parece estupendo, pero teneis que saber una cosa, en el momento que se sincronizan los wiimotes, el acceso a la ranura frontal del sd empieza a dar problemas y no se accede correctamente, es un bug que hay con las librerias y que se tiene que solucionar.

Saludos.

Es que las librerías del wiimote están en el mismo caso que las de la SD. Tienen bugs y quedarán obsoletas tan pronto se añada soporte al wiimote en libogc.

Puestos a elegir me parece más útil poder leer datos de la SD que tener acceso al wiimote, sobre todo teniendo en cuenta que el mando de GC seguiría funcionando.

Kontakatilu escribió:Me parece estupendo, pero teneis que saber una cosa, en el momento que se sincronizan los wiimotes, el acceso a la ranura frontal del sd empieza a dar problemas y no se accede correctamente, es un bug que hay con las librerias y que se tiene que solucionar.

Saludos.

Buff, llevo toda la tarde liado con el puñetero ejemplo de la sd y yo sin darme cuenta de que inconscientemente estaba usando la wiiuse .

Parece ser que ahora que le he quitado las wiiuse ya va "mejor" xD, como es muy tarde lo voy a colgar tal y como está, lo siguiente que queria hacer es que mostrase en pantalla el contenido del fichero que abre, pero como he dicho antes es muy tarde jeje.

Ahora mismo monta la sd abré el directorio "elf" y muestra los archivos que hay dentro, luego carga un archivo llamado "texto.txt" dentro de la carpeta "elf" y muestra su tamaño. Hasta ahí lo que hace, ahora quedaria por hacer lo que he dicho antes, pero bueno es bastante superfluo hacer esto ultimo, aun así si alguien tiene ganas de hacerlo ¡¡ADELANTE!! . Ah, y con el boton de reset se vuelve al loader.

PD: No se que coño hará la puñetera Wiiuse que jode la lectura de la sd, por eso no podemos hacer el MAGLoader con control wiimote (y mira que no acordarme de la pelea que tenemos con las wiiuse para cargar los elfs). Voy yo y me tiro toda la tarde tirandome de los pelos para tal tonteria xD. Solo me queda decir una cosa "gracias Kontakatilu" xD, que fallo mas tonto el mio jeje

PD2: Adjunto el programilla que decia, tiene aun la parte del uso del wiimote pero está "comentado" y lo ignora, he quitado todas los archivos del wiiuse para no ocupar espacio tonto, y también he borrado el archivo ".dol" final y he dejado solo el elf para que me deje adjuntarlo el foro, que si no ocupaba demasiado . Si alguien por algún motivo quisiera el dol que use el elf2dol o que lo compile directamente.

PD3: Si veis alguna falta de otrografia en los comentarios, "I'm Zorri", son las 2 de la madrugada ya, y paso de ponerme a revisar xD

Buenas Noches y Buena Suerte

Davpk gracias por el codigo, le voy a hechar un vistazo ahora mismo para hacerme una idea de como funciona

frontier seria genial si haces esas funciones y un programilla comentado de ejemplo

veo que cada uno va consiguiendo cosillas por su parte, esto pinta bien... aver si dentro de poco podemos hacer una demo guapa

oyzzo, el tema de los cargadores de modelos...ninguno sobra jeje. Como de momento estamos desarrollando los comienzos del motor habra que hacer pruebas con todo lo habido y por haber. Luego ya nos quedaremos con el formato que mas nos guste o que mejor nos parezca, incluso es posible que diseñemos nuestro formato, optimizado para las tareas que necesitamos. El 3ds lo he elegido por que tambien lo uso en un editor que estoy haciendo y asi me ahorro exportar y todo el lio

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