Revolution Engine

Existe el SDL para GC, asi que supongo que no tardaran en portarlo a Wii cuando funcione todo al 100%.

Con el SDL puedes portar muchas cosas ya existentes (como el ScummVM por ejemplo) y usarlo para crear juegos nuevos.

Yo esperaria un añito a hacer eso, a que la libog y el wiimote este bien implementado y sin fallos.

Por lo demas, muy buena iniciativa, espero que se lleve a cabo.

De las pocas cosas que de verdad interesan maxo DDD muy buena iniciativa, si señor.

Si necesitas algo de ayuda, solo dilo.

Bueno, Yo voy a empezar con ello en breve, os ire comentando todo lo que consiga y pondre screenshots cuando las tenga. Si a alguien mas le interesa el proyecto que lo diga aqui, que cuantos mas seamos mejor. Ademas, si a alguien se le ocurren ideas o cosas que le gustaria que tuviese, que las comente

En principio es buena idea pero creo que corres demasiado. Me explico:

- Según tengo entendido la parte del wiimote en las GRRLIB tiene aun algunos fallos y lo que es peor, su creador a abandonado el proyecto. Sería mejor esperar un poco a que se integren rutinas en libogc para controlar el wiimote. Así despues no habría que tirar código.

- Estoy aprendiendo ahora mismo el uso de libogc y aún no he llegado a la parte de 3D así que no se a que nivel está implementado. Pero si es a muy bajo nivel, tal y como sospecho, quizás sería bueno programar una implementación de OpenGL basada en libogc y sobre ella construir las clases del motor. Digamos que hay que dividir el problema en partes más pequeñas.

Me gustaría ayudar, tengo bastante manejo de C++ y ya he hecho cosas en 3D antes (incluyendo un motor 3D muy básico), aunque me veo demasiado pez en libogc. Contad conmigo.


Por cierto, para los que esteis como yo empezado con libogc hay un hilo muy interesante que tal vez querais visitar: http://www.elotrolado.net/hilo_-GC---Wii--Desarollo--Info-y-Dudas--_979647
No se porqué KFR lo creó en el subforo "otras consolas", por eso creo que no lo conoce demasiada gente.

Muy buena idea ^^

Ya me imagino a la peña combinando el wiimote con lo del wiifit

Hombre como idea se podria portar las SDL y luego el lenguaje [url=fenix.divsite.net]FENIX[/url] que es muy sencillo de aprender y da buenos resultados (EN 2D)

Buenas, Pues primero decir que me interesa el proyecto y puedes contar con mi ayuda.

Me manejo bastante bien en qualquier tema, asi que tu diras que necesitas. Como mas vale actuar que hablar pues anoche mismo terminé de portar TinyGL a wii.

Como bien dice frontier, no hay nada para hacer 3D en wii. La unica solución es hacer una implementación de OpenGL por software (aunque no hace falta que sea implementacion de opengl, pero asi es mas sencillo de usar y portar juegos 3D) así que eso es TiniGL.

Como es un port rapido que se tiene que pulir un poco pensava poner un screenshot, pero he pensado que mejor poner el binario y así lo provais en las consolas y me decis que tal va, porque lo cierto es que aun ni lo he probado yo en la mia, solamente en el emulador.

Realmente no hace nada, simplemente muestra los tipicos engranajes 3D rodando, no he añadido codigo para salir ni nada asi que tendreis que apagar la consola

Colgaré el codigo fuente tb cuando lo arregle un poco.

Espero que os guste

EDIT: si no pongo la descarga mal vamos xDD
http://d01.megashares.com/?d01=614b9a5
ahi va

si necesitais o quereis algun modelo en 3d decidmelo y lo hago Xd.

Me ofrezco a programar cualquier cosa.

Contar conmigo

Pues aun es temprano para necesitarlo, pero cuando se implemente un cargador de modelos se tendrán que hacer pruebas con varios modelos simples, mas complejos, sin material, con material, con textura, luego con animaciones... etc
Asi que gracias por ofrecerte

