G3D, una biblioteca - tutorial basica 3D para GP32

[Damizean]

Buenas madrugadas, por fin tras un par de semanas trabajando en ello, tengo el gusto de poder presentar una biblioteca 3D de propia cosecha para GP32, Ether 3D Graphics Library (gran oda a la originalidad >_>)

¿Pero eso que es lo que eees?: EGL es un motor 3D básico, cuyo objetivo es ser lanzada como una especie de "base" para motores mas complejos, incluyendo así todo el código libre y abundantemente comentado (para saber que pasa cada momento), como una documentación explicando el funcionamiento a grandes rasgos del motor 3D y descripciones de las funciones.

Y mas o menos que incluirá este... cosa: Ciñiendonos al objetivo de la biblioteca de ser lo más sencilla posible, solo seran añadidas las funcionalidades más basicas:

Todo renderizado en modo de 8 bits por pixel.
Operaciones básicas de vertices, matrices y planos.
Proyección 3D (naturalmente).
Rasterizado de triangulos wireframe, solidos, gouraud y texturas
Uso de una tabla de colores para poder conocer el color más cercano en la paleta de 8 bits (utilizado especialmente en el gouraud) (Porque se que manejar paletas en 8 bits es cansino).
Rasterizado de escenas mediante listas de triangulos (nada de strips).
Manejo y carga de Mallas (Formato propio, 3DM), Materiales (TGA) y Objetos.
Animación de mallas por interpolación de keyframes (¡como el Quake 2!).
Frustum Culling (El más basico posible) para rechazar lo que no está dentro del campo de vision de la cámara.
Posibilidad de renderizar el mundo en un buffer que no sea la pantalla (esto puede ser utilizado para diversos efectos como agua y demás).
Amor y todo eso.


