mov_vse

[FreeYourMind]

Bueno, os pongo el ejemplo que os comentaba, utilizando sólo un size_y se consiguen efectos como el que pongo, que a mi particularmente me encantan (soy fan de todo tipo de efectos de rotaciones en gráficos 2d).
Con el Expand pues se pueden hacer cosillas más chulas aún, que reservaré para los juegos que estoy haciendo.

Hay que probarla para ver el efecto, aunque pongo una captura  de un momento dado...

[SplinterGU]

Sobre los senos y cosenos, Splinter ha echo funciones complementarias totalmente compatibles con DIV, ya que las de Fenix/Bennu estan mal. No se si eso ayudaria...

Eso que decis no es correcto, las funciones no estan mal, funcionan bien... solo que el valor retornado para sin/cos/atan y otras funciones trigonometricas no usan el sistema milesimal, sino que usan el sistema de numeracion flotante... y estas funciones son las de nivel de usuario... y no estan mal...

por favor, cuidado con la informacion que se da...

[FreeYourMind]

Si me lo has dicho tu!!! Lo que uno tiene que oir, tendré que poner aqui las pruebas ?  ;D
Saludos.

[SplinterGU]

es que no estan mal... si te dije lo contrario disculpa... pero no, no es homogeneo el uso de angulos... pero no funcionan mal... solo hay que multiplicarlos o dividirlos por 1000... decir que estan mal, es decir que no funcionan... y eso es incorrecto, porque si funcionan...

[DCelso]

A ver, son dos librerías porque una es la que hace las cosas, y otra es un wrapper para exportar las funciones a bennu.
Son dos librerías por seguir el formato típico que he llevado haciendo hasta ahora, una es la librería que serviría para cualquier entorno, por ejemplo libcairo, libpango, libpng, libgzip, y otra es el port para bennu
Son dos librerías porque tenía pensado en hacerle también un wrapper para fenix (solo por curiosidad de saber si sería capaz :D.).
Son dos librerías porque así solo necesito recompilar la libvse una vez y los cambios lo verían los ports de bennu y/o fenix.
¿Por qué quieres que sea una sola? ¿ganarías algo? :D.

Por otro lado, ¿Has probado la libvse última? no debería irde de madre en los ángulos que comentas, al menos a mi no se me va ya.
Y lo de los parámetros de salida son en la consola de msdos desde donde ejecutas "bgdi platf_3dv2", claro si lo haces con un bat, sería la ventana de msdos que te abre el bat.

Ahora que lo pienso la histéresis que hie es una soplapoyéz es lo mismo que no tocar el ángulo en caso de que dz valga cero, voy a quitarla y hacer esto último que digo.

[Drumpi]

Lo de las dos librerías lo preguntaba porque siempre es más cómodo tener una sola dll que dos, y así la aprovechaba para tener una guia para realizar mis propios módulos para Bennu ;D

Sí, he probado con el mismo código la última dll que me has pasado, y si aprieto la D, a los 90º pega el salto. Hay que hacerlo con cuidado porque sucede prácticamente en 3 frames.
Pero en los parámetros de la consola de MSDOS no sale nada que tenga que ver con el ángulo, como mucho la Z del proceso cámara ("nueva_z").

Aparte de eso, también he intentado cargar un mapa de 16bits, sin éxito, me falla en el vse_render_voxelspace(suelo0). Tanto el VSE_SET_MAP como el VSE_SET_VOXELSPACE devuelven un OK y no se corta la ejecución por errores raros. Supongo que habrás tenido en cuenta que tanto el mapa de texturas como el mapa sobre el que dibujas sean de 16 bits.
El caso es que no devuelve ni un valor, ni sale nada por la consola, por lo que debe ser algo de dicha función, justo antes de escribir ningún dato internos de esos que has puesto de chivatos. Ahí ya hay que rastrear con varios SAY en qué momento casca.

Si quieres, mañana te lo miro en Fenix, a ver si pasa lo mismo.

[DCelso]