Esto se va animando. Yo lo que tenia pensado era hacer las librerias 3D, con un funcionamiento similar a OpenGL, pero eso es solo por que no se como portar librerias a la Wii. ¿como puedo aprender a hacer eso? Es que estaria bien saber crear/portar las librerias por que nos ahorramos mucho tiempo y trabajo y tambien nos permitiria pulir nosotros mismos el control de wiimote, no?

Me alegro de que a la gente le interese el proyecto, y aunque no conteste a cada uno independientemente aun, cuento con todos vosotros

PD: oyzzo , ahora mismo pongo a bajar ese archivo

Es que esto si es scene y mola que la gente haga cosas creativas-productivas en vez de partir la VC.
Yo de programacion poco, pero ya digo de modelar lo que querais

Yo digo lo mismo, de programar aun no estoy muy capacitado, pero de modelar... Incluso os puedo hacer unos modelos muy parcidos a los de N64

technik pues portar cosas puede ser sencillo si estan programadas con portabilidad en la cabeza, afortunadamente TinyGL no es complicado de portar

Yo he usado GRRLIB 2.0, así se puede usar para 2D GRRLIB 2.0, y para 3D TinyGL (openGL), ademas de wiimote y esas cosas

Nose que tienes en mente tu para tu Engine, pero el 3D lo tienes solucionado aunque se tendrian k hacer un cargador de modelos, animaciones y eso...

Y el 2D tampoco se que quieres que haga, pero usando GRRLIB tambien seria mas sencillo...

Piensalo, haz el diseño y nos comentas

PD: contarme si os va la demo esa k he colgado.. me estoy currando otra k use el mando y se pueda mover algo y salir

Yo tengo la demo descargada, pero estoy en la uni, asi que la probare cuando llegue a mi casa

Te refieres a que has portado tiniGL usando la libreria GRRLib 2.0?
En ese caso has hecho basicamente lo que tenia pensado hacer yo, solo que yo no sabia como jejej
Ahora mismo estoy liado con el diseño. Para empezar, en la primera version me conformo con mostrar terreno, modelos con textura simple de un solo canal y sprites en 2D sobre la pantalla. Se que teniendo las GRRLib y ahora con el tiniGL eso no deberia ser complicado, asi que para una primera version no esta mal
Cuando lo tenga un poco mas especifico os cuelgo una lista de caracteristicas basicas.

EDIT: Acabo de probar la demo, esta genial tio, a ver si puedes pasar el source, no?

Gracias por probarlo tio, va muy rapido? ... pues si quieres te rulo el source por mail, no lo colgaré aquí hasta que no esté un poco mas arreglado, y termine la otra demo mas elaborada que use el wiimote y la comente a fondo (sera para este finde) ya he hecho una plantilla comentada para programar usando TinyGL y GRRLIB

no quiero que esto suene a troll ni a al tipico jeta que no hace mas que pedir y pedir pero...

alguien se anima a programar un daytona para wii ?

ya se intento hacer algo en su dia para la DS, pero por motivos de capacidad el proyecto se paro, aun asi, ya hay algun modelo en 3d realizado.

sobre el tema de documentacion del juego lo tengo todo listo todo: texturas, sonidos, musica... faltarian algunos modelos en 3d y un motor grafico.

alguien se anima?

aqui podeis ver bastante material que tenia preparado:
http://jordigahan.iespana.es seccion daytonaDS

oyzzo escribió:Gracias por probarlo tio, va muy rapido? ... pues si quieres te rulo el source por mail, no lo colgaré aquí hasta que no esté un poco mas arreglado, y termine la otra demo mas elaborada que use el wiimote y la comente a fondo (sera para este finde) ya he hecho una plantilla comentada para programar usando TinyGL y GRRLIB

Wow, estoy deseando verlo, a ver si me decido ya a hacer algun juego....

pues a mi parecer seria esperar a q se integre lo del libogc, i ais ahorrarse muchas cosas...no?
aparte seria bueno lo de la idea con un buen manejo y uso de leng. fenix...jajaja no seria haze pero pues algo es algo y casero!