¿Formato propio? >_< ¿Porque? ¿Y como pillo modelos?: Bueno, lo del formato propio es debido a que queria mantener la simplicidad del formato del MD2 y la capacidad de tener varios subobjetos en la malla que nos da el formato 3DS. Fear not! Además de la biblioteca también incluiré un pequeño conversor (opensource'd tambien) para poder convertir mallas en formato 3DS o MD2 al formato.

Hum, vale, y más o menos... ¿Cuando saldrá?: Pues, espero que el lanzamiento de la biblioteca pueda ser posible al menos en algun tipo de grado en un mes ( o más, dependiendo de lo que me cueste reorganizar el código y escribir toda la documentación ).

Ejemplo del código: La API de la biblioteca intentará ser lo mas sencilla e intuitiva posible. El código será algo del estilo:

void GpMain (void *arg)
{
// Inicializar core
coreInit ( CORE_66MHZ, "gp:\\gpmm\\Engine\\", 2000 ); // 66 mhz, ruta relativa, numero de triangulos máximo en pantalla

// Cargar paleta del mundo
paletteLoad ( "Palette.pcx" ); // Paleta estandar
paletteRecalculateColorTable (); // Recalcular tabla de colores aproximados

// Cargar malla de ejemplo
Mesh testMesh;
if ( !meshLoad3DM ( &testMesh, "Falcon.3DM" ) ) return;

// Crear objeto
Object testObject = objectCreate( &testMesh, 0, 0, 0 ); // Crea objeto con la malla y en la posicion 0,0,0

// Cambiar animación
objectChangeAnimation ( &testObject, "Idle" );

// Mover el objeto hacia el fondo
objectTranslate ( &testObject, 0, 0, intToFixed(230) );
objectRotateX ( &testObject, intToFixed( -20 ) );

// Loop principal
while ( !keydata.Start )
{
// Borrar pantalla
displayClear ( 0 );

// Recoger datos del control
keydataRead();

// Animar objeto
objectAnimate ( &testObject );

// Rotar objeto
objectRotateY ( &testObject, intToFixed( 4 ) );

// Borrar escena
sceneClear ();
// Añadir objeto a la escena
sceneAddObject ( &testObject );
// Renderizar
sceneRender ();

// Cambiar de página
displayFlip ();
}

// Liberar malla
meshFree ( &testMesh );
// Liberar core
coreFree ( );
}

Bue, pesao, ¿y podemos ver algo?: Fale, aquí tengo preparada una pequeña y estupida demo del Blue Falcon hecho por mi mismo, son unos 180 triangulos, son pocos, lo se, pero tambien he probado mallas de 800 y no va nada mal a 66mhz :D

http://img462.imageshack.us/img462/8089/bluefalcon0md.png

Descargar alphabetadeltagamma del engine con un modelo cutre y ciertos fallos graficos por culpa de que no uso un Zbuffer y ordeno las caras por la Z ponderada pero que me da igual :D (http://www.academiarpg.com/personal/damizean/descargas/engineWIP.rar)

Juro que mañana o pasado meteré una demo de un MD2 animado y con texturas (es que aun no he acabado la rutina de cargar texturas ( mejor dicho, no la he empezado, pero bien :D))

[playgoodstudios]

gamepark se tirara de los pelos al ver que los juegos de la scene gp32 tienen mejores 3d que los juegos de la gp2x XD

Animo!!!

[Puck2099]

Chapeau Damizean :brindis:

[Aiken]

Cojonudo tio! La caña de españa!

Has visto el proyecto "Wipeout" de ARCHER y compañia? Lo digo porque yo creo que ellos tambien se han programado sus propias rutinas para uso propio (no han dicho nada de sacar una libreria, que es lo que mas mola de tu proyecto) pero quizas podriais compartir ideas, optimizaciones u otras cosas ;)

Pues eso que chapeau! seguro que mas de uno se anima a programar cositas con esto.
Aiken :brindis:

[D_Skywalk]

Que wapo, nen [wei4]

Aiken, que sepa Damizean esta con ArChEr trabajando el engine, lo mas normal es que sea basicamente el engine del Wipe con todas las cosas que le ha ido metiendo el feo este xD

Por cierto, dami, ¿no hay que liberar testObject? xD

Un Saludo :*

[jjdrako]

wuuuaaauuu gracias por la libreria a ver si cada vez se ven cosas mejores :D

aiken si te fijas el archivo se llama enginewip, supongo que por algo sera :)

[Puck2099]

aiken si te fijas el archivo se llama enginewip, supongo que por algo sera :)

Ese wip no creo que sea por wipeout sino por work in progress :)

[Damizean]

Sí, basicamente es bastante parecido al motor de Archer (aunque no igual, ojo, este está hecho "from scratch" ) porque compartimos información y usamos unas tecnicas parecidas, (porque la verdad, no hay mucho más que rascar, el 3D es como es, 4 matrices y aplicar a todos los vertices y proyectarlos) aunque el tiene una forma distinta de como manejar las cosas de como la hago yo, por ejemplo:

Si no recuerdo mal, Archer utilizará un piscina para guardar la informacion de las mallas mientras que yo las guardo de forma local en las estructuras mesh. Ademas de que a la hora de describir los triangulos proyectados yo utilizo una piscina con una copia del vertice proyectado y el utiliza un indice.

Ademas tambien uso algun par de trucos tontos: utilizo una tabla precalculada de Cos/Sin/Tan con 360 vectores y interpolo los valores entre cada vector para que tenga mas precisión (no es tan rapido como acceder directamente a la tabla, pero si es mas rapido que calcularlos otra vez)

Y si, W.I.P. significa Work In Progress. :3

Edit: Acerca de lo de liberar el objeto, ese no hacia falta porque no tenia miembros que requirieran ser liberados (osea, que no tenia miembros que hubieran sido alojados con malloc).

[LTK666]

Tiene muy buena pinta, mucho animo con el tema. Una duda, es dependiente del SDK oficial?

[Damizean]