ok
a ver adjunto la última versión que tengo con dos tests distintos.
mira a ver cómo se comporta ahora.
pero me da la impresión que la función target hay que cambiarla por completo, no va muy fina, porque va como a saltitos ¿te das cuenta?,
No entiendo como es que no ves nada en la consola de msdos a mi si me salen un montón de cosas, del tipo

Code Select Expand


voxel.x:-224, voxel.y:69,voxel.z:3370
x:16, y:48,z:0
angSB:5000, angSB cßmara:53, a:-40, b:53
voxel.x:-224, voxel.y:69,voxel.z:3370
x:16, y:48,z:0
angSB:5000, angSB cßmara:53, a:-40, b:53
voxel.x:-224, voxel.y:69,voxel.z:3370
x:16, y:48,z:0
angSB:5000, angSB cßmara:53, a:-40, b:53
voxel.x:-224, voxel.y:69,voxel.z:3370
x:16, y:48,z:0
angSB:5000, angSB cßmara:53, a:-40, b:53
voxel.x:-224, voxel.y:69,voxel.z:3370
x:16, y:48,z:0
angSB:5000, angSB cßmara:53, a:-40, b:53
voxel.x:-224, voxel.y:69,voxel.z:3370
x:16, y:48,z:0
angSB:5000, angSB cßmara:53, a:-40, b:53
0

y aqui puedes observar el cambio de todas las variables en cada bucle. Y he observado en el primer test que viene que la variable de ángulo no va lineal sino que vale -17, luego -16, luego otra vez -17, luego -15, luego otra vez -17, total que creo que es eso lo que hace los escalones visuales que vemos.
¿Segurísimo que estás usando la última versión?