Yo creo que tal como estan las cosas lo mejor es que los fieras se pongan a cacharrear y a experimentar sin centrarse en algo en concreto, ya que todavia el homebrew de wii ta empezando.

ANIMOS y a ver si pronto va cogiendo forma la idea que esta genial

jordigahan escribió:no quiero que esto suene a troll ni a al tipico jeta que no hace mas que pedir y pedir pero...

alguien se anima a programar un daytona para wii ?

ya se intento hacer algo en su dia para la DS, pero por motivos de capacidad el proyecto se paro, aun asi, ya hay algun modelo en 3d realizado.

sobre el tema de documentacion del juego lo tengo todo listo todo: texturas, sonidos, musica... faltarian algunos modelos en 3d y un motor grafico.

alguien se anima?

aqui podeis ver bastante material que tenia preparado:
http://jordigahan.iespana.es seccion daytonaDS

Pueeeees, me parece muy interesante, voy a hecharle un vistazo y te digo que tal lo veo

EDIT:
Pues lo he estado mirando y me gusta mucho ese juego, pero lo que hay en la web es un modelo y alguna textura de regular calidad, ademas que hay cosas cogidas del juego original, cosa que no es muy legal

En resumen, que es una muy buena idea para un juego, pero seria mejor reacerlo todo para que se adapte mejor a wii

EDIT2:
Estoy portando los programas de ejemplo del curso de openGL de nehe
http://nehe.gamedev.net
y tengo problemas con las texturas... todo lo demas va genial.
Las texturas las cargo usando GRRLIB y se las paso a tinyGL, pero algo debo hacer mal o algo se me escapa porque se ven mal :S enfin si alguien puede tener idea de porque es...

He empezado ya con un poco de codigo para la version 0.0 del game engine (hay que buscarle un nombre, se aceptan propuestas).
Ahora mismo estoy trabajando en el algoritmo de rasterizado por que voy a añadirle una cosa que no tiene openGL y que quedaria muy way en la wii. Es un tema relacionado con los planos de proyeccion. Os pondre alguna captura cuando las cosas funcionen mejor.
oyzzo, he estado pensando acerca del port de tiniGL. Creo que es una gran idea, y te agradeceria que siguieras portandolo. Yo mientras tanto seguire refinando mis algoritmos de scene management, rasterizado y demas. Si me pasas los sources de las cosas que vallas portando yo les podre incluir estos algoritmos y asi podremos conseguir entre los dos (y todos los demas que quieran colaborar) una primera version simple del motor que al menos cargue modelos y los muestre en pantalla girando con unos frame-rates aceptables, que te parece?

yo no usaria GRRLIB para el tema 2D... es una libreria nefasta desde el punto de vista de la optimizacion...

Hace todo por puntos, en lugar de copiar bloques de memoria.
Las funciones no son buffer-independientes, para poder trabajar sobre varias imagenes/buffer sin duplicar funciones.
Lo de pasar las imagenes a .h es horrible. Cargar bmps, jpgs, gifs o png es realmente sencillo en C.
Cargar modelos 3d, tampoco es muy dificil, hay mucho codigo por la red, cargar un 3ds es trivial, pero es un formato bastante penoso actualmente...

¿Que estas creando de rasterizado que no tiene openGL?
Nunca me he encontrado ante algo 3D que no pudiese hacer con openGL...


El tema de buffers es chungo en wii/gc, hay 2 opciones a considerar:

1-. Trabajar en plano, como hacen casi todos, la imagen es X * Y, y pintamos como mentalmente/visualmente nuestro cerebro entiende...
Pero la GC no trabaja asi las texturas, lo hace en blques 4x4 por lo que siempre hay que hacer una ultima transformacion del buffer a textura antes de sacar por pantalla el buffer.
(Por cierto el 2D es un 2D falso, es un 3D ortogonal, con un plano que ocupa toda la pantalla en el que el buffer transformado es la textura de ese plano).