Sí en cuanto a la hora de acceder a la SMC y alojar cosas en memoria. Aparte de eso, lo demas es mas o menos independiente del SDK oficial.

[halb]

Ya lo he puesto en el otro hilo pero como viene al caso...
Si Archer tambien estaplanteando su propia libreria, de verdad no es mejor que os pongais deacuerdo y hacer una sola? dividiendo el trabajo entre varios sera mas rapido implementarla, no? y mas completa, vamos digo yo, vosotros sabreis, si vuestras posturas son irreconciliables (en lo que al engine se refiere :P). Yo me ofrezco a ayudar en lo que sea.

Ahora un par de cosillas, curiosidad y dudas:
- Tio, porque 8 bits en vez de 16? entiendo con flat shading ganas un poco de velocidad pero yo en las pruebas que he hecho con mi engine, o soy un inutil y no cojo el concepto o no consigo una mejora sustancial... y con 16 bits te quitas el engoro de paletas, etc... vamos, que cuales son las ventajas de ls 8 bits?
- No se si lo hable contigo o con Archer pero... veo que no quieres usar strips, me parece totalmente adecuado pero: usas una cache de bordes? si quieres un engine rapido creo que este es uno de los puntos fuertes. Si necesitas info o codigo te paso lo que quieras (si es que no lo tienes ya pensado o implementado)
(Quiza me enrollo demasiao porque como estoy liao con mi propio engine pero yo sigo)
- Has pensado en incluir cel-shading? si tienes wire y flat o gouraud... es sencillo y queda delux (segun mi opinion de freak).
- Has pensado en usar mipmapping para las texturas? la correccion de perspectiva es costosa pero el mipmapping me ha sorprendido lo sencillo de implementar que es y lo mucho que se nota en los resultados.

Bueno, se que quieres que sea sencilla pero bueno, yo digo, pregunto y propongo.
En fin, que me parece una idea genial lo de unas librerias para que la gente se pegue con ellas y exprimamos un poco mas a fondo la GP.

Salu2

[Electric Dreams]

Damizean, buen trabajo. Pero si vas a publicarla, antes de nada, hazlo bajo GPL. Es un consejo de alguien que ya se llevó una sorpresa.

Hice un programa para programar de forma sencilla unas máquinas registradoras Samsung y poco después me encuentro que lo venden con las máquinas... XD

Lo peor de todo es que como lo registre, me tuve que aguantar...

[Puck2099]

Damizean, buen trabajo. Pero si vas a publicarla, antes de nada, hazlo bajo GPL. Es un consejo de alguien que ya se llevó una sorpresa.

Hice un programa para programar de forma sencilla unas máquinas registradoras Samsung y poco después me encuentro que lo venden con las máquinas... XD

Lo peor de todo es que como lo registre, me tuve que aguantar...

¿Lo registraste?, ¿entonces por qué no les denunciste?

Por cierto, si la hace GPL también se puede vender sin recibir él un duro.

[Damizean]

Ya lo he puesto en el otro hilo pero como viene al caso...
Si Archer tambien estaplanteando su propia libreria, de verdad no es mejor que os pongais deacuerdo y hacer una sola? dividiendo el trabajo entre varios sera mas rapido implementarla, no? y mas completa, vamos digo yo, vosotros sabreis, si vuestras posturas son irreconciliables (en lo que al engine se refiere :P). Yo me ofrezco a ayudar en lo que sea.

Ahora un par de cosillas, curiosidad y dudas:
- Tio, porque 8 bits en vez de 16? entiendo con flat shading ganas un poco de velocidad pero yo en las pruebas que he hecho con mi engine, o soy un inutil y no cojo el concepto o no consigo una mejora sustancial... y con 16 bits te quitas el engoro de paletas, etc... vamos, que cuales son las ventajas de ls 8 bits?
- No se si lo hable contigo o con Archer pero... veo que no quieres usar strips, me parece totalmente adecuado pero: usas una cache de bordes? si quieres un engine rapido creo que este es uno de los puntos fuertes. Si necesitas info o codigo te paso lo que quieras (si es que no lo tienes ya pensado o implementado)
(Quiza me enrollo demasiao porque como estoy liao con mi propio engine pero yo sigo)
- Has pensado en incluir cel-shading? si tienes wire y flat o gouraud... es sencillo y queda delux (segun mi opinion de freak).
- Has pensado en usar mipmapping para las texturas? la correccion de perspectiva es costosa pero el mipmapping me ha sorprendido lo sencillo de implementar que es y lo mucho que se nota en los resultados.