En cuanto a 16 bits, pues revisaré render a ver qué encuentro.
No es por desprestigiar el trabajo de nadie pero creo que vse está muy muy verde :(, al menos esa es mi impresión.

[Drumpi]

A lo mejor es que me pasaste la versión que no era, porque ahora sí que veo los datos, y también los saltos de a, así como cuando se vuelve loco a los 90º. Pero no se si eso es así por culpa de los redondeos de los int o no debería ser así.

Lo cierto es que si, la VSE es una beta (de ahi lo de v0.8) y fue de los primeros trabajos de Tristan. Ya me comentó unos meses después que ya había adquirido muchos conocimientos del 3D y que le hubiese gustado meterle mano de nuevo a la librería, pero ya fue cuando desapareció del foro.
Estoy de acuerdo contigo, el VSE_TARGET necesita reescritura, porque creo que es lo único que falla, y no se yo si al resto habría que meterle mano también, para no necesitar la función VSE_RENDER_VOXELSPACE. Fíjate que en mi ejemplo, en el proceso camara, tengo las siguientes lineas:

//ang_elevacion=fget_angle(-y,z/128,-id_pos3d.y,-id_pos3d.z);
//esta linea que viene es correcta, por si el angulo se modifica
ang_elevacion=fget_angle(0,-z/128,get_dist(id_pos3d),-id_pos3d.z*2);

ang_lateral=fget_angle(x,y,id_pos3d.x,id_pos3d.y);

Si cambias el uso del VSE_TARGET y se usan esas variables para establecer los ángulos de las cámaras, podrás ver que el ángulo horizontal va de miedo, pero el vertical no por lo que te comentaba de los modificadores, pero que usándolos en el código interno debería ir bien. Claro que esas funciones, ya sabes, internamente usan trigonometría:

atan( (id_pos3D.y-y) / (id_pos3D.x-x))

Y aparte, una serie de optimizaciones computacionales que ya desconozco (como lo de la tabla con los ángulos pre-calculados y todo eso). Eso ya Splinter sabrá más.


Con todo y con eso, quitando los fallos y el rendmiento, me gusta más que el actual estado del modo7 (porque si empezamos a mirar el estado de las rotaciones respecto al proceso target, que los procesos no pueden estar en décimas de pixel (porque un "pixel" del mapa en modo7 "mide" más de un pixel real)...), no tienes más que comparar con el ejemplo aquel del escenario cuadriculado en amarillo y marron (el primero de todos).

[DCelso]

yepaa, he metido estas dos líneas que comentas y no veas qué suavidad.
A ver si pueder probar si es lo correcto.
ang_elevacion=fget_angle(-y,z/128,-id_pos3d.y,-id_pos3d.z);
ang_lateral=fget_angle(x,y,id_pos3d.x,id_pos3d.y);

[Drumpi]

No entiendo ¿has metido el código en la VSE o en el PRG?
-Si es en el prg, se te ha olvidado comentar el VSE_TARGET y descomentar el VSE_SET_ANGLE. Y lo cierto es que parece que apunta mejor ??? pero si subes/bajas la cámara con WS se descentra.
-Si es en el código C de la librería, sí, lo cierto es que se nota mucha mejora, va suave... pero el ángulo vertical no va bien: fíjate que al saltar el personaje no está en el centro, y al acercar la cámara hace un "extraño". Es mas, si mueves la cámara detrás de la escena... ya no se a donde apunta :S

Quieras que no es un primer paso muy importante, por lo menos, se ha corregido el bug del alejarse/acercarse mucho con QA.

[DCelso]

Es en c, pues si eres tan amable de decirme como calcular el ángulo vertical lo cambio,( ese es el ángulo elevación ¿verdad?)
fíjate en la fórmula y dime qué cambiar.
ang_elevacion=fget_angle(-y,z/128,-id_pos3d.y,-id_pos3d.z);

en cuanto lo del bug de alejarse/acercarse, es otro tema, estaba en la forma de mostrar el sprite en pantalla, al alejarse mucho y no verse el sprite el graph de éste valía 0 y el programa intentaba mostrarlo así que bennu cascaba, debe ser un error introducido en la versión 0.80 que es la que trae el auto redimensionado del sprite y es la fórmula que fallaba.

Ahora con la librería mía final modificada me he encontrado un fallo nuevo generado por alguno de los miles de cambios que he hecho y estoy buscando cual fue el que provocó el fallo para corregirlo. El fallo se puede ver en el ejemplo 06 de vse que viene en la bennupack, que consiste en crear un escenario, poner un sprite y moverlo por la scenne, curiosamente cuando lo mandas para la izquierda desaparece antes de tiempo, cosa que no pasa con la librería v80 sin tocar. Si se te ocurre la causa, dímela y la busco en código.

[Windgate]

Vamos a ver esa demo DCelso, la última vez me bajé sólo la .dll y no sabía qué hacer con ella.

[DCelso]

Wind, ni te molestes, si ya estás doctos en temas bennu3d esto te va a parecer tercermundista :D.
Esta librería lo único para lo que sirve es para facilitarte el tema del terreno, que usa lo que se denomina técnica de voxelización, que consiste en lo siguiente:
Tienes una textura de tu suelo en vista de pájaro ( en diseño gráfico se llama planta ) y luego tienes un mapa de alturas para cada pixel de tu textura (podríamos asimilarlo un poco a lo que sería el alzado en diseño gráfico) y con esta información lo que haces es crearte un voxel (pixel tridimensional) y desde este punto 3d haces una línea del mismo color de la textura hasta llegar al suelo, si repites esto para cada pixel de tu textura, consigues un terreno muy majo que es lo que parece ser que vende a la librería y simula al modo 7.

Luego a este mini mundo que crea el suelo le puedes añadir uno o varios sprites 2d y moverlos por éste para que interactúen con el suelo y puedas moverlos en el eje z, por ejemplo si hay una montículo en tu terreno podrías ponerte delante o detrás de éste.
Como novedad añadida en la última versión de tristan, la 0.80 aporta auto escalado en la distancia de este sprite2d.

También aporta insertar en este mini mundo un objeto 3d real, pero esto no lo he probado ni sé qué formatos de modelos permite.

Luego puedes mover la cámara del observador y poco más.

En general es una librería muy simple para hacer juegos de pocas necesidades, si quisieras hacer juegos como los que haces en bennu3d quizás se quede demasiado corta.

Por otro lado, Drumpi, he probado la librería original de tristan y pasa lo mismo que en esta, si le das la vuelta con la cámara a la scenne no se ve nada por el otro lado.

[Drumpi]

Pues mira, he estado pensando y he cometido un error de novato ^^U

¿Te acuerdas que dije ang_elevacion=fget_angle(-y,z/128,-id_pos3d.y,-id_pos3d.z);? vale, pues no es así, y es raro que no hayan saltado los matemáticos del foro, esos que se pirran por las fórmulas físicas para hacer sus juegos :D
Esto sería correcto siempre y cuando el personaje sólo se desplazara en los ejes Y y Z, pero puede darse el caso de que Y=0, y X=10, por lo que la inclinación debería ser la misma que si Y=10.

Lo que quiero decir es que en lugar de la distancia en Y debería comprobarse la distancia desde el punto (x,y) de la cámara hasta el punto (x,y) del sprite target.

En código bennu sería algo como:

ang_elevacion=fget_angle(0,z,get_dist(id_pos3d.x,id_pos3d.y),id_pos3d.z);
suponiendo que esta linea esté en el proceso cámara y que la estructura id_pos3d tiene las coordenadas del target.
En términos matemáticos, debería ser algo como:

distancia=sqrt( (target.x-camera.x)^2 + (target.y-camera.y)^2 );
angulo=atan( (target.z-camera.z)/dist );

Obviamente, ten cuidado con las distancias 0, en ese caso puedes usar
angulo=atan( MAX_INT );
O directamente el ángulo.

Te podría decir alguna cosa más mirando el código. Se me ocurre que si pasas por detrás de la escena, la razón de que no apunte al target (raro que antes lo hiciese) es que el cálculo de ángulos y valores de senos, cosenos y demás devuelve valores en el primer y cuarto cuadrante de las coordenadas cartesianas, por lo que en el cálculo del ángulo horizontal puede que falle (recuerda que hay dos ángulos cuyo seno vale 1/2: 30º y 150º).

Respecto a la desaparición del sprite... ni idea. Es posible que haya un error en el cálculo para saber si ha salido del rango de visión de la cámara. Por regla general, en un entorno 3D se calcula la posición de todos los elementos, pero a la hora de dibujar se ignoran aquellos que quedan tapados por otros o salen fuera de cámara (de la pantalla). Puede ser que se esté dando el caso de que piense que la flecha se sale.

Y yo le acabo de dar la vuelta y si que se ve, pero claro, usando VSE_TARGET se cierra en los ángulos malditos, y sin usarlo, las lineas correctas son:

ang_elevacion=fget_angle(0,-z/128,get_dist(id_pos3d),-id_pos3d.z*2);
ang_lateral=fget_angle(x,y,id_pos3d.x,id_pos3d.y);
vse_set_angle(suelo0,ang_elevacion,ang_lateral);

El - de z supongo que será por aquello de que la coordenada Y crece en sentido inverso al habitual (hacia abajo en lugar de hacia arriba), y lo de multiplicar y dividir es una estimación a ojo para contrarrestar los efectos del cambio de altura y el ángulo de apertura de la cámara, no tendrían que estar en el código C.

Ya digo, me gustaría ver tu código, a ver qué tal lo tienes (aunque sea Me lo Pasas o lo haces por correo, no me voy a asustar ^^U).

PD: la VSE, para hacer un juego de golf, es perfecta ;) Mucho mejor que cualquier librería 3D

[FreeYourMind]

Ya digo, me gustaría ver tu código, a ver qué tal lo tienes (aunque sea Me lo Pasas o lo haces por correo, no me voy a asustar ^^U).

PD: la VSE, para hacer un juego de golf, es perfecta ;) Mucho mejor que cualquier librería 3D

Opino lo mismo, que vienen 3 dias seguidillos de codificación a fulltime :)