2-. Seria muy optimo, que el buffer fuese textura GC/Wii en bloques 4x4, para lo que todas las funciones de pintura tendrian que transformar las coordenadas X,Y en puntos dentro de esos bloques 4X4 que necesita la GC/Wii...


oyzzo, las texturas/imagenes han de ser 16bits de profundidad de color, o si las cargas en 32bits luego las transformas. Ademas la textura ha de transformarse en bloques de 4x4 para que sea compatible...

lo que no tiene openGL (al menos que yo sepa) es un sistema de rasterizado donde el plano de proyeccion no tenga que ser necesariamente ortogonal la direccion de vision. Por eso me gustaria trastear modificando los algoritmos de tinyGL

technik escribió:lo que no tiene openGL (al menos que yo sepa) es un sistema de rasterizado donde el plano de proyeccion no tenga que ser necesariamente ortogonal la direccion de vision. Por eso me gustaria trastear modificando los algoritmos de tinyGL

OpenGL es 3D completamente.

A partir de aqui depende de como establezcas la matriz de proyeccion tendras una perspectiva ortogonal o en perspectiva 3d segun el angulo que tu establezcas.
Los modelos se dibujan en el univeso, y luego a partir de la matriz de proyeccion se renderiza lo que tu ves en pantalla.

Si pones dos planos y una camara perpendicular a ese plano y el otro paralelo a la camara con vista ortogonal, obtienes el falso 2D. sobre el plano perpendicular y el plano paralelo es un linea en este tipo de camara (no lo ves)
Pero si tienes una vista 3D de la matriz de proyeccion, el mismo plano perpendicular no se vera 2D puro sino que se adaptara al 3D adecuado de la matriz, y el plano paralelo se vera como una pared de un pasillo a lo largo...


Si te entiendo bien, estas creando una matriz de proyeccion que no sea ortogonal, pero es que eso ya lo tiene openGL:

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0f,(GLfloat)width/(GLfloat)height,0.1f,100.0f);

Sasker, pues el problema que tengo con las texturas puede ser ese, pero no veo como solucionarlo... voy a hacer una cosa. Preparo un paquete y lo subo aqui en un rato, aver si entre todos lo sacamos lo que nose es si poner un hilo nuevo en el principal para que mas gente lo vea y nos pueda hechar una mano. Realmente funciona todo, lo unico k falta es eso de la textura que se ve rara y por la forma como se ve seguramente es lo que dices del 4x4.

te pego el codigo que uso para crear la textura, donde snoopy.h es la textura en formago GRRLIB.

glGenTextures(1, &texture[0]);
glBindTexture(GL_TEXTURE_2D, texture[0]);

glTexImage2D(GL_TEXTURE_2D,0,3,snoopy_width, snoopy_high,0, GL_RGB, GL_UNSIGNED_BYTE, &snoopy_img); //el problema puede estar aqui..

glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR); glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);

PD: De nombre para el engine voto por: Peanuts o Snoopy Peanuts son cacahuetes pero es el nombre de la serie donde sale snoopy y charly brown asi que quedaria gracioso con un cacahuete de logo tb se nota que me gusta snoopy?

Sube el codigo y le doy un vistazo.

De todas maneras como funciona TinyGL?
Me refiero a si es un emulador software de openGL, mas que nada pq la cube tiene soporte hardware de GL... se llama GX...

Pues esta claro que voy a tener que darle un buen repaso al openGL, por que no recordaba yo eso. Yo creia que la matriz de proyaccion era fija...
Pues me pongo manos a la obra
Muchas gracias Sasker, me acabas de ahorrar un par de dias de trabajo.

Sasker escribió:Sube el codigo y le doy un vistazo.

De todas maneras como funciona TinyGL?
Me refiero a si es un emulador software de openGL, mas que nada pq la cube tiene soporte hardware de GL... se llama GX...

Cierto, TinyGL es implementación por software ya que en wii aun no hay aceleración grafica por hardware (creo xD)