Bueno, se que quieres que sea sencilla pero bueno, yo digo, pregunto y propongo.
En fin, que me parece una idea genial lo de unas librerias para que la gente se pegue con ellas y exprimamos un poco mas a fondo la GP.

Salu2

Veras, es que la filosofia de este engine difiere de la de Archer. Esta no plantea ser la creme de la creme de la optimizacion si no como un punto de comienzo para el desarrollo de otros, con una base simple pero funcional; mientras que la de Archer plantea estar optimizada y traer el mayor numero de tecnicas para que sea lo mas optimizada posible.

Eso no significa que no ponga mis 4 centimos en el engine de Archer, cuando se me ocurre algo se lo comento, pero Archer no necesita mucho más de mi ayuda. :)

En cuanto a los 16bpp, es algo que me planteo, pero no se que impacto tendrá en cuanto al rendimiento o en cuanto al consumo de RAM (ademas de que aun no he trabajado en 16bpp :o).

En cuanto al caché de bordes, ¿que quieres decir exactamente? :3

Bueno, el cellshading es relativamente sencillo (los bordes son faciles de hacer, dibujas la malla invertida y con un material negro para el reborde :o), pero se escapa de los objetivos de la biblioteca, igual que el mip mapping (aunque me gustaria tener información sobre este ultimo).

En cuanto a la licencia, no estoy seguro si usar GPL o LGPL, pero la verdad es que no creo que a la gente le gustara mucho que cuando modificaran el motor tuvieran que soltarlo...

Gracias por el interes mostrado :D

[halb]

Ok, comprendo lo que quieres hacer ;D

Bueno, si no has usado 16bpp (que realmente son 15bpp ;P) te recomiendo que lo uses, un poco mas de gasto de memoria pero que merece la pena por no tratar las paletas. Si quieres que el engine sea sencillo... mejor eso que tratar con paletas y mas si quieres gouraud.

Te cuento lo de la cache de bordes como simple tecnica 3D, aunque no la incluyas en el engine.
Para dibujar un triangulo calculas sus bordes, osea posicion de inicio, longitud y deltas de lo que interpoles, como la coordenada X (o Y dependiendo del sentido de los spans) o los colores RGB o lo que sea. Bien, pues la tecnica consiste en guardar los ultimos n bordes y cuando tienes que calcular un borde primero lo buscas en esa cache... aqui entra en juego el algoritmo de cache que uses. Yo personalmente lo que hago es precalcular si cada borde tiene coincidencia en la cache y lo guardo con la propia estructura de la malla. Un ejemplo:

Tenemos un rectangulo con dos triangulos que comparten un borde, y una cache de tamaño x.

0--1
| \ |
3--2

El primer triangulo se define como la tripleta (0,1,2) y sus match en la cache son (no_match, no_match, no_match).
El segundo triangulo se define como (0,2,3) y sus match en cache son (2, no_match, no_match).

Al tener que calcular bordes para el primer triangulo primero vemos sus "matchs", para el borde 0-1: no_match, lo calculamos y lo metemos en la cache (en posicion 0).
para el segundo borde 1-2:no_match, lo calculamos y lo metemos en la cache(posicion 1 de la cache)
para el tercer borde 2-0:no_match, lo calculamos y lo metemos enl a cache(posicion 2)
Para el segundo triangulo, (hay que tener en cuanta que es lo mismo un borde 2-0 que 0-2) primer borde 0-2: 2, cogemos el borde que hay en la cache en posicion 2, y con los otros bordes pues lo de antes, no_match se calculan y a la cache en las siguientes posiciones.


