Hola a todos,
aquí os dejo una utilidad, un modulo .prg que tiene un PROCESS llamado make_3dit ( )
Ese PROCESS te permite usar: file, graph, x, y, z, angle, size en Bennu 3D exactamente igual que en Bennu 2D, de forma que no tienes que preocuparte de la extraña sintaxis de Bennu 3D.
Aquí un ejemplo de un proceso que usa 3Dit y se mueve, rota, escala, avanza y cambia de gráfico (Textura) usando únicamente las variables LOCAL de Bennu:
PROCESS dummy ( )
BEGIN
make_3dit ( );
file = load_model ( "model/ogre/ogre.md2" );
graph = load_texture ( "model/ogre/ogre001.pcx" );
LOOP
// Moving test along x,y,z axis
IF ( key ( _Q ) )
x++;
ELSEIF ( key ( _E ) )
x--;
END
IF ( key ( _R ) )
y++;
ELSEIF ( key ( _F ) )
y--;
END
IF ( key ( _Z ) )
z++;
ELSEIF ( key ( _X ) )
z--;
END
// Rotation test along y axis
IF ( key ( _A ) )
angle -= 1000;
ELSEIF ( key ( _D ) )
angle += 1000;
END
// Resize test along x,y,z (uniform)
IF ( key ( _C ) )
size++;
ELSEIF ( key ( _V ) )
size--;
END
// Advance test
IF ( key ( _W ) )
advance3d ( 4 );
ELSEIF ( key ( _S ) )
advance3d ( -4 );
END
// Change texture test
IF ( key ( _1 ) )
graph = load_texture ( "model/ogre/ogre001.pcx" );
ELSEIF ( key ( _2 ) )
graph = load_texture ( "model/ogre/ogre002.pcx" );
ELSEIF ( key ( _3 ) )
graph = load_texture ( "model/ogre/ogre003.pcx" );
END
FRAME;
END
END
Y aquí puedes descargar el ejemplo, incluye todas las dll de Bennu 3D, el bgdc, bgdi, con todas las últimas versiones, un RunWin.bat con todo listo para compilar, ejecutar e incluso modificar:
DESCARGAR: http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.0.0.zip (http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.0.0.zip)
Así que disfrutadlo!
Guau! 3D fácil!! Ahora ya no tengo escusa para meterle mano al 3D!! Gracias Windgate!
Por cierto, veo que angle sólo gira en el eje Y, le podrías meter angle_x, angle_y y angle_z
para darle más posibilidad de movimiento, y size_x, size_y y size_z para estirar (aunque
igual no es muy útil de normal, pero bueno...)
Sencillísimo añadir eso, también reutilizaré flags o xgraph para manejar los estados de animación de modelos .md2, controlando que la asignación del mismo estado no provoque un reseteo en el estado de animación, cosa que es tediosa en Bennu 3D pero que con este modulito se puede dejar 100% transparente al programador, que le parecería que está trabajando con toda la amigabilidad del jodido Bennu 2D.
Lo dicho, si gusta saco nueva versión porque ya la tengo en mente, y a ver si nos vamos pasando al 3D ya hombre, que por falta de recursos no será :P
MATADLO A KARMAS!!! +1!!!
Mmm... pero hagas lo que hagas, ¿has pensado en como controlar la animación con las locales de bennu?
wow! impresionante!
pregunta, esto trabaja sin cargar el modulo de video de bennu, cierto? sino genera conflictos entre ambos modulos, es correcto esto?
debo decir que esto es fantastico.
gracias, y te llevaste un karma... ya sin probarlo... ahora lo probare...
Ya has pensado cómo hacer las animaciones? Has dicho algo sobre el tema que no he entendido, utilizando xgraph y flags, aunque no veo la conexión de dichas variables locales con animaciones en 3D...
Ya tengo hecho el control de la animación, facilísimo, uso flags, es que no encuentro otra variable que tenga más relación... xgraph es un POINTER y sería más incordioso... Aunque se podría hacer un mem_alloc... En breve subo la nueva versión, dejadme cenar y tomar una cervezuela :D
wait... como es eso que no encuentras variables? tu modulo deberia ser independiente, crear sus variables y no usar las del video, es mas, no se deberia cargar el modulo de video o si este se carga no deberia usar las mismas variables...
como sea, buen trabajo, voy a ver si lo pruebo de una vez...
En verdad eso es todo cierto xD
Pero no es un módulo en si, sino un "módulo" para Bennu hecho en Bennu! xD
Deja de cenar y de beber cabrón!!! (con cariño)... Y saca ya nueva versión con mejoras rectales :P
Reutilizo las LOCAL ya existentes en Bennu para evitar añadir nuevas LOCAL. No veo eficiente abusar de las LOCAL y más aún sabiendo que las que hay no tienen utilidad alguna en Bennu3D.
El módulo de video lo tengo que cargar necesariamente, Bennu3D necesita un set_mode (mod_video) para dibujar la ventana de ejecución.
¿A qué conflictos te refieres Splinter? Fíjate que file y graph toman valores que no corresponden a ningún fpg/map existente, y por tanto no dibujan nada en el buffer 2D, el resultado 3D se muestra correctamente. Esto lo afirmo porque ya hice la prueba y si dibujas en el "buffer de Bennu 2D" y en el "buffer de Bennu 3D" a la vez tienes un parpadeo incesante :D
El módulo funciona muy bien ahora mismo. Quiero subir la nueva versión con el control de animaciones, pero no sólo eso si no que además voy a intentar añadir una función gravity ( ) que con una sóla llamada se ocupe de resolver las colisiones con el mapa... A ver si lo termino para hoy porque después de un día de perros me espera una noche de perros solucionando unos asuntos diversos :(
Informaré, y gracias por los karmas, lo he enseñado a algún alumno joven y ha dicho que le gustaría trabajar el 3D así :D
mientras no se carguen graficos de la forma habitual no tendras problemas... ahora si cargas graficos de bennu, puede que en algun momento haya conflicto...
las locales graph, file, etc, de bennu se crean cuando usas alguno de los modulos de video... si no los usas esas locales no existen, entonces vos podes definir las que quieras...
como sea, cuidado, porque al tener esas variables valor, el runtime de bennu ejecuta y asume un monton de cosas, que no te haya dado problemas ahora no significa que no los de... esta no es la forma prolija de hacerlo...
por otra parte, es un modulo en C o es un modulo en PRG?
ya veo... es un prg! estaria bueno hacerlo en C como un engine grafico...
muy ingenioso... ;)
Claro, asumo que no se utilizará load_png ni ninguna instrucción de ningún módulo de Bennu que genere maps, ya que cualquier proceso que por casualidades del destino termine con cierto valor de file y cierto valor de graph puede empezar a provocar cosas raras...
En cualquier caso, para carga de maps he creado load_texture, que los carga como texturas para Bennu3D exclusivamente. Como limitación veo que lo más problemático sería intentar combinar buffer de 2D para un menú y luego pasar a buffer 3D... Tengo por ahí un ejemplo en el que probé algo así.
¿Para tener esto en C la opción sería recompilar Bennu o se te ocurre alguna otra cosa Splinter? Ya sabes que propuse hace tiempo un "Bennu para niños" y eso va por el mismo camino :D
Bien, de momento aquí dejo la nueva versión, primero la captura:
(http://trinit.es/DescargaDirecta/Bennu3D/3Dit/02.02.10.png)
Ahora hay gestión hipersencilla de animaciones. Basta con asignar a flags valor 0 para quieto, 1 para andar, 2 para... Consultad la documentación de Bennu3D en el directorio /doc, hay 16 estados de animación distintos en cada modelo md2.
También he añadido en beta la función gravity ( ) que gestiona con una sóla llamada las colisiones con un mapa de terreno, el código resultante con cambio de animación en gravedad apenas se nota.
Y una función load_terrain que carga en una sóla instrucción un mapa de alturas y su textura asociada, devolviendo un identificador.
El nuevo código para implementar todo esto supone 4 sencillísimas lineas de código más (
En negrita no puedo ponerlas en negrita) mirad:
PROCESS dummy ( )
BEGIN
make_3dit ( ); // Makes de process compatible with 3dit, let it use local 2d Bennu variables
// Loads a model file and a texture file
file = load_model ( "model/ogre/ogre.md2" );
graph = load_texture ( "model/ogre/ogre001.pcx" );
gravity ( map , 10 ); // Note that map is a GLOBAL with the terrain map loaded with load_terrain
LOOP
// Moving test along x,y,z axis
IF ( key ( _Q ) )
x++;
ELSEIF ( key ( _E ) )
x--;
END
IF ( key ( _R ) )
y++;
ELSEIF ( key ( _F ) )
y--;
END
IF ( key ( _Z ) )
z++;
ELSEIF ( key ( _X ) )
z--;
END
// Rotation test along y axis
IF ( key ( _A ) )
angle -= 2000;
ELSEIF ( key ( _D ) )
angle += 2000;
END
// Resize test along x,y,z (uniform)
IF ( key ( _C ) )
size++;
ELSEIF ( key ( _V ) )
size--;
END
// Advance and animation test
IF ( key ( _W ) )
advance3d ( 4 );
flags = 1;
ELSEIF ( key ( _S ) )
advance3d ( -4 );
flags = 1;
ELSE
flags = 0;
END
// Change texture test
IF ( key ( _1 ) )
graph = load_texture ( "model/ogre/ogre001.pcx" );
ELSEIF ( key ( _2 ) )
graph = load_texture ( "model/ogre/ogre002.pcx" );
ELSEIF ( key ( _3 ) )
graph = load_texture ( "model/ogre/ogre003.pcx" );
END
FRAME;
END
ENDDESCARGA: http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.0.1.zip (http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.0.1.zip)
Juer, pues esto si que es útil, cada día simplificándonos más la vida a los ignorantes de la tercera dimensión (mira, mamá, soy un dibujo animado ;D).
Lo miraré más tranquilamente cuando tenga tiempo. Karma++.
el usar las variables reservadas del motor hace que el motor tenga trabajo extra, porque va a pensar que tiene un grafico, va a intentar obtener el grafico y sus caracteristicas y va a intentar muchas cosas mas... entre las cuales es dibujarlo...
yo usaria otras locales, podria algo asi como _3d_file, _3d_model, _3d_x, _3d_y, _3d_z, _3d_angle_x, _3d_angle_y, _3d_angle_z, _3d_size... etc... o algo similar, pero diferente de las ya usadas... quizas con poner _file, _graph o _model, etc... alcanza, pero ponerle 3d o algo deja mas claro a que se refiere
y no se podría independizar del todo bennu3d de mod_video?
Si solo depende de set_mode, quizas se podría reimplementar dentro de bennu3d.
Bennu3D puede ser que necesite también set_fps? (que también está en mod_video). No sé muy bien las cosas de mod_video que necesita...
De todas formas me imagino que habría que intentar quitar mod_video como dice DCelso. Aunque se utilicen otros nombres que empiecen por _3d_, los procesos van a seguir estando ahí, todos en la posición [0, 0], pero el mod_video va a intentar repintarlos y tal (creo, no conozco los detalles de la implementación)...
De todas formas, sería gracioso ver por donde "rondan" los gráficos reales en 2D de este módulo en ejecución... en plan yo me estoy dando de balazos con un nazi a dos palmos de mí pero los procesos realmente están uno en Pamplona y otro en Jaén disparando cada uno para un lado xD
Por cierto, Bennu3D admite transparencias? Algo leí en la página de Trinit de que estabas intentando poner transparencias a las animaciones de agua y oleaje que estabas haciendo... Porque a mi "flags" me sugiere o espejados (lo que no tiene mucho sentido teniendo rotaciones en los 3 ejes) o transparencias. Si admite transparencias/semitransparencias estaría chulo usarlo para poner modelos de fuego y agua tal (lo dice uno que no tiene ni idea de 3D, igual esos efectos se hacen de otra forma) :D
Tenéis razón en lo que decís, reutilizar las LOCAL de 2D implica trabajo extra, pero ya de por sí está visto que para Bennu 3D quedan "residuos" del 2D que a largo plazo habría que pulir. Lo de independizar el set_mode (Y set_fps que también se usa) podría ser un gran paso, por ejemplo hacer que Bennu 3D tuviese uno propio.
(Ahora recuerdo que funciones como map_get_pixel que requieren file y graph son útiles en 3D, y path_find, entre otras... Así que ojo)
Bennu 3D admite transparencias, pero por ahora sólo he encontrado un flag de transparencia 50% para los modelos 3D... En otros elementos como los emisores de partículas (Para el fuego y tal xD) sí que se puede poner un alpha. De todas formas los emisores de partículas no los he explorado a fondo, lo justo me he peleado para tener distintos efectos de fuego, humo y alguna chorradita más, pero no tengo una documentación como para saber exactamente qué es lo que hay que poner para simular sangre... Tiempo al tiempo.
Voy a hacer una cosa chicos:
Voy a probar rendimiento en fps y memoria usada tal y como está el módulo ahora y con LOCALs definidas por mí. Invocaré varios cientos de dummys con posiciones aleatorias y así de paso pruebo la estabilidad, os informo :P
flags=4 es transparencia 50% :)
Te dejo un par de sugencias pa posteriores (aunque no he visto aún la última versión y no sé si las has metido):
1. Cámara manual o que siga a un personaje (creí ver en el manual que hay funciones en Bennu3D para ello)
2. Colisiones con otros procesos como la de Bennu2D, con función tipo if(collision3d(type ogro))...
(eso ya no sé si está en Bennu3d... pero de todas formas eso es de matrícula de honor xDD)
La cámara con movimiento es una parida, tengo vectores de ellas con distintos funcionamientos, fijas de seguimiento automático, controlables... Todo en un módulo independiente que puedo reutilizar, ya lo meteré, pero lo considero de momento algo ajeno al módulo actual, que todavía no está listo.
La colisión en Bennu 3D está recién implementada, es "parecida" a la de 2D, con la limitación de que hay que especificar los 2 procesos implicados (No el conjunto de procesos), por lo que habría que hacer una iteración y comprobar y/o apoyarse en la existencia de un grid (Cómo me gustan) para acotar las comprobaciones. Como te digo, no la he probado aún pero he de hacerlo próximamente, ya tengo pensado como la "portaré" a 3dit para que sea como la collision de Bennu 2D y soporte conjuntos de procesos. Gracias por la sugerencia Grisendo, próximo paso a seguir :D
En cuanto al rendimiento con reutilización o no de LOCAL, sinceramente lo veo exactamente igual, para 1001 procesos Dummy, juzguen ustedes mismos:
Rendimiento reutilizando las LOCAL de Bennu:
(http://trinit.es/DescargaDirecta/Bennu3D/3Dit/03.02.10%20local%20recycle%201000%20test.png)
Rendimiento creando nuevas LOCAL y sin usar las de Bennu:
(http://trinit.es/DescargaDirecta/Bennu3D/3Dit/03.02.10%20new%20local%20test%201000%20dummy.png)
Cabe destacar que la memoria usada se queda en casi la mitad y los fps suben ligeramente si uso OpenGL (Las pruebas son con Direct3D9 para que funcione hasta en los PC más mierdosos).
He probado a no importar mod_video ni establecer modo de video y fps, sale en ventana 320x240 y el rendimiento no cambia un ápice.
He intentado no importar mod_proc omitiendo el exit, pero Bennu 3D lo requiere, lo mismo con mod_text.
Conclusión: Veo exactamente igual reutilizar o no, pensaré por dónde seguir, se trata de que sea lo más sencillo y similar a bennu 2D posible... Me ha extrañado que con nuevas LOCAL ocupe un poco más de memoria, debería ser al revés :S
1) en maquinas poderosas no vas a sentir mucha diferencia de rendimiento...
2) con las locales del mod_video te ocupa mas memoria
1001 procesos dummy? Eres un puto bestia :) al final vamos a tener que implantar algún módulo de CUDA para que revientes la gráfica con bennu...
Qué gracia! El windows semen te marca que bgdi trabaja a 32 bits xDD
¿Y por qué no? aun no hay versión 64 bits ¿o si? ;D
Yendo al tópico: hombre, se verá que usa unas cuantas locales más (o menos, no se, no he contado las variables que se crean en una y otra librería), no debería verse afectado el rendimiento... bueno, salvo por las comprobaciones gráficas que haga internamente Bennu, a osea, una vez por ciclo ver que no existen los gráficos apuntados por file+graph, pero vamos ¿que ocupa eso? ¿12 ciclos por proceso?
Tampoco es tan bestia tener 1001 procesos, aunque sean 3D: cuando edito niveles para el juego tengo más de 6000 activos (he pasado los 7000), el doble cuando trabajo con dos mapas :D :D :D
Bien, vamos a dejarnos de chorradas y vamos a probar con 32000 o algo así, aunque la saturación en Bennu 3D llega por CPU y va a ser brutal comparada con la saturación que pueda suponer la presencia de LOCAL que afecten internamente a la ejecución...
También voy a probar a lanzar 32000 procesos que "no hagan nada" más que FRAME para comprobar diferencias de carga a ver si sale algo significativo de "un 10% más de algo".
Informo :P
Quote from: Drumpi on February 03, 2010, 06:23:11 PM
¿Y por qué no? aun no hay versión 64 bits ¿o si? ;D
Yap, pero me refería a que me hace gracia que Windows 7 (lo tendrás de 64 bits me imagino) diga que ese proceso es una aplicación de 32 bits, no sé si Vista 64bits también lo hacía o no. :) Yo nunca lo había visto hasta ahora...
Quote from: Drumpi on February 03, 2010, 06:23:11 PM
Tampoco es tan bestia tener 1001 procesos, aunque sean 3D: cuando edito niveles para el juego tengo más de 6000 activos (he pasado los 7000), el doble cuando trabajo con dos mapas :D :D :D
Joder, creo recordar que DIV tenía un tope (una constante) de máximos procesos que podías ejecutar, y creo que era muchísimo más pequeño que eso (y entonces me parecía una barbaridad...). Yo hasta hoy en DIV/Fenix/Bennu no sé si he pasado alguna vez de lanzar 20 procesos simultáneos!!! :D
Espero con ansias versiones nuevas... parece que éste era el empujón que necesitaba para pasarme a las 3D!!
Breve apunte: Con 32000 procesos las cosas siguen igual, no hay ninguna diferencia apreciable de rendimiento ni de comportamiento, 2% menos memoria consume SIN reutilizar las locales...
Quería hacer más cosas pero no he podido, mañana más.
PD: Lo he enseñado a unos alumnos y lo han pillado al vuelo :D
a que te refieres con eso de 32000 procesos no hay diferencias? rendimiento o memoria?
Quote from: grisendo on February 03, 2010, 07:39:09 PM
Quote from: Drumpi on February 03, 2010, 06:23:11 PM
¿Y por qué no? aun no hay versión 64 bits ¿o si? ;D
Yap, pero me refería a que me hace gracia que Windows 7 (lo tendrás de 64 bits me imagino) diga que ese proceso es una aplicación de 32 bits, no sé si Vista 64bits también lo hacía o no. :) Yo nunca lo había visto hasta ahora...
Quote from: Drumpi on February 03, 2010, 06:23:11 PM
Tampoco es tan bestia tener 1001 procesos, aunque sean 3D: cuando edito niveles para el juego tengo más de 6000 activos (he pasado los 7000), el doble cuando trabajo con dos mapas :D :D :D
Joder, creo recordar que DIV tenía un tope (una constante) de máximos procesos que podías ejecutar, y creo que era muchísimo más pequeño que eso (y entonces me parecía una barbaridad...). Yo hasta hoy en DIV/Fenix/Bennu no sé si he pasado alguna vez de lanzar 20 procesos simultáneos!!! :D
Espero con ansias versiones nuevas... parece que éste era el empujón que necesitaba para pasarme a las 3D!!
Bennu siempre ha sido 32bits y siempre se ha ejecutado a 32 bits. Ahora ya hay un montón de programas que funcionan a 64bits, pero cuando empezó Bennu, eso era una tecnología aun en desarrollo.
Es más, Bennu (y Fenix tampoco) no usa ni aceleración HW, imagina ;D Ya se habló de los problemas que había para pasar a 64 bits (no creo que sea dificil de encontrar el hilo).
Y si, lo mío es una salvajada, pero es un editor que hice cuando no tenía ni idea de punteros, y usa mi primer motor de scroll tileado (snif). Por desgracia, no tengo dos meses para reescribirlo y meterle el motor actual, otro gallo cantaría.
ONTOPIC: hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta. Drumpi me ha pedido tu ip, Windgate, ¡PARA NO ENTRAR NUNCA EN TU ORDENADOR! :D :D :D
Quote from: Drumpi on February 04, 2010, 02:32:47 AM
Bennu siempre ha sido 32bits y siempre se ha ejecutado a 32 bits. Ahora ya hay un montón de programas que funcionan a 64bits, pero cuando empezó Bennu, eso era una tecnología aun en desarrollo. Es más, Bennu (y Fenix tampoco) no usa ni aceleración HW, imagina ;D Ya se habló de los problemas que había para pasar a 64 bits (no creo que sea dificil de encontrar el hilo).
Soy un incomprendido!!! O me expreso con el orto, una de dos... jaja. Me refería a que no sabía que Windows 7 te avisaba de qué procesos eran de 32 bits... :)
Ontopic: Ayer trasteé con el bicho, metí otro personaje-3d-proceso pero no consigo matarlo con signal (y en el proceso mato a su make_3dit porque si no luego tira error de que no encuentra al padre), supongo que habrá que usar algo para quitar el modelo md2, porque se queda ahí justo donde lo mato animándose :) ... No sé si has hecho algo al respecto, pero a lo mejor vendría bien que al igual que haces lo de "si el padre no tiene file, no hago nada", algo como "si el padre está muerto, borro sus datos de 3d y me suicido"
Gran sugerencia Grisendo.
Bennu 3D no es como Bennu 2D. Te sorprenderá, pero no es necesario un proceso activo para que el "graph" se mantenga en pantalla, aquí un sólo proceso puede gestionar miles de modelos a la vez.
Pero con una comprobación de si el padre muere en el proceso make_3dit ( ) y un ONEXIT encargado de destruir todo lo que ha creado sería suficiente. Gracias por su sugerencia y K++
Más sugerencias bienvenidas, esta última ha sido grande, estoy testeando ya con alumnos y no quisiera encontrarme con tremendas cagadas inesperadas como esta :S
- Añadida la funcionalidad de auto-remover el modelo cuando el proceso muere.
- Distintas funcionalidades de 3dit separadas en distintos módulos brevísimos.
- Añadido módulo para añadir cámaras estáticas y de autoseguimiento sencillísimas (p.ej add_follow_camera ( ogre ) donde ogre es el id de proceso a seguir).
- Añadido un doc con pruebas de rendimiento, probé a checkear cambios de valores antes de posicionar,rotar,escalar, el rendimiento empeora, supongo que las funciones 3D ya se encargaban de comprobar antes de cambiar.
- Añadido un Readme (En inglés) con instrucciones de uso, limitaciones, etc.
El código del dummy ya no realiza los test que ya estaban re-probados y funcionaban, el código que tiene movimiento, animación y gravedad queda así de sencillo:
PROCESS dummy ( )
BEGIN
make_3dit ( ); // Makes de process compatible with 3dit, let it use local 2d Bennu variables
// Loads a model file and a texture file
file = load_model ( "model/ogre/ogre.md2" );
graph = load_texture ( "model/ogre/ogre001.pcx" );
gravity ( map , 10 ); // Note that map is a GLOBAL with the terrain map loaded with load_terrain
LOOP
// Rotation test along y axis
IF ( key ( _A ) )
angle -= 2000;
ELSEIF ( key ( _D ) )
angle += 2000;
END
// Advance and animation test
IF ( key ( _W ) )
advance3d ( 4 );
flags = 1;
ELSEIF ( key ( _S ) )
advance3d ( -4 );
flags = 1;
ELSE
flags = 0;
END
FRAME;
END
ENDDESCARGA: http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.0.2.zip
EDIT: Por cierto, no recuerdo si añadí la prueba de 32K dummys:
(http://trinit.es/DescargaDirecta/Bennu3D/3Dit/03.02.10%2032K%20dummys.png)
Ah! Se me olvidó comentarte, la gravedad lo que hace únicamente es mantenerte pegado al suelo, no? Porque hice un proceso-proyectil y estaba todo el rato al nivel del suelo, quité lo de "gravity" y entonces ya funcionó. Te paso el código que hice, por si te sirve o ves que no he entendido algo bien:
Código que aplica movimiento parabólico a un proceso, entradas: "proceso" - proceso a aplicar la parábola, "v0" - velocidad de lanzamiento, "a0" - ángulo del tiro con respecto al suelo, "b0" - ángulo de tiro izquierda-derecha (es decir, a donde está mirando el que lo lanza).
[code language="bennu"]PROCESS tiroParabolico3D(proceso, v0, a0, b0)
PRIVATE
float t;
float x0, y0, z0;
BEGIN
t=0;
x0=proceso.x;
y0=proceso.y;
z0=proceso.z;
LOOP
proceso.x=x0+v0*cos(a0)*sin(b0)*t;
proceso.y=y0+v0*sin(a0)*t-(9.8*t*t/2); // 9.8m/s^2, o la gravedad que se quiera con un CONST
proceso.z=z0+v0*cos(a0)*cos(b0)*t;
t+=0.2;
IF(proceso.y<0)
signal(proceso, s_kill_tree); // TREE para matar al make_3dit, pero los objetos 3d se quedan ahí...
BREAK;
END
FRAME;
END
END[/code]
Y el proceso bala:
[code language="bennu"]PROCESS bala(x,y,z)
BEGIN
make_3dit();
// Sin gravity, o si no no vuela!!
file=load_model("model/bullet/bullet.md2");
graph=load_texture("model/bullet/bullet.pcx");
LOOP
FRAME;
END
END[/code]
Forma de lanzarlo:
[code language="bennu"]tiroParabolico3D(bala(personaje.x, personaje.y, personaje.z), fuerza, angulo, personaje.angulo);[/code]
La idea es buena grisendo, tenía en mente algo así pero pensaba basarlo en herencia, se hereda la rotación del emisor del disparo para que el tiro vaya en esa dirección, posiblemente reutilice tu código para la parábola, que es buena idea.
En cuanto a lo de matar el proceso con y<0 mejor usaré una función de cálculo de la altura del terreno en un punto, aunque eso implicaría que el terreno sea parámetro... No es bueno asumir la presencia de globales... Ya veremos como queda, de momento la eliminación de modelos al matar procesos debería funcionar con la 0.0.2
Próximos objetivos:
- Gestión de modelos hijos: Poner armas y tal, además de disparos y otras modelos que heredan.
Detección de colisiones para los muy muy burros :D
Ok, reutiliza lo que quieras sí, y lo del y<0 era solo como prueba cutre (soy un poco maniático con la limpieza de memoria). Pero la idea es... debería funcionar la parábola con gravity o no? Lo digo porque vale, en este caso lo omites y ya está, pero en el caso de un personaje como el dummy que la utiliza para moverse por el suelo, si quieres hacerlo saltar, se podría?
La gravity gestiona la y de forma que hagas lo que hagas con ellas la gravity es la que manda...
Para tener parábolsa no hay que poner gravity, hay que hacerla tú a mano o meter física con gravedad.
Es que es una historia compleja, actualmente la llamada gravity es un simple manejador rápido de colisiones con el terreno, por lo que mantiene los elementos pegados al terreno sin más.
Ya haré algo al respecto tranqui, en el tema de colisiones todavía no he terminado de investigar.
Guapo, guapo, guapo esto del 3D... He probado la nueva versión, por fin desaparecen los muñecos 3D al matar su proceso correspondiente! :)
He notado cierto "atascamiento" en la animación de andar, pero debe ser porque estoy usando wine, el otro día utilicé windows con la segunda versión y funcionaba perfecto.
He de confesar una cosa, soy tan vago que mi personaje dispara lo primero que pillé por internet de md2: delfines (http://telias.free.fr/models_md2_menu.html) xDDD Bennu3D también carga como .obj, .3ds y tal, no?
Sí, se lo traga todo Bennu 3D, te dejo la última versión de la documentación que estoy preparando, están todas las funciones descritas, en español, al 95% porque algunas todavía no he podido probarlas a fondo. También vienen los formatos soportados y alguna cosita más:
http://trinit.es/temario/Lista%20Funciones%20Bennu%203D.pdf (http://trinit.es/temario/Lista%20Funciones%20Bennu%203D.pdf)
No es el 3dit, es el Bennu3D puro y su sintaxis es más fea que el Fary comiéndose un limón, pero bueno, cosas peores he visto.
Ayudenme ustedes por favor.
Como ya sabéis, la función make_3dit ( ) es la que prepara cualquier proceso para ser compatible con 3Dit y responder a las modificaciones en sus variables locales:
x,y,z - posición en 3D.
angle - rotación (En milésimas de grado) en el eje y.
size - tamaño en tanto por ciento, en los 3 ejes.
file - modelo 3D.
graph - textura.
flags - estado de animación.
El caso es que tengo un problema con flags:
Cuando cargamos una md2 flags = 0 se ocupa de asignar el estado "quieto" y flags = 1 asigna el estado "andar", pero resulta que si cargamos un modelo que no sea .md2 el programa da un error de ejecución al intentar aplicar animación md2 a un modelo que no la soporta (p.ej una esfera).
De momento voy a tomar una solución que espero se pueda mejorar:
Los procesos tendrán flags = -1 de serie y serán ellos los que deban asignar flags = 0 para que comiencen en estado quieto. Mientras flags valga -1 no se aplicará ninguna animación para evitar ese problemita...
Si alguien se ha enterado de algo y puede echar un cable se agradece :P
EDIT: Pregunta fácil:
He determinado que es necesario "avisar" a 3Dit si se trata de un modelo .md2 animado o de otro tipo de modelo estático:
¿Qué os parece más razonable?, ¿Que haya que asignar siempre flags = 0 a los modelos md2 para que 3Dit se encargue de dejarlos quietos o que haya que asignar flags = -1 a los modelos estáticos para que 3Dit no se moleste en aplicarles animación? :S
Y OTRO EDIT: Ahora estoy con el módulo de herencia, de forma que un proceso disparo (Por ejemplo) pueda tomar la posición y rotación de su padre y sólo preocuparse de avanzar, así:
PROCESS shoot ( )
// Inheritance test getting position and rotation from father
BEGIN
make_3dit ( );
get_father_position ( );
get_father_rotation ( );
file = M8E_LOADSPHEREMODEL ( 10 );
LOOP
advance3d ( 10 );
FRAME;
END
END
El caso es que he comprobado que cuando un proceso se encuentra sobre un terreno siempre se obtiene de él la posición y=0. Esto me impide poder heredar correctamente la y del padre... Una solución "cutre" sería obtener la altura del terreno en el punto donde se encuentra el padre, pero no sería correcto asumir que hay terreno porque puede no haberlo, ni sería limpio tener una GLOBAL donde guardar el terreno si lo hay... Quizás sea un fallo de Bullet, ya que a mi manera de verlo M8E_GETPOSMODEL debería obtener la posición real, ya se encuentre sobre un mapa de terreno o se encuentre bajo los efectos de un animador de movimiento... Creo que voy a mandar un mail a l1nk a ver qué me dice :( agradezco ideas, creo que no voy a hacer nada más con 3Dit hasta resolver estas 2 últimas dudas, son peludas...
Solucionado el extraño problema de animación, ahora a los modelos estáticos no se les aplica animación :D pero ahora es necesario que se asigne un valor a flags para indicar el estado de animación inicial de todo modelo md2, en otro caso realizan todas sus animaciones, esto sucedía así también en Bennu3D así que no perdemos nada.
(http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3dit_06-02-10_18h20m25s.png)
Añadido:
- Gestión de modelos hijo con add_to_father ( ) que se ocupa automáticamente de seguir las animaciones, movimientos, rotaciones, etc. del padre y mueren con él.
Módulo de captura de screenshots que las nombra automáticamente con la fecha.
collision EXACTAMENTE igual que en Bennu 2D, pero ahora en 3D :O
Todo modelo cargado ahora tiene asociado el id del proceso que lo gobierna, vendrá bien a largo plazo para usar collision.
Carga fácil de cielo, ya veréis qué belleza...
Recién comenzado un módulo de trabajo con la GUI que implementará un write_var exactamente igual que el de Bennu 2D pero en 3D.
Diversas mejoras puntuales...
DESCARGAR: http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.0.4.zip (http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.0.4.zip)
Nueva versión:
http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.1.2.zip (http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.1.2.zip)
El módulo de GUI ya está terminado, implementa write_gui ( ), write_var_gui ( ), delete_text_gui ( ) con un funcionamiento idéntico a Bennu 2D, incluido el manejo de all_text para borrar todos los textos.
Nuevo módulo de rendimiento para 3dit, tiene una función make_efficient ( ) que puede ser lanzada por un proceso y se encarga de ocultar su modelo cuando se encuentra a cierta distancia global CAM_FAR. También otra función única optimize_fps ( ) que evalúa el FPS y se encarga de reducir CAM_FAR cuando no se alcanza cierto % del fps deseado y subirlo gradualmente hasta el valor original de CAM_FAR en caso contrario, cojonudo xD
Solucionados los problemas para distinguir modelos estáticos y animados que comenté hace 2 posts.
Próximos objetivos:
Un módulo de sonido que hará que todo play_wav ( ) lanzado por un proceso que tiene cargado un modelo calcule su posición respecto a la cámara y utilice el estéreo para dar sensación espacial.
Al igual que ocurre en Bennu 3D, en la carga de texturas 3Dit no se preocupa de controlar si la textura ya ha sido cargada previamente, había planteado tener una lista/árbol de búsqueda que obtenga/añada el id de la textura cargada dependiendo de si es la primera vez que se carga... Como se imaginarán esto será a largo plazo, ya que la lista/árbol sería algo dinámico y primero tendría que hacer un módulo de uso general para ello.
Una función saltar que se ocupe del salto sin complicaciones adicionales... Aunque para esto necesitaré una pequeña ayuda de l1nk3rn3l y Prg, uso terrain maps y ya he leído varias veces que el salto es prácticamente incompatible con ellos.
muy buen trabajo windgate... imagina que teniendo esto modulo desde codigo bennu, es muy simple armar luego un modulo C que evite tener que hacer el proceso auxiliar, etc... todo desde el core...
nuevamente, muy buen trabajo...
¿Sugieres modificar Bennu para que integre esta "cosa", hacer una variante de Bennu o una simple .dll de Bennu?
No sería mala idea empezar a meterme con el código fuente de Bennu con este proyecto como motivación... :D
modificar no, hacer un nuevo modulo... (modulo = dll, lo que siempre debio haber sido la bennu3d)
Quote from: Windgate on February 08, 2010, 08:15:28 AM
Nueva versión:
http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.1.2.zip (http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.1.2.zip)
El módulo de GUI ya está terminado, implementa write_gui ( ), write_var_gui ( ), delete_text_gui ( ) con un funcionamiento idéntico a Bennu 2D, incluido el manejo de all_text para borrar todos los textos.
Nuevo módulo de rendimiento para 3dit, tiene una función make_efficient ( ) que puede ser lanzada por un proceso y se encarga de ocultar su modelo cuando se encuentra a cierta distancia global CAM_FAR. También otra función única optimize_fps ( ) que evalúa el FPS y se encarga de reducir CAM_FAR cuando no se alcanza cierto % del fps deseado y subirlo gradualmente hasta el valor original de CAM_FAR en caso contrario, cojonudo xD
Solucionados los problemas para distinguir modelos estáticos y animados que comenté hace 2 posts.
Próximos objetivos:
Un módulo de sonido que hará que todo play_wav ( ) lanzado por un proceso que tiene cargado un modelo calcule su posición respecto a la cámara y utilice el estéreo para dar sensación espacial.
Al igual que ocurre en Bennu 3D, en la carga de texturas 3Dit no se preocupa de controlar si la textura ya ha sido cargada previamente, había planteado tener una lista/árbol de búsqueda que obtenga/añada el id de la textura cargada dependiendo de si es la primera vez que se carga... Como se imaginarán esto será a largo plazo, ya que la lista/árbol sería algo dinámico y primero tendría que hacer un módulo de uso general para ello.
Una función saltar que se ocupe del salto sin complicaciones adicionales... Aunque para esto necesitaré una pequeña ayuda de l1nk3rn3l y Prg, uso terrain maps y ya he leído varias veces que el salto es prácticamente incompatible con ellos.
je je, no había leido reciente mente el tema... has avanzado mucho :)
el salto ya es compatible con los terrenos, si usas la gravedad m8e_addcolterrainfast o algo así, solo tienes que poner a true el parámetro para saltar, y luego ya puedes moverte por el eje "y" como siempre, si lo pones en false no te puedes separar del piso. también hay nuevas funciones para saber si colisionas con el piso en mapas que no son terrains y para saltar. también puedes usar la función de obtener altura de terrain en una coordenada para hacer tu propia gravedad. :)
Oh, Bennu3D debió ser una .dll desde el principio... Malditos errores de base que se arrastran hasta el infinito y más allá... Pensaré lo de la .dll, aunque al hacer uso de las funciones del m8ee.h, ¿Será posible invocarlas desde C para hacer la .dll?, ten en cuenta que lo que hago es enmascarar las funciones de Bennu 3D dejando algunos parámetros bizarros como constantes de 3Dit y/o asociando varias para hacer una función más sencilla de usar.
Y Prg: Te acabas de ganar un karma amigo, el parámetro que me dices que debe ser FALSE se llama glueEnable y tenía pensado que indicaba si el personaje debía quedarse pegado o bien deslizarse por la pendiente... Mil gracias de verdad...
no, lo que digo es que bennu3d debio ser desde siempre con variables locales y orientado a procesos...
eso es lo que me refiero... bennu3d siempre fue una dll...
lo que digo es que ese enmascaramiento, hay que hacerlo desde C... pero, como nunca tuve tiempo de meterme a trastear con el 3D y que siempre que pregunte nadie me supo responder... ahora tu lo has hecho, con esto has escrito a alto nivel lo que deberia ser la capa de bajo nivel...
sigue con eso, esta excelente, que luego lo podemos mejorar con C... pero necesitamos (yo) saber como manejar el API de bennu3D, cosas que tu estas haciendo a la perfeccion...
Hay algunas funciones que enmascaro y son ultra-mega-simples, por ejemplo:
FUNCTION int load_model ( string path )
BEGIN
RETURN M8E_LOADANIMODEL ( path )
END
¿Se podría empezar por ahí?, ¿Usas CodeBlocks?, con CodeBlocks sé comenzar un proyecto para hacer una .dll, pero lo que me resulta peludo (como a muchos) es importar la gran cantidad de dependencias de los paquetes de Bennu (Que si el sdl, que si zlib, que si otros tantos que puedes descargar de mil sitios y hay distintas versiones...).
Me gustaría mucho hacerlo, por ahora he descargado las fuentes de Bennu 3D de la web de l1nk3rn3l, es un proyecto CodeBlocks en el .cpp principal reconozco BASTANTES cosas, ¿Crees que se podría partir de ahí?
tu solo encargate de seguir con este proyecto, yo con tiempo pondre mi granito de arena y lo convertire a C, con makefiles como Dios manda.
CodeBlocks es para las niñas... :D
Yo recomendaría que fuera linkernel quien lo portara (o remaketara o como se diga) ya que es el que conoce a la perfección la librería 3d :D. O al menos conteis con él :D.
Jurl, uso CodeBlocks, he probado con otros entornos y suelo terminar teniendo más errores que líneas de código :S ok, sigo con el 3Dit, hay un puñado de cosas más que quiero meterle.
Sí que contaríamos con l1nk, por supuesto, aunque está complicado encontrarlo disponible últimamente :( sobre conocer la librería: Ayer mismo sin ir más lejos descubrí gracias a Prg que un parámetro de la función de colisiones con el terreno no tenía el uso que yo pensaba xD
vamos que hace años que le vengo diciendo a l1nk3rn3l que haga un modulo de esta forma... quizas por falto de tiempo o por rendimiento, no tenemos un bennu3d con esta orientacion...
pero si Windgate lo hizo (y funciona), creo que se puede hacer... para este modulo en C, con lo que windgate haga es mas que suficiente de conocimientos sobre la lib, esto no va a quitar que se sigan empleando comandos bennu3d, pero gran parte estara orientada a procesos... lo mas importantes para esto es saber como usar los callbacks de manera eficiente, para que el engine se integre, analice y renderice sin tener que hacer un M8_RENDER o lo que sea, que lo haga automatico, ante cambios, y sin que el usuario se tenga que preocupar... eso es lo que mas atencion debe prestarse en el momento de pasarlo a C...
Y ni hablar que hay que deshabilitar cosas de BennuGD para obtener el maximo rendimiento.
Por otro lado, todas las libs usadas en Bennu3D son portables 100%? en que plataformas las tenemos disponibles?
El M8E_RENDER se realiza una vez por FRAME, ahora mismo la función config_video ( ) se encarga de mantener ese bucle, por lo que si inicializas el video te despreocupas de todo y sólo tienes que poner modelos en pantalla.
Ahora mismo Bennu3D está en Windows y hay una versión para Linux que no he podido probar ya que soy esclavo de un Windows 7... Estoy en vías de tener un pendrive con Ubuntu y Bennu, con eso podría verificar si está disponible y tiene la misma funcionalidad que la versión de Windows.
PD: Ya hay salto que funciona MARAVILLOSAMENTE, y las locales size_x, size_y, size_z que se comportan como en 2D, valen 100 por defecto y en el primer momento que se usa una de ellas se ignora size, que es heredado por las demás. En breve habrá angle_x, angle_y, angle_z de la misma forma, con una función advance3d que se encargará de tener en cuenta el avance en todos los ejes, será delicioso para juegos de aviones donde las rotaciones pueden ser diversas.
Juer, hace un par de días me dio por pensar en hacer un Kario, y cada vez que te leo me dan más ganas ¡no me tortures! ;D
Aquí la nueva versión con salto y size, size_x, size_y, size_z funcionales:
DESCARGA: http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.1.5.zip
Ojalá a alguien le apetezca probar el control dinámico de la distancia de render en función del fps, que se ajusta automáticamente para que no baje de 50fps... Estoy por hacer como con el propio Bennu3D varios TEST para que se vea cada cosa por separado xD
Nueva versión, tras varias pruebas de rendimiento y discusiones con SplinterGU queda determinado que el número de subprocesos no afecta al rendimiento NADA. Sólo os digo que los proyectos de Bennu 3D que estoy empezando los estoy haciendo partiendo de esta plantilla, es la polla con cebolla.
Aquí os dejo la última versión, tiene un programa de prueba sin mucha complicación, con gestión de movimiento, rotación, animación y colisiones con un mapa.
DESCARGA: http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.2.0%20test.zip
Como novedad principal, ahora hay unas LOCAL llamadas position, rotation y scale, que son structs con las componentes x,y,z, de tipo float, que afectan a la posición, rotación y tamaño en 3 dimensiones.
También un nuevo proceso mouse_gui ( ) que pone el gráfico que pases como parámetro como ratón en la GUI.
Numerosas mejoras y cambios, toda una maravilla para todo aquél que quiera introducirse en el diseño de videojuegos en 3D, hasta mis alumnos más jóvenes han conseguido pasarse de 2D a 3D de forma casi inmediata.
Dejo aquí la última versión, numerosos cambios y mejoras:
- Funciones para avanzar, desplazarse lateralmente, subir y bajar sea cual sea la rotación 3D del proceso.
- Sonidos con volumen variable según la distancia.
- Clonado de modelos para evitar acceso a disco.
- Documentación actualizada y ampliada.
Modificaciones en progreso:
- Una variable como ctype para indicar si el posicionamiento/rotación es relativo al mundo o al modelo.
- Gestión hiper-fácil de la física de Bullet.
- Terrenos tileados.
- Introducirlo adecuadamente en el motor de Bennu 2.0 como algo definitivo :D
DESCARGA: http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.3.1.zip
Gracias!!
Quote from: Windgate on May 03, 2010, 12:08:17 PM
- Introducirlo adecuadamente en el motor de Bennu 2.0 como algo definitivo :D
Espero ansioso ese día, ya sea introducirlo en Bennu o en Bennu3D.
Y no te quepa duda que el día que me pase al 3D usaré este "motor", y no creo que falte mucho, porque todos los usos que se me ocurren del wiimote implican movimiento en el espacio tridimensional ^^U
Posicionamiento relativo y absoluto 100% funcionando, lo que permite movimiento y rotaciones libres fácilmente, para haceros una idea se puede programar una flecha que recorra una parábola, un pájaro, un avión con giros de 360 grados...
Etiquetada como versión 0.4 ya que el cambio es significativo.
Otra mejora interesante, aunque no está totalmente acabada, es la inclusión de varias GLOBAL que almacenan colores básicos (rojo, verde, cyan, blanco...) y se pueden pasar como parámetros a las funciones de escritura de textos.
También se ha mejorado un poco la documentación, todas las funciones disponibles están en /3dit/3dit_declare.prg
DESCARGA: http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.4.0.zip (http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.4.0.zip)
karmita para el windgate!
Bien caballeros, ahora traigo la mejor versión sin duda hasta la fecha:
- Integrada la física de Bullet con funciones para tontos, con un par de instrucciones ya tienes funcionando la física de colisiones de objetos con el escenario.
- Añadidos programas de test para todas y cada una de las utilidades de 3Dit, incluida la física de Bullet, funciones de GUI, etc.
- Revisión completa de todos los módulos y mejoradas varias de las funcionalidades ya existentes.
http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.5.0.zip (http://trinit.es/DescargaDirecta/Bennu3D/3Dit/3Dit%200.5.0.zip)
Os pediría probar los tests a ver si veis algo que se pueda mejorar.
Ejemplo de uso de la física de Bullet para que se vea lo fácil que es:
init_phys ( ); // Inicializa el motor de física de Bullet
terrain_phys ( map ); // Aplica física al terreno dado como parámetro
make_phys ( ); // Aplica física al proceso que invoca esta función
¡A colisionar!
karma!
viene con ejemplos?
Sí, 5 ejemplos que prueban todas y cada una de las utilidades, todavía falta portar alguna cosa más como las partículas y saldrá un ejemplo más.
Los .prg con ejemplos que hay ahora mismo son:
test_effects.prg
Tests all fog and fade effects
test_gui.prg
Test all GUI and 2D functions
test_model1.prg
Test camera and basic model loading and removing
test_model2.prg
Test texturing and animated model controls and physics
test_model3.prg
Test models collision and inheritance
test_model4.prg
Test particles and advanced physics
Lo he probado y esta genial lo unico que he echado en falta ha sido la key_event.lib que hizo SplinterGU que estaría bien tenerlo ya metido.
karma++
Quote from: JMP on July 21, 2010, 07:38:55 PM
Lo he probado y esta genial lo unico que he echado en falta ha sido la key_event.lib que hizo SplinterGU que estaría bien tenerlo ya metido.
karma++
Me lo apunto :P
Ahora mismo estoy pensando que windgate es una especie de Dios, y si alguien la porta a wiz......
¿En Canoo va el motor 3D?, ¿Alguien se atrevería a probar?
Hay 5 modos de render, en teoría 2 de ellos van por soft...
Tengo alguna mejora lista en esta librería, incluída la key_event de SplinterGU y alguna cosa más... También de redes con la librería nueva de l1nk que está de lujo :D
Si no esta portado como quieres que lo prueben xDDDD
Oh, en cuanto a eso, ¿No funciona con las .so de Linux?
He tenido una Wiz un par de días en mis manos y la verdad nunca me fijé, pero sí sé que las RC de Wiz van a parte e imagino que será por eso, vale :(
¿La librería de redes de l1nk va en Linux? No sé porqué me suena que no...
no wind, comparten el codigo fuente, pero los binarios son diferentes.
La librería de l1nk la tengo en .dll y he revisado varias veces su repositorio y no he visto prácticamente nada para Linux...
En cuanto a los binarios para Wiz, tengo entendido que la Bennu3D fue portada a Linux, no creo que costase mucho pasarla para Canoo y probar.
Quote from: Windgate on November 04, 2010, 01:53:48 AM
La librería de l1nk la tengo en .dll y he revisado varias veces su repositorio y no he visto prácticamente nada para Linux...
Es una lástima. Para mí eso es un problema. Porque utilizar por ejemplo la Fsock u otra...¿no sería buena idea?
La librería de l1nk por ahora es lo mejor que he visto, ya que automatiza completamente el protocolo de tráfico de datos. No digo que sea la solución perfecta para todo, pero es muy "Bennu", ya que prácticamente se comparten las variables entre distintos clientes casi automáticamente.
bueno la libreria de red , es 100% compatible con linux, se incluyen los fuentes
para algun voluntario...
Quote from: Windgate on November 04, 2010, 01:53:48 AM
La librería de l1nk la tengo en .dll y he revisado varias veces su repositorio y no he visto prácticamente nada para Linux...
En cuanto a los binarios para Wiz, tengo entendido que la Bennu3D fue portada a Linux, no creo que costase mucho pasarla para Canoo y probar.
Puede costar más si la Caanoo soporte OpenGL ES en lugar de OpenGL.
En cuanto a la otra librería... si alguien me pasa el código, me imagino que la podré compilar para Linux.
la caanoo usa opengl es.
No hay ningun gadget portatil que soporte el OpenGL padre, o tienen la version GLES 1.0 o la reciente 2.0, esta ultima es la que se esperaria en una nueva portatil de GPH, ya que permite muchas mas cosas/efectos de rendering.
Pues entonces no sé cómo de posible será...
si lo he notificado en varios post y nadie se ha animado(no tengo linux, ni canoo, ni gpx, asi que no puedo portarlo)
de nuevo alguien se anima?
https://irrlicht.svn.sourceforge.net/svnroot/irrlicht/branches/ogl-es/
http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=40133
http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?t=34035
de todas maneras no esperes hacerte un quake3 y que te corra a 400fps en una consola con estandar (opengles)
si alguien lo prueba y me lo pasa , y lo subo a la pagina de bennu3d, ;D
Ya se ha comentado hace tiempo, ya existe un yeti 3d portado a wiz, igual te seria mas fácil adaptarlo a Bennu.
Free, deberías leer lo que pone debajo del avatar supergigante de L1nk ;D
Drumpi, se me olvidaba :)
Bueno, pero tu no tenias ahora tiempo de sobra !? ;D
Quote from: FreeYourMind on November 04, 2010, 09:14:14 PM
Drumpi, se me olvidaba :)
Bueno, pero tu no tenias ahora tiempo de sobra !? ;D
jajaja, como estamos hoy!
Quote from: FreeYourMind on November 04, 2010, 09:14:14 PM
Drumpi, se me olvidaba :)
Bueno, pero tu no tenias ahora tiempo de sobra !? ;D
Eso creía, pero ahora me paso las mañanas buscando convertirme en "working class", ayudando en casa o comprando (y no juegos, precisamente).
Y por las tardes la cosa no mejora: crap-compo (una vez más, me meto yo solito en unos "fregaos" de tres pares de narices, sólo diré que he tenido que echar mano hoy del motor de scroll tileado, y es sólo 1/5 del motor del juego) y 100º juego paperactivo para antes del día 15 (quería haber terminado el Mortadelo, pero me iba a llevar más de la cuenta y he tenido que empezar otro de cero, ya os contaré).
Quote from: josebita on November 04, 2010, 02:04:31 PM
En cuanto a la otra librería... si alguien me pasa el código, me imagino que la podré compilar para Linux.
Se puede obtener de aquí:
http://code.google.com/p/otherfenixbennuprojects/downloads/detail?name=BennuPlayNet.rar&can=2&q=
Por lo que he visto, está en C++
En cuanto a esa librería l1nk, tengo un par de dudas, pero me parece que estamos discutiendo en el hilo incorrecto :D
Quote from: osk on November 05, 2010, 03:14:31 AM
Quote from: josebita on November 04, 2010, 02:04:31 PM
En cuanto a la otra librería... si alguien me pasa el código, me imagino que la podré compilar para Linux.
Se puede obtener de aquí:
http://code.google.com/p/otherfenixbennuprojects/downloads/detail?name=BennuPlayNet.rar&can=2&q=
Por lo que he visto, está en C++
Ok, intentaré compilarlo en cuanto pueda.