Pues aquí os cuelgo TinyGL-wii tal y como lo tengo ahora, que no funcionan las texturas y con algunos ejemplillos. Aver si Sasker ve lo de las texturas y podemos comenzar a hacer cosillas ya, como los cargadores de modelos y eso

link de descarga :
EDIT: la version que puse no compilava, he subido la buena a:
http://d01.megashares.com/?d01=d57326a


EDIT:
En examples/example5.c esta el ejemplo de texturas k es el que va mal, prueba eaxmple5.elf y veras lo que hace

Pues la ideas es excelente, sé muy poco de programación, pero me encantaría meterle mano a esto. El problema es que me confunden tantos términos, programas, librerías, etc.

Si puedo ayudar,quisiera saber qué necesito, digamos en términos de hardware; obviamente el wii, pero que más?¿Memoria SD, quemador DVD ? etc. ¿y Software? ¿emulador de wii? ¿librerias?

Y en verdad, si puedo, trataré de contribuir al menos con lo que me salga (si logro despertar mis neuronas).

Sasker me he pasado varios días trasteando el fuente de libogc y grrlib para darme cuenta de casi todo lo que tu has puesto. ¡¡Ya podías haber posteado una semanita antes!! jejeje

Las GRRLIB son un horror, u horreur como dirian sus creadores franceses. Para poner un sprite rotado un cierto ángulo calculan la rotación de cada pixel... ¿Por qué coño no giran el polígono donde va pegado el sprite?

Las funciones GX_* las he mirado pero no me entero de muchas de ellas, y eso que tengo algo de experiencia previa con OGL. Yo no diría que las GX son un soporte hardware de OGL, sino más bien que podría programarse una implementación de OGL muy optimizada usando las GX...

Por último ¿Qué es eso de que las texturas es mejor que estén en bloques de 4x4? ¿Podrias explicarlo con más detalle por favor? Si no tienes ganas de escribir te agradecería que al menos me facilitaras algún enlace donde se hable del tema... Ya puestos a pedir...

Muchas gracias.

bruslash escribió:Pues la ideas es excelente, sé muy poco de programación, pero me encantaría meterle mano a esto. El problema es que me confunden tantos términos, programas, librerías, etc.

Si puedo ayudar,quisiera saber qué necesito, digamos en términos de hardware; obviamente el wii, pero que más?¿Memoria SD, quemador DVD ? etc. ¿y Software? ¿emulador de wii? ¿librerias?

Y en verdad, si puedo, trataré de contribuir al menos con lo que me salga (si logro despertar mis neuronas).

Pues para programar se necesita el devkitPPC y libogc que estan en http://www.devkitpro.org. Ahi tb hay el emulador para probar los programas, se llama gcube, aunque es muuuuy lento :)

y para ejecutar los programas se necesita la wii, el juego zelda TP, una SD y un mando de gcube aunque ahora tb se puede con el wiimote :)

frontier escribió: Las GRRLIB son un horror, u horreur como dirian sus creadores franceses. Para poner un sprite rotado un cierto ángulo calculan la rotación de cada pixel... ¿Por qué coño no giran el polígono donde va pegado el sprite?

No veo que las GRRLIB sean un horror, para poner un sprite rotado un cierto angulo calculan la rotacion de cada pixel, porqu es así como se tiene que hacerxD si pones el sprite en un poligono, como dices, y lo rotas... que codigo dibuja eso rotado? se dibuja solo? No, habria que calcular el poligono y ademas rasterizar (pixel a pixel) el sprite en ese poligono. Sería mas costoso.

El inconveniente que ve sasker en que las imagenes estén en .h tampoco lo veo como un inconveniente, mas bien como una ventaja. Al tener la imagen en .h se compila con el binario, lo que quiere decir que es infinitamente mas rapido que cargar una imagen de disco (leer de disco >>>> leer de memoria) ademas es mas simple porque no tienes que tratar con memoria dinamica y la de bugs potenciales que te ahorras.