Esto requiere haber precalculado los "matchs" pero es algo sencillo que puedes hacer en la conversion del archivo o al cargarlo de disco. Requiere mas de memoria pero es una tecnica muuuuuy util y creeme acelera bastante puesto que la mayoria de bordes se calculan unicamente una vez en lugar de dos, y claro contra mas cosas interpolas entre vertices mas se nota esta tecnica en el rendimiento.

En fin, espero que entiendas el ejemplo aunque sea como curiosidad.

Lo del mipmapping pues si tienes una textura de M x N pues vas calculando sus mipmaps que son la misma textura pero reducida con ponderacion de los colores. Asi generas (M/2) x (N/2), (M/4) x (N/4) y asi las veces que quieras. luego eliges cual de los mipmaps usar como textura segun la distancia del triangulo (yo lo hago segun el tamaño de los deltas). Asi se consigue una mejor calidad en las texturas lejanas, mucha mayor contra mas lejos este.

Bueno, pues hasta aqui mi panfletos matutino, jejeje
Espero que te sea interesante aunque no te sea util ;P

[A.r.R.c.H.E.r]

Ese Damizean ahi! jejej seguro que te sale una libreria cojonuda! jejej espero que siguamos compartiendo ideas ya que mi engine no seria lo que es (o sera) gracias a ti, bueno y a una-i y ha Electric Dreams y a halb. Bueno que como veis en realidad nos ayudamos entre todos.

Respecto a lo de juntarnos y hacer un solo engine... pues la verdad que me atrae bastante la idea pero tendria que ser una agrupacion de 4 personas es decir... Damizean, halb (con sus tecnicas de optimizacion y 16 bits), Electric Dreams (optimizando en asm lo mas critico) y Archer que no hara nada jejej. Pues eso yo creo que de esta union saldria una muy buena libreria con calidad y potencia pero bueno cada uno tiene sus proyectos y supongo que sera dificil trabajar en grupo a ese nivel.


Resumiendo! felicidades Damizean por esa magnifica libreria y espero seguir dandote la bara por mucho tiempo con mis preguntas jajaj teluegooor!!

[Damizean]

Gracias por la explicación, es basicamente comprobar si comparten aristas y usar los mismos deltas, no? :) Bueno, ya he convertido el motor para que utilice 16bpp aunque he tenido que utilizar las estructuras del SDK de Gamepark en vez de punteros directamente hacia el buffer, pero va casi igual :/

¿Pero de verdad tanta calidad se obtiene con el mip mapping? :3 Tambien he estado pensando en que podria meter algun filtro para la textura como el filtro ese que utiliza el Unreal Engine cuando renderiza por software (el dithering, he estado leyendo un articulo y es una tonteria) que queda bastante bonito incluso en la pantalla de gp32...

Gracias halb! :D

See A.r.R.c.H.E.r, pero que dices si tu motor es mejóooo, ademas, yo ya no se mucho mas de lo que tu ya sabes :D

[theNestruo]

Ademas tambien uso algun par de trucos tontos: utilizo una tabla precalculada de Cos/Sin/Tan con 360 vectores y interpolo los valores entre cada vector para que tenga mas precisión (no es tan rapido como acceder directamente a la tabla, pero si es mas rapido que calcularlos otra vez)
Hola, campeón. ¿Porqué no hiciste una tabla de 256 o 512 entradas? Así te ahorrarías un módulo entre 360 (una división).
Por lo demás, enhorabuena por tus progresos; siento no haberlos podido vivir más de cerca. Mándame a mi correo de gmail el source que quiero echarle un vistazo (no te voy a plagiar nada; no te preocupes).
Saludos a todos; espero podais tener pronto noticias mías ;) ¡Nos vemos!

[una-i]

Ok, comprendo lo que quieres hacer ;D

Bueno, si no has usado 16bpp (que realmente son 15bpp ;P) te recomiendo que lo uses, un poco mas de gasto de memoria pero que merece la pena por no tratar las paletas. Si quieres que el engine sea sencillo... mejor eso que tratar con paletas y mas si quieres gouraud.

Jeje yo tambien voto por los 16bpp, las operaciones de color se pueden hacer bastatne optimas iguallmente.



Lo del mipmapping pues si tienes una textura de M x N pues vas calculando sus mipmaps que son la misma textura pero reducida con ponderacion de los colores. Asi generas (M/2) x (N/2), (M/4) x (N/4) y asi las veces que quieras. luego eliges cual de los mipmaps usar como textura segun la distancia del triangulo (yo lo hago segun el tamaño de los deltas). Asi se consigue una mejor calidad en las texturas lejanas, mucha mayor contra mas lejos este.

Y como bonus, el mipmapin tambien acelera bastante, porque aumente los acirtos de cache sobretodo si no usas texturas con swizle.

En resumen mipmaping mola :P

Unai.

[mortimor]

Saludos a todos; espero podais tener pronto noticias mías ;) ¡Nos vemos!

Dichosos los ojos paisano :p

Esa frase me deja intrigado ;)

[Damizean]

Hola, campeón. ¿Porqué no hiciste una tabla de 256 o 512 entradas? Así te ahorrarías un módulo entre 360 (una división).
Por lo demás, enhorabuena por tus progresos; siento no haberlos podido vivir más de cerca. Mándame a mi correo de gmail el source que quiero echarle un vistazo (no te voy a plagiar nada; no te preocupes).
Saludos a todos; espero podais tener pronto noticias mías ;) ¡Nos vemos!

Lo estuve pensando y es como probablemente lo deje al final, asi para redondear solo tendria que usar una máscara (obviamente bastante mas rapido) :3 En cuanto al source te lo enviaré en cuanto lo tenga un poco mas limpio, ¿ok? (y sobre lo de plagiar, joer macho, que hay confianza, coñe, se que tu nunca harias algo asi, ademas de que seguro que no te interesaria, son las cosas basicas xD)

Y hamigos, ya está cambiado el motor para que use 16bpp (aunque ya lo dije antes) :D Y esto me lleva a una pregunta.... alpha blending anyone?

-Deus

P.D. ¿Texturas con swizzle?

[anibarro]

Da gusto ver a gente hacer cosas con tantas ganas, alargando mucho la vida de la GP32 ^^ Muchas gracias y aqui me espero hasta que salgan esos motores XD

[una-i]

Y hamigos, ya está cambiado el motor para que use 16bpp (aunque ya lo dije antes) :D Y esto me lleva a una pregunta.... alpha blending anyone?

-Deus

P.D. ¿Texturas con swizzle?
si en vez de tener en memoria las texturas por lineas horizontales las tienes en "bloquezitos" de 4x4 o 8x8 tienes mchos mas aciiertosd e cache, esto se suele notar tipicamente si tienes una textura "girando" en la pantala, mientras estas pintando la textura "igual" que esta en memorri todo ok, a medida que la textura va girando cada vez hay mas saltos de un pixel al siguiente y seve como los fps suben y bajan dependiendo de la orientacino de la textura.

Para operaciones de color en la gp32 mira mis libreris de sprites hay funciones de suma,resta y blend de colores en 5551 y 55515551 (dos colores de golpe)

Unai.

[Makoe]

Todos os entendemos... Cuanto nivel hay aki **** , que ignorante soy. Y yo que apenas se tontear en fenix.

[WinterN]

Jo, cuando uno lee estas cosas se da cuenta de lo que mola hacer un motor en 3D, y el reto que supone. Bueno, yo hice uno propio, en J2ME, pero no llegué demasiado lejos, aunque más de lo que me esperaba. :D