Es mas, para los modelos yo haría lo mismo, un conversor de un modelo cualquiera a .h en un formato que nos fuera bien, o directamente a listas openGL. Sería infinitamente mas rapido, y al ser 3D por software eso se va a notar mucho.

PD: sasker, yo tampoco acabo de entender lo que dices de 4x4

oyzzo escribió:No veo que las GRRLIB sean un horror, para poner un sprite rotado un cierto angulo calculan la rotacion de cada pixel, porqu es así como se tiene que hacerxD si pones el sprite en un poligono, como dices, y lo rotas... que codigo dibuja eso rotado? se dibuja solo? No, habria que calcular el poligono y ademas rasterizar (pixel a pixel) el sprite en ese poligono. Sería mas costoso.

Ningún código dibuja ese rotado. Lo hace el hardware de la tarjeta gráfica, o sea, que sí se rota solo.

Lo de rasterizar pixel a pixel se hacía en los tiempos del Quake I y similares. Con la llegada de las aceleradoras ese trabajo se transfirió al hardware. De hecho, las primeras aceleradoras eran básicamente máquinas de aplicar texturas. Como apunte el parámetro que mide la capacidad de rasterizar de una aceleradora se llama fill rate y me parece que se mide en texels por segundo.

frontier escribió:Ningún código dibuja ese rotado. Lo hace el hardware de la tarjeta gráfica, o sea, que sí se rota solo.

Lo de rasterizar pixel a pixel se hacía en los tiempos del Quake I y similares. Con la llegada de las aceleradoras ese trabajo se transfirió al hardware. De hecho, las primeras aceleradoras eran básicamente máquinas de aplicar texturas. Como apunte el parámetro que mide la capacidad de rasterizar de una aceleradora se llama fill rate y me parece que se mide en texels por segundo.

Cierto, ahi estoy totalmente deacuerdo contigo, pero te recuerdo que en WII aun no hay acceso a la gpu, así que todo se hace por software, como en los tiempos de quake 1. Si alguien saca drivers para la aceleradora grafica de la wii estoy deacuerdo en que será mejor hacerlo de otra manera, pero hasta entonces es lo que hay.

oyzzo escribió:
Cierto, ahi estoy totalmente deacuerdo contigo, pero te recuerdo que en WII aun no hay acceso a la gpu, así que todo se hace por software, como en los tiempos de quake 1. Si alguien saca drivers para la aceleradora grafica de la wii estoy deacuerdo en que será mejor hacerlo de otra manera, pero hasta entonces es lo que hay.

Si que hay acceso a la GPU, mira el archivo "gx.h" dentro de libogc. Las GRRLIB usan las funciones de ese archivo para pintar un único polígono que cubre toda la pantalla y que está texturizado con una imagen que contiene todos los sprites. Sería mucho mejor pintar un polígono independiente por cada sprite, ya que las rotaciones, los reescalados y las transparencias los haría el hardware. Por eso GRRLIB no es precisamente un ejemplo de librería currada...

frontier escribió:Si que hay acceso a la GPU, mira el archivo "gx.h" dentro de libogc. Las GRRLIB usan las funciones de ese archivo para pintar un único polígono que cubre toda la pantalla y que está texturizado con una imagen que contiene todos los sprites. Sería mucho mejor pintar un polígono independiente por cada sprite, ya que las rotaciones, los reescalados y las transparencias los haría el hardware. Por eso GRRLIB no es precisamente un ejemplo de librería currada...

Jur, voy a mirar gx.h aver si realmente usa la gpu de wii, (yo tenia entendido que no) porque si es así incluso seria una tonteria usar TinyGL... Seria mejor hacerlo de cero usando libogc.

solo posteo para daros ánimos y felicitaros por la idea.

y pienso que seria muy buena idea, para empezar a trastear en los juegos de Wii, portear alguno shooter tipo Doom, heretic, hexen,etc, etc, que se han portado a PSP, Xbox,NDS,etc,etc.

al menos para el funcionamiento del mando y cosas asi vendria muy bien,no?