[Damizean]

Se avecinan problemas :o

Tenemos un problema: parece ser que la libreria SLL tiene problemas de precision con alguna de sus funciones (y lo mas seguro es que sea con la que calcula la aproximacion de 1/x) y este problema hace que las texturas del triangulo no funcionen correctamente.

E aqui una comparación de la version de PC utilizando floats y la version de GP32 de la misma rutina utilizando SLL:

http://img477.imageshack.us/img477/8918/pc3dd.png http://img477.imageshack.us/img477/2119/gp327hd.png

Si alguien sabe de alguna posible solucion...

Edit: Confirmado que el error está en la funcion para calcular el 1/x, acabo de substituirlo por una version usando floats y funciona perfectamente:

http://img461.imageshack.us/img461/9196/usandofloats8eb.png

Entonces... alguien sabria calcular el 1/x mas aproximado posible o puede aportar alguna solucion? He pensado en la posibilidad de utilizar una tabla precalculada, pero quizá nos puliriamos la ram...

[jjdrako]

te refieres a que te guarde mas decimales?? porque no metes la parte entera en una variable y la parte decimal en otra??

[Wave]

Mmm, deberias buscar informacion sobre un metodo de calculo para resolver equaciones de manera incremental, ahora no requerdo el nombre...

[Damizean]

Bueno, ultimos cambios sobre el motor:

Estoy reescribiendo el motor para estructurarlo mucho mejor.
Esta vez usaré variables de 32 bits, con 16 bits de precision. Deberian ser mas que suficientes siempre que no nos pasemos con la escala de los modelos.
Tras hablar con una-i, he decidido usar tambien una tabla para calcular el inverso de los números usando la parte entera, y interpolando la parte decimal, tal y como lo hago con la tabla de Cos/Sin/Tan.
Las tablas de Cos/Sin/Tan han pasado a ser de 512 vectores, así será mucho menos costoso redondear el numero, tan solo tendremos que usar una mascara.
Supongo que en cuanto pasen estos dias y apruebe el examen practico del coche, me pondré a ello mucho mas profundamente :)
¡Ah! El nombre ha cambiado a Ether 3D Graphics Library.
Talue!

[Ralph007es]

te refieres a que te guarde mas decimales?? porque no metes la parte entera en una variable y la parte decimal en otra??

Eso, venga procesos, como sobran... :? tiene que haber otra opcion...

[amkam]

Bueno, ultimos cambios sobre el motor:

Estoy reescribiendo el motor para estructurarlo mucho mejor.
Esta vez usaré variables de 32 bits, con 16 bits de precision. Deberian ser mas que suficientes siempre que no nos pasemos con la escala de los modelos.
Tras hablar con una-i, he decidido usar tambien una tabla para calcular el inverso de los números usando la parte entera, y interpolando la parte decimal, tal y como lo hago con la tabla de Cos/Sin/Tan.
Las tablas de Cos/Sin/Tan han pasado a ser de 512 vectores, así será mucho menos costoso redondear el numero, tan solo tendremos que usar una mascara.
Supongo que en cuanto pasen estos dias y apruebe el examen practico del coche, me pondré a ello mucho mas profundamente :)
¡Ah! El nombre ha cambiado a Ether 3D Graphics Library.
Talue!


Good Work!

PD: Como se nota cuando uno tiene tanto tiempo pa rascarse los huevos , eh ? ; )

[Damizean]

Pues... sí, la verdad.

[bulbastre]

Watt the FAQ ease mimapping?

[Damizean]

Es generar texturas de mas baja calidad (mas pequeñas) para acelerar el rendimiento y evitar el efecto de onda cuando una textura está lejos.

[amkam]

Es generar texturas de mas baja calidad (mas pequeñas) para acelerar el rendimiento y evitar el efecto de onda cuando una textura está lejos.

Que se usan para aquellas texturas mas lejanas o mas abatidas (a no ser que se suba mucho el mipmapping)