oyzzo escribió:Jur, voy a mirar gx.h aver si realmente usa la gpu de wii, (yo tenia entendido que no) porque si es así incluso seria una tonteria usar TinyGL... Seria mejor hacerlo de cero usando libogc.

Bueno, podríamos usar TinyGL como una forma de aislarnos de la implementación. Es decir, si mañana cambiasen las funciones de acceso al hardware de libogc nosotros sólo tendríamos que cambiar la implementación de TinyGL, dejando el resto del código tal cual. Además , mientras un primer grupo de gente programa el motor usando la implementación actual de TinyGL otro podría ir mejorándola para que usase hardware. Es una forma de repartir el trabajo y al final uniendo ambas partes tendríamos un motor que usa el hardware...

Lo suyo seria modifical el Ogre3d
Con ello se podria crear un motort 3d para wii

Yo no soy programador pero si diseñador 3d y ya me he tocao algo el temad e juegos amateur

frontier escribió:Bueno, podríamos usar TinyGL como una forma de aislarnos de la implementación. Es decir, si mañana cambiasen las funciones de acceso al hardware de libogc nosotros sólo tendríamos que cambiar la implementación de TinyGL, dejando el resto del código tal cual. Además , mientras un primer grupo de gente programa el motor usando la implementación actual de TinyGL otro podría ir mejorándola para que usase hardware. Es una forma de repartir el trabajo y al final uniendo ambas partes tendríamos un motor que usa el hardware...

Tienes razon, ir haciendo el motor usando TinyGL por un lado
y por el otro lado ir acelerando por hardware TinyGL. O incluso hacer el motor usando TinyGL para que se puedan hacer juegos, y luego hacelerar TinyGL por hardware.

oyzzo escribió:Tienes razon, ir haciendo el motor usando TinyGL por un lado
y por el otro lado ir acelerando por hardware TinyGL. O incluso hacer el motor usando TinyGL para que se puedan hacer juegos, y luego hacelerar TinyGL por hardware.

Yo no sabia que se tenia accesoa la gpu de wii, siendo asi carece de sentido hacer todo el trabajo que yo estaba haciendo, habria que estudiar la compatibilidad entre tinyGL y las funciones de GX no valla a ser que luego nos toque cambiarlo todo para acelerar por hardware.
Mañana me pondre a estudiar mejor el tema.

yeladies escribió:Lo suyo seria modifical el Ogre3d
Con ello se podria crear un motort 3d para wii

Yo no soy programador pero si diseñador 3d y ya me he tocao algo el temad e juegos amateur smile_:P smile_[tomaaa]

El ogre3D es brutal (yo tambien he trabajado con el) lleva mas de 5 años de desarrollo y ha sido usado en multiples juegos comerciales (algunos incluso son disco de oro)
El problema es que eso es un trabajo de demasiada envergadura, probablemente eso se nos va de las manos. Ademas no sabemos si la wii seria capaz de mover semejante monstruo

No creo que carezca de sentido. TinyGL es la interfaz, el como esté implementada ya depende de cada sistema. Aunque cueste un poco encajar las GX y TinyGL creo que merece la pena el esfuerzo, porque después se podrán portar cosas con más facilidad, hacia Wii como desde ella.

He estado fuera todo el dia, mañana por la mañana contesto desde que deje el hilo...

Por encima, las GX es la implementacion GL via hardware GPU de la Cube, habria que crear un openGL mas extenso y traducirlo en llamadas a la GPU...
Se podria usar TinyGL??? Si, pero modificandolo para que usase hardware en lugar de software...


Lo de celdas de 4x4 de la Cube, no se pq es asi para las texturas, pero funciona asi...


Lo de tener las imagenes en .h y compiladas en binario es una aberracion... Imagina que creamos un juego 3d con texturas, con 100Mb en texturas ... vas a compilar 100Mb dentro del binario???
Hay que crear lectores de formatos graficos y modelos 3D.


Os ayudare en la medida de lo posible con la implementacion que quereis llevar a cabo, he programado motores en 3d direct3d y openGL. Ogre es un buen motor 3d, pero su 3d se implementa bajo openGL, por lo que primero habria que crear el wrapper openGL para poder portarlo.


Lo de rotar punto a punto es correcto, pero no es optimo, como dije del resto de cosas de GRRLIB, tengo la opinion que es un conjunto de funciones realida por gente con no demasiado conocimiento en programacion avanzada. Realiza todas las tareas que requiere para sus tests, pero no lo hace de forma optimizada...
La rotacion de lineas se hace utilizando una acumulacion de salto sobre Y, para no tener que recalcular todo el rato la rotacion, eso si se hace via software, pero rotar un cuadrado se hace en openGL de forma hardware sin gastar ni un 2% del tiempo que por softwware...

Esto me parece interesante y quiza nos sirva:
http://linux.wikia.com/wiki/GameCube_Linux/OpenGX

Pero esta en una fase poco avanzada como para usarlo y listo...

Hoy estuve curioseando las GX tratando de aclararme con el ejemplo del cubo. Os linkeo los fuentes por si acaso os puede aclarar algo echarle un vistazo.

acube
texture test

Perdona Sasker, pero lo de las texturas en bloques de 4x4 sigo sin pillarlo.

Te explico lo que creo haber entendido...


- Imaginemos una textura de 8x8 con los píxeles numerados para su identificación:

1 2 3 4 5 6 7 8
9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24
25 26 27 28 29 30 31 32
33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48
49 50 51 52 53 54 55 56
57 58 59 60 61 62 63 64


- El almacenamiento más obvio en memoria sería secuencial:

1 2 3 4 5 ... 62 63 64


- Ahora bien, según dices la GC/Wii usaría un esquema en bloques de 4x4... ¿asi?:

1 2 3 4 9 10 11 12 17 18 19 20 25 26 27 28 5 6 7 8 13 14 15 16 21 etc...


Por favor, corrígeme si me equivoco.



Creo que OpenGX es justo lo que necesitamos oyzzo, pero no creo que vaya a estar terminado para mañana... Mientras tanto podríamos ir tirando con una implementación software de GL, digo yo...

Pues openGX es lo que necesitamos, claramente pero me da la sensacion de que el proyecto esta un poco abandonado. Creo que los posibles caminos a seguir son:

1) usar gx.h y hacer el motor sobre eso.
positivo:
+ poder programar a partir de ya.
+ será algo mas rapido porque sino se tendria que llamar a funciones del motor, de ellas a funciones openGL y de ellas a funciones gx.

negativo:
- no se podran portar juegos ya existentes.
- el motor no se podrá portar a PC o a otras plataformas.

2) usar TinyGL por software para hacer el motor:
positivo:
+ openGL es conocido y documentado, se avanzaria mas rapido en el desarrollo
+ el motor se podrá portar a PC o a otras plataformas.
+ se podra aprovechar para portar juegos opengl ya hexos a wii.

negativo:

- Es mas lento, se tendria que reprogramar una parte importante de codigo para que tuviera aceleracion 3D.



Nosé, eso es mas o menos como yo lo veo, seguro que vosotros teneis varias opiniones. En resumen creo que eres tu quien tiene que escojer ya que has abierto el hilo y planteado el proyecto, yo voto a usar tinyGL y mientras uno va haciendo el motor, otro va metiendo codigo para que use aceleración hardware (como ha planteado frontier) o incluso usar solamente TinyGL y cuando esté completo el motor, ponernos a acelerar TinyGL para ganar velocidad y poder hacer mejores juegos.


realbrucest, gracias por los ejemplos les voy a hechar un vistazo y hacer alguna prueba con gx

Me encantan estas charlas tecnicas. Por momentos pense que estaba en beyond3d. Y eso q apenas he entrado.

No se si conoceis esto, pero os podría servir eventualmente:

http://www.gamasutra.com/view/feature/2945/shader_integration_merging_.php?page=1