Bennu Game Development

Foros en Español => Extensiones => Topic started by: DCelso on March 11, 2010, 12:15:39 AM

Title: mov_vse
Post by: DCelso on March 11, 2010, 12:15:39 AM
hola a todos, he portado a Bennu esta librería pero no tengo ni la más mínima idea de cómo se usa, simplemente me dediqué a adaptar el código a las peculiaridades de bennu y a eliminar "warnings" de compilación.
Necesitaría vuestra ayuda para probar la librería.
Title: Re: mov_vse
Post by: SplinterGU on March 11, 2010, 02:18:40 AM
conozco a alguien que estara feliz de esto...

yo sinceramente no la porte, porque en fenix era muy inestable... la simple demo que hicieron para mostrar como se usa, ya hacia que se caiga la dll... asi que por eso no la porte, y tampoco quiero lidiar con problemas adicionales...

gracias.
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 06:15:21 AM
Hombre, despues de tal descaro deberia poner el código del port con sus dependencias correctas, no!?  :(
Grácias por hacer el trabajo, aunque creo que Drumpi tambien me deberia dar el karma diário, por justo  ;D
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 06:34:38 AM
La he probado, nunca probe la original, por lo que veo va super rápido, con super rendimiento, hice una captura que de tan rápido sólo pille una region verde  ;D

(http://forum.bennugd.org/index.php?action=dlattach;topic=1225.0;attach=937)
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 06:44:05 AM
Hay problemas en el import del "type08.vse" para el ejemplo "vse08_sort.prg":

en la linea 68 con pointer (END expected):

vse_face pointer first; //Primera cara que se dibujará en caso de que se ordenen las caras
Title: Re: mov_vse
Post by: DCelso on March 11, 2010, 07:25:25 AM
juasjuasjuas, sabía yo queee,
me va a tocar saber que es lo que hace internamente esta libreria y estudiarla más a fondo, que listo fue SplinterGU con no portarla :D.
Haremos lo que se pueda.

Y soltar el código, lo tengo pensado, pero cuando sea estable para no ir liando a la gente en cosas que no estén funcionales :D.

A ver si alguien como Drumpi es tan amable de ponernos un prg sencillote explicando linea a linea qué es lo que hace así me ahorro de leerme el tocho de htmls adjuntos que tarde o tremprano tendré que leer :D.

En cuanto a los karmas, dita sea ¿ya quieres karmas por nada? :D, hazte más módulos y no pidas limosnas :D.
Yo te voy a dar uno por pasarme la patata caliente de este project, porque menudo marrón has sabido quitarte :).
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 08:54:59 AM
Esto me recuerda a historias deja vú, tipo tetris y otras más de la história. En que el tonto del turno que tuvo la idea, la que permitió a otros listillos forrar sus bolsillos :)

Enfin, con decir que si no fuera por el pequeño impulso dado en el momento justo por FreeYourMind la vse seguiria sin estar portada, me bastaria tan sólo eso para alegrarme el día, snifff  ::)
Title: Re: mov_vse
Post by: DCelso on March 11, 2010, 09:37:43 AM
No te procops, te meteré en algún lado en los comentarios del código fuente, a ver donde te mento :D. Por cierto que conste que ya tienes el minipunto que querías, por lo menos el mio correspondiente que te dije que te iba a dar, eh.

Aunque he de decirte que ya tenía pensado el portarla desde que drumpi lo dijo en otro post (por eso le pregunté que qué diablos era :D) pero que la dejé apartada por desmotivación :D.
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 09:56:42 AM
No pido tanto :) (Ni tiene lógica).
Con saber que te motivo es suficiente, karma por eso, y otro cuando saques el código y me digas que dependencias me faltaban  ;D

PS: Por cierto, si luego veo el motor3D que me han regalado ayer portado a Bennu, por lo menos sabré que soy fundamental en la comunidad para motivar a los foreros coders :D
Title: Re: mov_vse
Post by: DCelso on March 11, 2010, 10:30:07 AM
Quote from: FreeYourMind on March 11, 2010, 09:56:42 AM
No pido tanto :) (Ni tiene lógica).
Con saber que te motivo es suficiente, karma por eso, y otro cuando saques el código y me digas que dependencias me faltaban  ;D
Eso es fácil y muy buena idea de que te pusieras ha intentarlo, así aprenderías para futuros ports, si es que te mola esto, que parece ser que sí.
A ver, vamos por partes.
Simplemente he necesitado insertar dos includes, el libgrbase.h y el bgddl.h :D.
El problema me lo he encontrado con los cambios de código.
1.- la estructura GRAPH antes parece ser que tenía un campo depth con la profundidad de color, ahora tienes que sacarlo de otra propiedad llamada format que a su vez es una estructura que tiene un campo depth.
2.- la estructura GRAPH antes parece ser que tenía un campo flags en el que almacenaba si tenía puntos de control o no, además existían unas constantes para poder hacer los "Ands" a flags y sacar informaciones varias. Ahora este campo no existe pero podemos saber si un graph tiene puntos de control viendo el valor de un campo llamado ncpoints que indica el número de puntos de control que tiene el graph.
3.- la función para dibujar una línea en un graph antes se llamaba gr_line(...) y ahora se llama draw_line y está en libdraw.dll.

Así que básicamente, en resumidas cuentas es solo esto:
1.- Insertar los dos includes mencionados, en verdad solo son obligatoriamiente necesarios estos dos pero puedes meter libdraw.h libblit.h para eliminar algunos warnings de compilación.
NOTA: tienes que hacerlos al principio del todo, antes del include personal de vse, ya que si no da errores este include personal.
2.- hacer los cambios al código comentados anteriormente.
3.- Insertar la ruta de los directorios de libgrbase y del bgdrtm del cóidog fuente de bennu en la compilacion ejemplo"-Ic:/bgdsrc/modules/libgrbase".
4.- Insertar la ruta de los binarios de bennugd en el enlazado, ejemplo  -Lc:/devbennu/bin, si tienes la estructura de ficheros del instalador oficial de bennu, vas a necesitar insertar los directorios lib,externals,bin,modules.
5.- Insertar la dependencia de librerías en el enlazado, ejemplo -libgrbase -libbgdrtm -libblit -libdraw.

con esto consigues la mi..rda binario que he hecho yo y que parece ser que no va :D.

Hazlo y me cuentas a ver que tal.

A mi gcc me ha soltado la pila de warnigns que he corregido la mayoría y quizás hayan cambiado la lógica de la librería y por eso no va, así que te recomiendo que no hagas nada primeramente, y luego ya si quieres y veas que va como la librería original te pongas a limpar  warnings para acotar posibles problemas de portado :D

Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 10:45:19 AM
Muchas grácias, pero acabo justo de pillarme otro modulo de fenix, el cual esta sencillote (y personalmente este me gusta mucho más) y este si que lo quiero portar yo (ya que entre tres mil tuyos yo quiero llegar al tercero :))

Utiliza tambien el GRAPH, así que de esta vez voy a seguir tu tutorial, sino lo consigo me envias tu actual version despues por PM, ya que quiero conseguir sacarlo hoy mismo cuando llegue a casa.

Este modulo va a callar algunos que yo sé, que critican duramente Bennu, pero que en su día este modulo les molaba mogollón, y no me preguntes más sobre el modulo, sino lo portas antes que llegue a casa  ;D (almenos que lo adivines), heheheheeheh
Title: Re: mov_vse
Post by: DCelso on March 11, 2010, 11:07:47 AM
nope, no sé de que hablas, tuviste suertecilla :D.
Title: Re: mov_vse
Post by: Drumpi on March 11, 2010, 01:49:31 PM
Bueno, tranquilidad, que me acabo de conectar, que llevo una mañana ;D (entre arreglar el TDT, las prisas de mi padre por hacer cosas de casa, y arreglar un bug GORDO que me apareció anoche del Echo...).

Lo acabo de bajar, a ver si saco un ratillo para portar y os cuento.
De momento ahi va el primer karma, y como funcione, ya irán el resto como prometí ^^
Puedo subiros un par de códigos que guardo de la época de Fenix, de mis pruebas (en Fenix), un par de cosas sencillitas, por si os aclara más las dudas, pero básicamente consistía en situar la cámara y hacer el render.

Ya digo, a ver si esta tarde me dejan trabajar tranquilo y le robo un poco de tiempo a Echo.
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 02:07:52 PM
No veo el Karma por ningun lado... Upsss, si lo tiene DCelso  ;D
Title: Re: mov_vse
Post by: Drumpi on March 11, 2010, 04:18:39 PM
It works
¡¡¡¡IT WOOOOOOORRRKSS!!!!!

Ou, yeaaahh, y sin cambiar nada del código (bueno, el nombre de la DLL). Al menos con los test que hice en su momento... y con los mismos fallos de entonces ;D

Por cierto, dentro de la lib está el código que se usa en la expand.dll, una librería que, al pasarle las coordenadas de 4 puntos deforma la imagen (colocando las esquinas en esos puntos) ;)

Quote from: FreeYourMind on March 11, 2010, 02:07:52 PM
No veo el Karma por ningun lado... Upsss, si lo tiene DCelso  ;D
Bueno, la dll la ha adjuntado DCelso, así que... ^^
Pero si hay un trabajo conjunto detrás... no se ha dicho, o mi cerebro no tiene ahora capacidad para haberlo entendido ^^U, y habría karma para repartir ;)


El error del vse_target está en la línea 1607, porque es posible que dist valga 0 y por tanto se da la ya comentada división por cero.
Respecto al resto, ya ni idea (las rayas de colorines del primer plano en el test del plataformas de Sonic y el reescalado de los sprites que no van como deben).

Wow, 3d, 3d, 3d, 3d ¡2000! ;D

PD: en el test del racer hay una prueba de ascensor, a base de modificar el mapa de alturas, está comentado y no se ve, lo digo por si quereis ver cosas curiosas que dan mucho juego ;)
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 04:43:00 PM
"Bueno, la dll la ha adjuntado DCelso, así que... ^^"

Si si, Windows 7 tambien lo ha sacado Bill Gates...
Title: Re: mov_vse
Post by: Drumpi on March 11, 2010, 05:28:43 PM
Bueno, teniendo en cuenta que el Billy Puertas se "jubiló" de M$ hace años, y que no la dirige ya :D
Pero vamos, que a esfuerzo conjunto, doble racion de karmas ;D

Ahora ya sólo falta que me ponga a trabajar en algo, que alguien aprenda cómo funciona el código y que se corrijan los bugs ;D
¿Hay muchos cambios en el código fuente? ¿se puede ver o vais a revisarlo para que esté más limpio / mejorarlo?
Title: Re: mov_vse
Post by: DCelso on March 11, 2010, 07:14:03 PM
Ahora mismo estoy solo en el proyecto, pero si quiere ayudarme free bienvenido sea yo esto de los voxels no los controlo.
Que alguien me los expliqueee.
A ver vamos por partes Drumpi, ponme un prg con un bug solo y lo que debería de hacer para que no fuera un bug y empiezo por ahí.
Explicame el ejemplo linea a linea porque es que ni j idea de lo que es hacer que una imagen plana se ponga en relieve usando un .map.

En cuanto a lo del karma para free, él fue el primero en intentar portarla y el que me pasó la patata caliente para que lo intentara yo tras fracasar él en el primer intento. Así que yo me piqué y me puse al lío por tanto es culpa suya que esté aqui tan pronto el módulo este ya que yo lo puse en cola hace tiempo para hacerlo y se quedó allí.
Es por eso que se merece los karmas tanto como yo :D.

NOTA: como dije antes, he quitado muchos warnings de compilación, así que puede que algunos bugs se hayan eliminado o hayan aparecido otros, por lo que tienes que probar los bugs que conocías en esta nueva librería para ver si siguen.
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 08:29:59 PM
Muchas grácias a todos, pero hombre es que no te has fijao ? si esto de los Karmas lo digo más de coña que otra cosa, por diversión :) Si es el único sitio donde los tenemos, casi me apetece ponerlos en otros sitios hehehh.

Pues sobre los voxels, nunca dijé nada, pero años atrás ya tuve mi primer contacto con ellos en algun código en C que miré sobre el tema (sino mal recuerdo creo que alguien se lo inventó y puso unas demos).
Pero vamos ni en su día lo miré con atención, sólo me dislumbré con los cubos que ponia la demo.

Hombre, ya ni se si me da tiempo hoy de hacer el intento de portar la otra dll, pero si necesitas ayuda hasta el finde, pues sabado te podria echar una mano (de las pequeñas ya lo sabes, que esto no da para mucho).
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 10:11:57 PM
Buenas, ya tengo la otra dll portada!!!

Sólo me falta las dependencias, o sea, las .lib, donde las puedo sacar ???

Insertar la dependencia de librerías en el enlazado, ejemplo -libgrbase -libbgdrtm -libblit -libdraw.

En este punto, de donde las sacaste tu ?
Grácias
Title: Re: mov_vse
Post by: FreeYourMind on March 11, 2010, 10:22:10 PM
Ya lo tengo!!!!! he linkado directamente las dll's :)
Title: Re: mov_vse
Post by: Drumpi on March 12, 2010, 01:29:34 AM
Bueno, pues explico un poco lo que es un voxel: a groso modo es un modo7 con relieve. Es un mapa 2D al que se le asigna, pixel a pixel, una altura distinta, por lo que cada punto (x,y) se dibuja con una linea de altura Z. En este caso, la VSE, se usa un mapa con una textura (en los ejemplos se usan colores montañosos, yo he usado la Gree Hill Zone), y aparte, un mapa de 8bits, que indica la altura de cada pixel (si el pixel (0,0) tiene el color 45, se dibujará la textura con el punto (0,0) a 45 pixels de altura).

¿Quieres un ejemplo concreto de bug? en el segundo código que subí, el del Sonic plataformas puedes ver todos los fallos:
1-El primero salta a la vista: unas lineas verticales multicolores que tapan la escena.
2-El segundo requiere que muevas la cámara: usa QAWSED para moverla y verás que cuando la cámara se pone de forma que el test se maneja cual plataformas 2D clásico, o situando la cámara justo enfrente del personaje (siempre en ángulos de 90º), el programa se cierra. Es lo que comentaba de la división por cero.
3-Este es un poco más sutil, y sólo se ve bien en el ejemplo en el que mueves la bola en el mundo 3D: el reescalado de un sprite (imagen 2D situada en el voxel en un punto 3D) con la distancia no va. En el citado ejemplo no se sabe a qué distancia está el círculo y por eso los deplazamientos muchas veces no tienen sentido (unas veces va muy rápido, otras muy lento... pero en realidad siempre se mueve a la misma velocidad).

Luego está el tema de que vse_advance peca de mucha imprecisión, tanta como el Advance normal con resolution=1, por eso en el primer ejemplo he usado las funciones del propio Fenix y va tan suave.


En fin, si está todo bien, entonces la ración de karmas va para DCelso, pero cada bug que se arregle y cada mejora que se haga no va a estar exenta de su conveniente ración ;)
Ya veis lo que hice en una tarde: imaginad ese plataformas de Sonic, pero añadidle profundidad ;) Obviamente, las limitaciones de la VSE me impiden ponerle loopings, pero tengo algunas ideas para puentes y demás y puede quedar un juego curioso. No a la altura del personaje, pero sí algo bastante original (y que me moría de ganas de hacer en papel y no pude por "limitaciones espaciales").
Title: Re: mov_vse
Post by: SplinterGU on March 12, 2010, 02:33:13 AM
drumpi... drumpi... haras trabajar a los muchachos en algo obsoleto, con muchos bugs...

insisto en que no vale la pena perder tiempo en esto, mejor es que emplen el tiempo (freeyourmind) en hacer algun modulo 3d real... (yo ya empece a hacer pruebas con opengl... despues no digan que no tuvieron oportunidad...)
Title: Re: mov_vse
Post by: DCelso on March 12, 2010, 02:41:31 AM
 ;D, mi no importar
Title: Re: mov_vse
Post by: FreeYourMind on March 12, 2010, 05:21:26 AM
Quote from: SplinterGU on March 12, 2010, 02:33:13 AM
drumpi... drumpi... haras trabajar a los muchachos en algo obsoleto, con muchos bugs...

insisto en que no vale la pena perder tiempo en esto, mejor es que emplen el tiempo (freeyourmind) en hacer algun modulo 3d real... (yo ya empece a hacer pruebas con opengl... despues no digan que no tuvieron oportunidad...)

Con el modulo Open3D, mi único problema es hacer de chino para poder avanzar y eso me cuesta mogollón  ;D
Title: Re: mov_vse
Post by: Drumpi on March 13, 2010, 01:02:59 AM
No, si por mi, me pasan el códgo y ya veré cuándo le meto mano. Yo no tengo prisa ni me importa cocinármelo.

Simplemente, preguntan por bugs, yo respondo. Me hace ilusión tenerla de nuevo entre mis binarios :)
Subiendo el karma de hoy.
Title: Re: mov_vse
Post by: DCelso on March 13, 2010, 01:07:38 AM
Quote from: DCelso on March 11, 2010, 10:30:07 AM
...
4.- Insertar la ruta de los binarios de bennugd en el enlazado, ejemplo  -Lc:/devbennu/bin, si tienes la estructura de ficheros del instalador oficial de bennu, vas a necesitar insertar los directorios lib,externals,bin,modules.
..
Quote from: FreeyourMind
Buenas, ya tengo la otra dll portada!!!

Sólo me falta las dependencias, o sea, las .lib, donde las puedo sacar Huh

Insertar la dependencia de librerías en el enlazado, ejemplo -libgrbase -libbgdrtm -libblit -libdraw.

En este punto, de donde las sacaste tu ?
Grácias
Quote from: FreeyourMind
Ya lo tengo!!!!! he linkado directamente las dll's Smiley
A qué te creía que me refería con el punto 4? :D.
Title: Re: mov_vse
Post by: FreeYourMind on March 13, 2010, 06:50:24 AM
Fijate el lamer que soy, las libs siempre me han echo confusion, aún al día de hoy no se que difereencia hay entre libs y dll's  ;D
Title: Re: mov_vse
Post by: SplinterGU on March 13, 2010, 02:47:21 PM
Hecho del verbo "hacer" lleva "H"...
Echo del verbo "echar" va sin "H"...

:P
Title: Re: mov_vse
Post by: DCelso on March 13, 2010, 03:11:48 PM
Oye, "me han echo confusión" pues ni idea si es de hacer o de echar porque a mi no me suena bien ninguna de las dos, siempre escuché "me han dado confusión"
:D
Por otro lado los .lib y los .dll son lo que correctamente hablando se llaman "bibliotecas de funciones" un compendio de funciones y variables para realizar algún objetivo común, vulgarmente se les empezó a llamar librerías por la mala traducción de library (Recuerdo que librería en inglés se dice bookshop, y que biblioteca es library) y en la actualidad se ha hecho muy común decirle así.

Diferencias: las .lib son estáticas y las .dll son dinámicas.
Y qué significa estático, pues que a la hora de hacer el enlazado para generar el ejecutable las funciones que use éste de esta librerías se incrustan con el binario (.exe) final, por lo tanto ya no es necesario transportar los .lib con el ejecutable, éste mismo es independiente de ellos.

Con las dinamicas pasa justo lo contrario, a la hora de enlazar no se incrustan con el binario sino que dejan una marca para que el binario sepa que si necesita una función de ésta, tiene que buscarla por fuera de éste. Es por ello que tienes que distribuirlas junto con el ejecutable.

Ventajas:
Con los estáticos el ejecutable es lo único necesario para que se ejecute en otro ordenador mientras que con las dinámicas necesitas pasar también el .dll.

De forma estática el binario final ocupa más que de forma dinámica, pero si pones a comparar el binario final de un estatico con el binario final del dinámico mas todas las dlls que necesita, este último caso ocupa bastante más.
¿Por qué usar entonces ejecutables compilados con librerías dinámicas?
Bueno, la respuesta es porque si se populariza una .dll mucho y muchos de tus ejecutables la usan al final sale más rentable en espacio ocupado y además ofrecen la ventaja de que si alguna dll contiene un bug, con solo recompilar la dll todos tus ejecutables tendrán solucionado el problema.
Title: Re: mov_vse
Post by: SplinterGU on March 13, 2010, 03:25:47 PM
no se a que vino el comentario de las dinamicas y las estaticas... pero te equivocas enormemente... las dinamicas suponen una ventaja general con respecto a las estaticas...

las ventajas de una dinamicas son muchas, se cargan 1 sola vez en memoria y son usada por muchos programas... lo unico que tiene diferente cada proceso es el area de datos... pero comparten el area de codigo... se pueden actualizar sin necesidad de tener que compilar nuevamente tu programa... se pueden cargar las que realmente necesites... y no necesariamente ocupa mucha mas memoria, ya que el enlazador dinamico se encarga de cargar lo que necesita de las mismas (no tiene por que mantener tablas de simbolos o cosas que no necesita luego de la carga) y actualizar lo que tiene que actualizar, por eso que veas el tamaño mayor de archivos separados no significa que realmente eso ocupa en memoria...

tambien tienes que tener en cuenta cosas como simbolos de debug... que puede que las hayas tenido en las pruebas que hayas hecho para afirmar estas cosas...

creo que tu apreciacion es un poco apresurada...

pero bueno, creo que nos desviamos del tema.
Title: Re: mov_vse
Post by: DCelso on March 13, 2010, 05:24:48 PM
Aha, todo lo que dices es cierto.
¿En qué ves que mi descripcion contradice a la tuya?
Todo lo que dije también es completamente cierto.

Puede que me equivoque pero a veces me parece que no lees detenidamente los post. :( (espero que no te lo tomes a mal, puede que sea yo el que no lo haga)
Por ejemplo, ¿leiste este?
Quote from: FreeYourMind on March 13, 2010, 06:50:24 AM
Fijate el lamer que soy, las libs siempre me han echo confusion, aún al día de hoy no se que difereencia hay entre libs y dll's  ;D
Title: Re: mov_vse
Post by: SplinterGU on March 13, 2010, 06:07:37 PM
es que en tu post has dado a entender que es infinitamente mejor usar estaticas... y que el uso de dinamicas era mas una resignacion que otra cosa...

eso has dado a entender en la redaccion de tu mensaje... quizas no lo leiste completo una vez escrito, y por eso no te diste cuenta...

yo lo he leido varias veces para no mal interpretar...

yo hablo de tu explicacion, no de que lo origino... pero bueno, eso fue un comentario de free, no una pregunta... pero nada...
Title: Re: mov_vse
Post by: DCelso on March 13, 2010, 06:13:45 PM
Visto así, tienes razón.
Yo solo pretendía definirlas, no decantarme por una ni otra, intenté poner ventajas e inconvenientes de ambos.
Yo también me postularía en usar .dlls a .lib si fuera el caso :D.

En cuanto a el motivo de explicar ambos formatos fue porque entendí que free necesitaba saber la diferancia al poner esa afirmación.
Title: Re: mov_vse
Post by: SplinterGU on March 13, 2010, 06:43:04 PM
bien, mi respuesta fue mas bien porque se veia como dije, y no queria que se de una formacion erronea...

pero bueno, veo que fue buena la aclaracion ya que coincides en eso... solo que el post daba otra impresion...

vamos que tenemos otras cosas por hacer...
Title: Re: mov_vse
Post by: FreeYourMind on March 14, 2010, 12:04:48 AM
Con lo estatico y dinamico y lib/dll me has resuelto otra duda que nunca busque en google... Hablais tando de compilar estaticamente y dinamicamente y nunca pense que fuera eso, sencillamente linke las dll's porque no encontre las libs por ningun lado ni por internet, esque tengo incluso que poner todo el tipo de ficheros en el filtro porque al importar una lib, no te ponde el filtro para dll :)

Como se hace una lib en lugar de una dll para terminar ?
Title: Re: mov_vse
Post by: DCelso on March 14, 2010, 12:46:27 AM
Free, depende del compilador que uses, yo en eclipse+cdt en las opciones tengo una combo que dice static/dynamic/executable y dependiendo de la que elijas te configura las herramientas de compilación para generar un lib/dll/exe respectivamente. En las herramientas de compilacion GNU, hay una aplicación que se llama "ar" y a la que pasándole los ".o" te genera un ".a" que es el equivalente a los ".lib" que generan otras herramientas como visualc o borlandc.

En cuanto a este mod, tengo una nueva versión limpiada un poco más pero en windows vista no se ve nada en los dos ejemplos que adjuntó Drumpi, he probado con la vse.dll que viene en el bennupack pero hace lo mismo (gracias a dios no es culpa de mi modificaciones :D)
A ver Drumpi te adjunto nueva versión con la corección de la división por cero, pruebala y nos dices.
Title: Re: mov_vse
Post by: FreeYourMind on March 14, 2010, 12:57:51 AM
Pon el código hombre que quiero mirarlo, o enviamelo por pm si la consideras beta ;D
Title: Re: mov_vse
Post by: DCelso on March 14, 2010, 01:31:35 AM
jurljurl, olee, los ejemplos de la vse que vienen en el bennupack funcionan correctamente. Algo anda mal en los ejemplos que nos pasaste drumpi.
he hecho pruebas de rendimiento entre el vse.dll del bennupack y el mod_vse.dll que he compilado yo y de media el mio sale un 20% más rápido, :D, así lo más drástico que he hecho es sustituir una funcion de logaritmo en base 2 que había hecho tristan a mano por la que viene en la math.h. Bueno, luego cambié post incrementos por pre incrementos que leí en manuales de optimización que eran más rápidos.

Free, el código aún no lo quiero soltar, voy a ver si lo organizo un poco, ¿tanta prisa te hace falta?, de todas formas en el bennupack puedes encontrar el portado por, supongo que, linkernel.(He visto que ha hecho trucos para no tener que tocar mucho el código usando "defines").

Drumpi, cuando puedas, a ver si me puedes hacer un ejemplillo simple de un mapa con un objeto que se gire automáticamente de 1 en 1, para ver si casca ahora algún ángulo. Yo, en las pruebas de los ejemplos que vienen en el bennupack (que son vse04.prg hasta vse08.prg) no he visto ningún error.

Lo que comentas de las líneas pues como tus ejemplos no me van pues no puedo buscar el motivo por los que fallan.
Title: Re: mov_vse
Post by: Drumpi on March 14, 2010, 02:20:41 AM
Pues he probado los test que tengo y buenas noticias: sí, el fallo de los ángulos está solventado, ya no hace crash (pero hace un efecto similar a la gráfica de la tangente: si se aproxima por un lado la cámara empieza a apuntar cada vez más alto hasta el infinito, y si se aproxima por el otro hace lo mismo hacia abajo, por suerte es un rango de ángulos muy bajo).

Respecto a hacer otros ejemplos, no sé, intentaré hacer algo, pero es que los fallos que me daban incluso a Tristan le parecían extraños. De todas formas te adjunto unas capturas, todas de la misma escena, modificando la cámara, para que veas el tema de las rayas. Es como si leyera unas posiciones de memoria fuera del mapa, y por tanto, es posible que sea la fuente del error, lo que impide que te vaya en tu windows (vamos, que te detecta lalectura fuera de rango y se cierra).

También puedes probar a cambiar los mapas por los de los ejemplos: el primer test es sobre una vista en primera persona que se mueve en un mundo infinito, ajustando su altura al suelo, y el segundo es una prueba de juego de plataformas.

Ya de paso, si voy a hacer los ejemplos, hago la prueba que quería que hiciese Splinter en el otro hilo, pero necesito saber si preferís correr, saltar o volar ^^U
Title: Re: mov_vse
Post by: Drumpi on March 14, 2010, 02:23:09 AM
PD: ten cuidado, en el segundo ejemplo hay DOS pruebas distintas, la segunda es la más completa pues trae un sprite y dos botones más para mover la cámara, indispensable si quieres probar todos los ángulos (QA acerca y aleja la cámara, WS la sube o la baja y ED la desplaza a izquierda o derecha). En la primera prueba, las rayas esas se notan mucho menos ???
Title: Re: mov_vse
Post by: DCelso on March 14, 2010, 02:44:52 AM
a ver, he modificado con un poco de más cabeza el asunto de dividir por 0, a ver que tal ahora.

En cuanto a los ejemplos, he probado a poner logs y nada, parece que todo va bien, pero no se ve un carajo en la pantalla, solo las letras y muevo camara con asdw y el supuesto objeto con las flechas y nada no veo nada.
Los valores que veo al principio son:
250         1   16
3100             0
-90000          0
0                  0
¿es correcto?
Title: Re: mov_vse
Post by: Drumpi on March 14, 2010, 03:01:10 AM
Ahora se nota MUCHÍSIMO menos... pero en ESE ángulo en concreto sigue tendiendo a infinito, no se por qué. En su momento hice mi propia versión de VSE_TARGET mediante código Fenix, pero no se dónde andará, pero no funcionaba bien, porque hay modificadores de altura a los que no tenía acceso, y aunque en el plano horizontal sí iba bien, en el vertical era una chapuza. A ver si lo encuentro.

Por lo demás, tienes un fallo, no sé donde, porque ese valor -90000 a mi me sale positivo. Quizás por eso no ves nada: te has dejado la escena a la espalda ^^U

Pero prueba tambien el plataf3d_v2.prg, porque es otro código distinto/aparte.
Title: Re: mov_vse
Post by: DCelso on March 14, 2010, 03:06:15 AM
el plaft3dv2 no lo tengo :(
Title: Re: mov_vse
Post by: Drumpi on March 14, 2010, 03:13:02 AM
Juer ¿pero qué me pasa? ¿el proyecto me ha dejado tonto o que?
Pues nada, te lo subo, con todo lo que lleva, esta vez, con lo que pruebo en Bennu.
Title: Re: mov_vse
Post by: DCelso on March 14, 2010, 03:32:44 AM
ahora veo cosas, a ver ya veo las barras de colores que decías, joer si están por tos laos no dejan ver na.
y lo del ángulo como se prueba?
Title: Re: mov_vse
Post by: SplinterGU on March 14, 2010, 04:22:25 AM
cuidado que yo no pedi ningun ejemplo, yo quiero ver un proyecto increible...

ahora, quizas esta vse va mas rapido porque estara compilada con optimizacion... ademas de los cambios que hayas hecho...
Title: Re: mov_vse
Post by: Windgate on March 14, 2010, 04:38:14 AM
Esto... ¿Alguien es tan amable de explicarme en algún idioma humano qué demonios hace esta librería?

He visto las fotos, pero no veo más que números y una pantallita en el centro aparentemente mal dibujada, con lineas extrañas...
Title: Re: mov_vse
Post by: SplinterGU on March 14, 2010, 04:44:56 AM
3d?
Title: Re: mov_vse
Post by: Windgate on March 14, 2010, 08:15:37 AM
Sí, algo relacionado con 3D me huelo, pero veo unas capturas un poco cutres... Ya está el Bennu 3D y un proyecto de 3D para GP2X que está intentando portar l1nk3rn3l, se llama Yeti, luego está BeOgre recién empezado y según veo Splinter está intentando traer OpenGL a Bennu... ¿No nos estamos excediendo un poco con tanta alternativa? :S
Title: Re: mov_vse
Post by: FreeYourMind on March 14, 2010, 09:05:12 AM
Si en eso tienes razón, pero al ser modular sólo usas la alternativa que quieras ni que tengas 100 parecidas. A mi no me parece que esto ensucie Bennu, ya que en tu proyecto sólo pones los modulos que te interesen. Esto permite que cada uno haga lo que quiera con sus modulos ni que sea sólo para aprender, tu depues lo usas si quieres, por eso no son oficiales.
Title: Re: mov_vse
Post by: Drumpi on March 14, 2010, 01:28:47 PM
Quote from: DCelso on March 14, 2010, 03:32:44 AM
ahora veo cosas, a ver ya veo las barras de colores que decías, joer si están por tos laos no dejan ver na.
y lo del ángulo como se prueba?

Hombre, modificar el ángulo a mano no se puede, pero sí indirectamente. Ese valor que a ti te daba mal es el ángulo de la cámara.
Si has descargado el último rar que te he puesto, en la v2 puedes modificar la posición de la cámara y SIEMPRE apuntará al personaje, por lo que podrás probar todos los ángulos. QA y ED la mueven a lo largo de las coordenadas cartesianas respecto al plano horizintal.

Quote from: Windgate on March 14, 2010, 04:38:14 AM
Esto... ¿Alguien es tan amable de explicarme en algún idioma humano qué demonios hace esta librería?

He visto las fotos, pero no veo más que números y una pantallita en el centro aparentemente mal dibujada, con lineas extrañas...

Pues la VSE hace un modo7 con relieve, resumiendo mucho. Tambien permite meter imágenes con textura en el mundo 3D.
Y eso de tener muchas librerías, no es exactamente: esta es algo como el modo7 al scroll vertical de toda la vida. Depende de lo que busques tiene su utilidad, para hacer mapas en relieve te da MUCHÍSIMA más precisión que cualquier editor 3D, pues puedes ponerle a cada pixel una altura independiente, lo que en 3D se traduciría con cientos o miles de polígonos, pero claro, no deja de ser un modo7.

SPLINTER: o sea, sólo llevo "terminados" 3 proyectos en 5 años y quieres que haga uno en VSE, tu sueñas :D :D :D Voy a ver qué sale.
Title: Re: mov_vse
Post by: SplinterGU on March 14, 2010, 04:33:09 PM
yo estoy viendo opengl para el mundo 2D... no estoy pensando en 3D aun...
Title: Re: mov_vse
Post by: DCelso on March 14, 2010, 05:40:52 PM
Splinter, eso molaría.
Yo hice un ejemplo 2d en antaño en opengl, es tan facil como obviar el eje z, y hacer todo sobre texturas en el plano z=0. :D.
La venta de esto es que luego puedes cambiar el punto de vista del observador y ver el plano 2d de juego como ladeado o curvado o darle efectos chulos al plano :D. Oye no sirve para nada (el hacerle esta últimas cosas que digo eh.) pero queda muy vistoso :D.
Title: Re: mov_vse
Post by: DCelso on March 14, 2010, 11:08:26 PM
Uajaajaa, sin tener ni idea de voxels he solventado el problema de las líneas, que bueeeeno soy, mua,mua,mua.
A ver drumpi, prueba este ejemplo que te paso y coméntame si todo es correcto.
Veo unas cosa muy raras que no se si deben ser así
1.- Cuando toco la a repetidamente para alejarme de la scene poco a poco va desapereciendo el muro verde y amarillo del final en cambio la rampa no desapare. ¿falla algo?

2.- Cuando dejo la d un montón de rato pulsada para cambiar el ángulo lateral, al llegar al valor 40850 da un error windows y cierra el programa. ¿Este es el problema de los ángulos que comentabas?

Title: Re: mov_vse
Post by: Drumpi on March 15, 2010, 01:54:28 AM
Moooooooooolaaaaaa. ¿Entonces descubriste por dónde se salía al leer el mapa? ;D
Pero te cuento, porque veo que para algunas cosillas no te has leido el tutorial donde se explica todo lo que trae:
1.- Lo que ves es a causa de la distancia de dibujado: se puede especificar hasta qué profundidad se puede dibujar. Es lo que se hacía con el 3D para no renderizar cosas muy alejadas de la cámara, que luego se disimulaba con la siempre socorrida niebla. Supongo que en el ejemplo puse una distancia relativamente corta para mejorar el render.
También se puede especificar la cantidad de píxeles a renderizar, yo lo tengo al máximo pero se puede poner cada 2 y cada 4, provocando una pérdida de calidad pero un aumento de velocidad, algo así como la calidad de Flash.
Incluso si has llevado al límite el movimiento de la cámara habrás notado un efecto llamado "ojo de pez", en el que las lineas rectas tienden a curvarse: se puede cambiar la "lente" para acentuar o disimular el efecto. Si se aumenta, se tiene mayor ángulo de visión a costa de verlo todo a través de un culo de botella (técnica usada en Sonic Extreme, el juego que nunca salió).

2.- No, a mi no se me cierra. El problema que te comentaba era este: intenta conseguir un ángulo lateral de 90000 o 180000 exactos, usa QAED sin miedo, verás que, llegando a dichos valores, la cámara deja de enfocar al erizo y hace "cosas raras" (apunta al techo o al suelo). Antes ese valor valía infinito (división por cero) y provocaba el cierre del programa.

Another karma, has arreglado un bug que ni Tristan encontró en su día :)
Title: Re: mov_vse
Post by: DCelso on March 15, 2010, 09:50:18 AM
Exacto, no me he leído la docu, la ví muy tocho, así que más mérito el haber arreglado el problema ¿no?. Intentaré leermela para poder saber de qué va la cosa más a fondo :D.

Por otro lado, a ver si puedes hacerle una cosa al ejemplo que te adjunté, eliminar el color verde del sprite de sonic y darle profundidad de forma parecida al fondo, es decir ver al sonic cuadradete con la misma perpestiva que la "scene" si se puede, sería algo como ponerle un map de alturas ¿no?
Yo por lo poco que he visto del código parece que no se puede , las opciones que ví eran para poner un sprite o un objeto 3d en la scenne, pero no ví poner un sprite con produndidad usando mapa de alturas.

Otra cosa que he visto es que no funciona a 16 bits (o no se como se hace), todas las pruebas que hago poniendo a 16 o 32 bits cascan. He visto en el código que en algunos sitios discrimina por el modo de pantalla así que me imagino que debería de ir bien en 16 bits, si tienes ejemplos en este modo a ver si puedes facilitarmelos.
Title: Re: mov_vse
Post by: Drumpi on March 15, 2010, 12:09:48 PM
Veré qué puedo hacer, pero el personaje de Sonic es un sprite 2D, es como los enemigos de un modo8: un mapa plano. Como mucho puedo hacer como el ejemplo del cubo, usar la función expand para crear un prisma, pero hacerlo 3D requeriría bastante trabajo porque hay que hacerlo a mano.
Si se integrase la ETD y consiguiese un modelo válido, si, podríamos tenerlo en 3D, pero eso ya es complicarse demasiado.

Lo de funcionar en 16 bits... no recuerdo, la verdad, creo que si se podía usar una textura 16 bits, pero no un mapa de alturas (este debe ser 8 bits a la fuerza, más que nada, porque si no, la edición del mismo se complicaría exponencialmente con cada bit extra)... aunque no recuerdo si lo probé.
Title: Re: mov_vse
Post by: DCelso on March 15, 2010, 04:34:08 PM
A eso me refería, a textura de 16 bits, lo otro ya es inimaginable, alturas desde 0 hasta 65535 uajajaa. Ojo, se podría hacer si fuera el caso de necesitase pero lo veo poco práctico.

Puedes probar en fenix el modulo a ver si soportaba texturas de 16 bits?
Title: Re: mov_vse
Post by: DCelso on March 15, 2010, 04:35:30 PM
En cuanto al sonic en 3d, me refería a usar una técnica tipo el terreno, tener una textura y un mapa de alturas para generar el sprite, pero vamos que si esto nunca fue posible pues ya me queda resuelta mi pregunta.
Title: Re: mov_vse
Post by: DCelso on March 15, 2010, 06:31:17 PM
ahora que lo pienso, a lo mejor expand es lo que yo digo, osea quedaría el sonic como un cartón gordo en el que se recorta la figura de sonic? Osea imagínate una tabla gorda de aglomerado, en ella dibujaas el sonic, lo recortas con una serreta y te queda un sonic que por delante y por detrás tienen forma de sonic pero que si lo canteas se ve solo el ancho de la tabla.
Title: Re: mov_vse
Post by: FreeYourMind on March 15, 2010, 08:19:04 PM
La expand sólo estira las 4 puntas de un gráfico, que a diferencia de hacer un size_y o size_x, te permite por ejemplo estirar sólo la parte de arriba o de abajo del cuadrado (o imagen con transparencias, la cabeza de Sonic por ejemplo).
Title: Re: mov_vse
Post by: Windgate on March 15, 2010, 10:32:07 PM
Oh, con expand se pueden hacer efectos como el de la tabla que dice DCelso, no lo había pensado... Si el modo 7 funcionase al 100% se podría combinar la idea xD
Title: Re: mov_vse
Post by: DCelso on March 16, 2010, 12:28:12 AM
Quote from: Windgate on March 15, 2010, 10:32:07 PM
Oh, con expand se pueden hacer efectos como el de la tabla que dice DCelso, no lo había pensado... Si el modo 7 funcionase al 100% se podría combinar la idea xD
Wind, Free dice que no.

Por otro lado, Drumpi, necesito que compares la antigua versión que colgué con esta nueva versión que dejo ahora con el .prg adjunto en esta versión.

He eliminado un error que daba al dejar pulsado "A" hasta llegar a la distancia de mas o menos 505, a mi ese error me lo soltaba windows vista y quiero comprobar si te lo suelta windows xp también. Pues eso prueba a dejar "a" pulsado con la antigua mod_vse que puse y a ver si da el error, y también prueba a hacer lo mismo con esta nueva versión que ya no lo tiene a ver si ya no te da.

También me pasaba dejando "Q" pulsado a una distancia de -55 mas o menos. Ahora con esta versión no casca.

Verás que ahora el módulo esta dividido en dos *dll, una es la vse propiamente dicha y otra es el wrapper de ésta para que sirva en bennu.

Aparte tambien necesitaría saber como llegar al ángulo 180000 sin perder de vista al sonic, o al ángulo 0. Solo consigo llegar al 90000 y ya veo lo que pasa, pero ahora no se me ocurre como solucionarlo, porque el truco que hice parece ser que no vale, yo pensé que si se dividía por cero es porque era infinito entonces en vez de poner infinito que no se puede ponía el valor más grande de un int. Pero pareceser que esto no es lo que verdaderamente hay que hacer :D.
Title: Re: mov_vse
Post by: Windgate on March 16, 2010, 11:32:04 AM
¿Entonces expand no es compatible con size, size_x, size_y, flags?

Si es compatible "creo" que sí debería ser posible conseguir el efecto que comentaba, aunque vamos, hablo desde la ignorancia, no he probado las funciones del módulo.
Title: Re: mov_vse
Post by: FreeYourMind on March 16, 2010, 11:50:21 AM
Yo no he dicho eso, yo he dicho la diferencia de un metodo en relación al otro.

El Expand te permite cojer una punta del cuadrado (vertice) y moverlo, y la region del cuadrado se verá afectada (sólo tienes que mirar el ejemplo).

Hacer un size_y por ejemplo, es como si con el expand (que tambien sirve para poder hacer lo mismo), pillarás las dos puntas de arriba (o abajo) del cuadrado y las estiraras al mismo tiempo.

Resumiendo, con size_y estiras o encojes 2 vertices de un gráfico al mismo tiempo en el mismo eje, y con expand puedes hacer eso y mucho más, pillar por ejemplo sólo un vertice lo que te permite poder deformar la imagen de más formas.

Tampoco he hablado del ejemplo que dice DCElso que no lo he entendido muy bien...
Title: Re: mov_vse
Post by: FreeYourMind on March 16, 2010, 11:55:44 AM
Luego cuando llegue a casa, os pongo una demo privada que le he enviado a Splinter, que enseña las maravillas que se pueden hacer con un sencillo size_y.
Title: Re: mov_vse
Post by: Drumpi on March 16, 2010, 12:18:43 PM
Bueno, voy a ver... pero si no tengo hecha la prueba a 16 bits es que en su día yo tampoco pude, me daba error sin saber por qué.

Lo del personaje a partir de alturas, no tiene mucho sentido: ten en cuenta que VSE son lineas que suben desde el suelo por lo que el personaje sería una especie de prisma o pirámide, o cualquier poliedro cuya base sea siempre mayor que cualquier sección superior.
Puedo usar un sprite, como ahora, o la expand, para crear una imagen de perfil, otra de frente y luego ponerlas en cruz, o bien usar muchas imágenes a modo de polígonos, pero tardaría un mes sólo para eso, y el rendimiento... ^^U

La expand permite hacer lujosos efectos 3D, aunque en realidad la imagen sea 2D, por ejemplo, poner las esquinas de la derecha en las esquinas de la ventana, y las otras dos hacia el punto de fuga, y así da sensación de ser una pared a nuestra diestra. Fue una idea que le sugerí a Tristan para poder poner algún tipo de textura al mundo 3D de ETD y VSE (y así poder hacer un Starfox).

Respecto a probar lo que me has puesto, sí, lo he probado y ahora si me ha saltado error. La otra vez me dijiste que pulsase D, y por ahí no petaba. Te adjunto sendas capturas de la última versión (la anterior no me deja, pero casca igual).
Para el ángulo que te tiene que devolver, puedes intentar mover la cámara a la misma distancia, pero con ángulo -90000 o 0 y ver qué valor debería devolver. Si no, siempre se puede reescribir, es simple trigonometría (por ejemplo, respecto al plano horizontal sería algo como ángulo=atan(disty/distx) siendo disty la distancia en el eje y entre la cámara y el proceso target, y lo mismo con distx y el eje x). En el plano horizontal se puede hacer con el propio Bennu, pero la elevación no, porque influyen cosas como el parámetro que indica la altura por pixel, el ángulo de apertura...
Title: Re: mov_vse
Post by: DCelso on March 16, 2010, 02:54:25 PM
¿Entonces la versión que te subí también casca dejando el "a" pulsado un rato?

en cuanto lo que comentas de la arcotangente no entiendo nada :D.
Te pongo el código modificado de target

angSB = vse_fget_angle ( VoxSpaceIdents[id_voxelspace]->x,
VoxSpaceIdents[id_voxelspace]->y,
sprite_x,
sprite_y); <b>Aqui calcula el ángulo B</b>
      <b>Aqui ya vale 90000 el ángulo</b>

angSB = (angSB * VoxSpaceIdents[id_voxelspace]->a360)/360000; <b>aquí lo transforma en un valor interno para usar una tablas pregeneradas de cosenos y senos</b>

dx = VoxSpaceIdents[id_voxelspace]->cos_look[angSB] * 2;
dy = -VoxSpaceIdents[id_voxelspace]->sin_look[angSB] * 2;

if (dx > dy){
if (dx != 0)
dist = ((sprite_x - VoxSpaceIdents[id_voxelspace]->x) * 4096) / dx;
else
dist = INT_MAX;
}else if (dy != 0)
dist = ((sprite_y - VoxSpaceIdents[id_voxelspace]->y) * 4096) / dy;
else
dist = INT_MAX;

zr = (sprite_z << (FIXP_SHIFT + VoxSpaceIdents[id_voxelspace]->scale))
- (VoxSpaceIdents[id_voxelspace]->dslope * dist
* VoxSpaceIdents[id_voxelspace]->RMap->height >> 1);

if (dz !=0)
dz = (zr - (VoxSpaceIdents[id_voxelspace]->z << FIXP_SHIFT)) / dist;<b>Aqui es donde cascaba antes</b>
else
dz = INT_MAX;

VoxSpaceIdents[id_voxelspace]->a = (dz / VoxSpaceIdents[id_voxelspace]->dslope)
+ VoxSpaceIdents[id_voxelspace]->RMap->height; <b>Aqui calcula el ángulu A</b>

VoxSpaceIdents[id_voxelspace]->b = angSB;

Pues vamos, si sabes explicarme más a fondo la función target bienvenido sea.
yo se que como parámetro de entrada se le pasa el suelo y las coordenadas "xyz" del sprite y calcula los ángulos "ab" del suelo.
Pero poco más, porque no se ni qué son esos águlos :D.
Title: Re: mov_vse
Post by: Drumpi on March 16, 2010, 04:48:33 PM
Ah, guay, es que aun no me he puesto a mirar el código a fondo ^^U
Pero bueno, a ver si esta tarde le doy un vistazo, porque parece mentira la de cosas que me has aclarado con dos frases (sorry, el trabajo es lo primero).
Básicamente, los ángulos son:
-Por lo que leo, el B indica el ángulo segun el plano horizontal. O sea, cuanto hay que girar el cuello de izquierda a derecha.
-Y el A indica la inclinación de la cámara, vamos, girar el cuello arriba y abajo.

No sabía que usaba tablas de senos/cosenos precalculadas ¿eso aumenta el rendimiento? ¿eso no estaba ya pre-calculado por c o por bennu?
Title: Re: mov_vse
Post by: FreeYourMind on March 16, 2010, 04:53:58 PM
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...
Title: Re: mov_vse
Post by: DCelso on March 16, 2010, 05:45:56 PM
npi, es un mundo abstracto esto para mí :.(. Yo solo leí el código pero no lo entendí :D.
Title: Re: mov_vse
Post by: DCelso on March 16, 2010, 07:19:31 PM
Ya he encontrado el problema, el error está en el cálculo del ángulo A, cuando dz vale 0
He hecho un algoritmo con histéresis y en caso de que dz valga 0, asigno al ángulo a el valor anterior.
Ahora el problema parece culpa de precisión, veo valores del ángulo a bastante dispares.
Drumpi, prueba esta nueva versión, que muestra por la consola los valores xyz del suelo y del sprite y los angulo a y b
lleva el ángulo a 90000 y luego a 920000 y mira todos los resultados antes y despues de 900000, verás que no hay continuidad.
Title: Re: mov_vse
Post by: Windgate on March 16, 2010, 07:52:17 PM
Descargando, voy a echar mi primer vistazo a esta librería a ver si saco algo en limpio :D
Title: Re: mov_vse
Post by: Drumpi on March 16, 2010, 08:04:40 PM
¿Te refieres a los datos en pantalla? porque cuando me pongo a 90000 o 180000, el ángulo de inclinación apenas varía, pero la cámara se va de viaje ???
¿Tienes el código fuente por ahi? para echarle un vistazo, porque si no, tengo que tirar del código original de la 0.8 para Fenix.
Por otro lado ¿por qué dividirlo en dos librerías?

PD: lo siento, no he podido probar lo de los 16 bits ni nada de lo demás, aun.

PD2: Wind, no te descargues la última, porque es una actualización :P La buena creo que es la tercera.
Title: Re: mov_vse
Post by: FreeYourMind on March 16, 2010, 09:26:49 PM
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...

(http://forum.bennugd.org/index.php?action=dlattach;topic=1225.0;attach=999)
Title: Re: mov_vse
Post by: SplinterGU on March 16, 2010, 09:35:49 PM
Quote from: FreeYourMind on March 16, 2010, 04:53:58 PM
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...
Title: Re: mov_vse
Post by: FreeYourMind on March 16, 2010, 09:38:52 PM
Si me lo has dicho tu!!! Lo que uno tiene que oir, tendré que poner aqui las pruebas ?  ;D
Saludos.
Title: Re: mov_vse
Post by: SplinterGU on March 16, 2010, 11:13:10 PM
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...
Title: Re: mov_vse
Post by: DCelso on March 16, 2010, 11:56:06 PM
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.
Title: Re: mov_vse
Post by: Drumpi on March 17, 2010, 12:32:06 AM
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.
Title: Re: mov_vse
Post by: DCelso on March 17, 2010, 12:56:14 AM
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

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.
Title: Re: mov_vse
Post by: Drumpi on March 17, 2010, 02:12:21 PM
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).
Title: Re: mov_vse
Post by: DCelso on March 17, 2010, 06:04:52 PM
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);
Title: Re: mov_vse
Post by: Drumpi on March 18, 2010, 01:08:13 AM
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.
Title: Re: mov_vse
Post by: DCelso on March 18, 2010, 08:39:54 AM
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.



Title: Re: mov_vse
Post by: Windgate on March 18, 2010, 09:27:48 AM
Vamos a ver esa demo DCelso, la última vez me bajé sólo la .dll y no sabía qué hacer con ella.
Title: Re: mov_vse
Post by: DCelso on March 18, 2010, 09:58:45 AM
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.
Title: Re: mov_vse
Post by: Drumpi on March 18, 2010, 01:38:08 PM
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
Title: Re: mov_vse
Post by: FreeYourMind on March 18, 2010, 02:04:03 PM
Quote from: Drumpi on March 18, 2010, 01:38:08 PM

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 :)
Title: Re: mov_vse
Post by: DCelso on March 18, 2010, 06:47:55 PM
Drumpi,
prueba esta nueva versión,he puesto en target lo siguiente,

b = vse_fget_angle(VoxSpaceIdents[id_voxelspace]->x,
VoxSpaceIdents[id_voxelspace]->y, x, y);

a = vse_fget_angle(0,
VoxSpaceIdents[id_voxelspace]->z/128, get_dist(VoxSpaceIdents[id_voxelspace]->x,VoxSpaceIdents[id_voxelspace]->y,x,y) , -z*2);


el dividir por 128 no se porqué ni el -z*2, puedes explicarmelo?
Title: Re: mov_vse
Post by: DCelso on March 18, 2010, 06:53:29 PM
voy a colgar el código aqui entero por si te ayuda, pero OJO no lo useis para compilarlo porque aún está muy verde
Title: Re: mov_vse
Post by: Drumpi on March 18, 2010, 07:02:51 PM
Te lo pruebo luego, que ahora estoy con Linux ^^U

Como te dije antes, esos valores son para corregir a ojo las deformaciones del voxel por la apertura del ángulo de la cámara y el tamaño de cada pixel de altura. Me explico mejor:

int vse_set_voxelspace ( int id_voxelspace, int angle, int jump, int scroll, int maxStep, int scale )

   Parámetros:

   * id_voxelspace:   Identificador de la escena a configurar
   * angle:               Ángulo de apertura de la cámara
   * jump:                  Columnas a dibujar por iteración (1,2 ó 4)
   * scroll:                 Indica si el mapa es cíclico
   * maxStep:           Profundidad máxima a la que se renderiza
   * scale                  Cantidad que se escalan las alturas

El ángulo de apertura de la cámara indica cuanto se va a ver. Una persona puede ver casi 180º a su alrededor sin mover los ojos. Los pájaros, al tener los ojos en los lados, pueden cubrir un ángulo mayor, superior a los 300º. Si miras por una ventana, tu ángulo de visión se reduce.
Si has visto algo de óptica, o has tirado fotos o eres aficionado al video, supongo que sabrás de que va el tema. Hay lentes que permiten ver con mayor o menor ángulo ¿has visto los videos de los skaters? usan una lente con un ángulo de visión enorme, pero eso provoca el efecto ojo de pez (en el centro las cosas se estiran hacia arriba y abajo, y en los extremos laterales se encogen).

Esta deformación afecta a la posición del sprite en pantalla, por lo que hay que inclinar más o menos la cámara.

También está el campo scale, que se explica en la ayuda:
Con scale indicamos por cuanto se amplifican las alturas del mapa de alturas, es decir, si usamos un scale 8 (el que hay por defecto) la altura que tendrá la punta más alta de un mapa de alturas será 255*8 = 2040 (referido a la posición del observador), es decir, que cuanto mayor sea scale las montañas serán más "puntiagudas", scale debe ser una potencia de 2 (1, 2, 4, 8, 16, ...)

Obviamente esto también afecta a la posición del sprite en pantalla.


Pero, supuestamente, en el código interno, todo esto ya se tiene en cuenta al calcular las posiciones y los ángulos y todo, por lo que el /128 y el *2 no deberían ser necesarios.
¿No te había explicado ya esto antes? ???
Title: Re: mov_vse
Post by: Windgate on March 18, 2010, 08:03:05 PM
Arg, ¿Cómo me subís los test sin la .dll?

Voy a ver si por fin pruebo este módulo :S
Title: Re: mov_vse
Post by: Windgate on March 18, 2010, 10:58:27 PM
Veamos, tengo un problema de índole sexual con este módulo:

- Intento compilar el test y me pide la vse.dll
- Descargo la dll y veo que se llama libvse.dll
- Renombro a vse.dll y me dice que vse_new_vexelworkspace no está definido

Un .zip con todo incluido pofavo... He estado siguiendo el hilo más o menos, pero ando un poco perdido...
Title: Re: mov_vse
Post by: DCelso on March 19, 2010, 12:25:16 AM
esta es la peúltima versión de la lib que tengo
http://forum.bennugd.org/index.php?action=dlattach;topic=1225.0;attach=1004
la colgué hace unos cuantos hilos atrás.
Y la última versión se conseguiría añadiendo
http://forum.bennugd.org/index.php?action=dlattach;topic=1225.0;attach=1006
esta otra lib.

A ver si me explico, "vse.dll" es la versión que viene en el bennupack, simplemente es un port de la vse 0.80 de tristan.
Luego yo he dividido el código fuente en dos dlls independiente libvse.dll que es la librería que tiene todas las funciones vse implementadas y luego un mod_vse.dll que es un wrapper de libvse para bennugd.
Así que si usas vse.dll solo necesitas este archivo y poner import "vse" en tu prg, pero no es la versión de mi port, sino la de supongo que de l1nk3rn3l.
Si quieres usar mi versión necesitas mod_vse.dll  y libvse.dll y poner import "mod_vse" en tu prg.

Tu lo que has hecho es intentar usar mi libvse.dll como si fuere el vse.dll del bennupack, o lo que es lo mismo has intentado usarlo como módulo bennu, y no lo es, el módulo bennu es mod_vse.dll pero internamente llama a las funciones de libvse.dll, de haí el nombre de "wrapper"
Espero que quede claro ahora que estamos todos un poco empanaos últimamente :D.

Drumpi, tienes razón ya lo dijiste, pero si quito el /128 no se ve nada en la scenne y si quito el -z*2 y pongo solo z sin el menos ni el por dos entonces al saltar el sonik la camara no lo sigue bien, salta bastante.
Espero que mires el ejemplo a ver si los resultados son los esperados.
Title: Re: mov_vse
Post by: Drumpi on March 19, 2010, 01:49:42 AM
Pues he sobreescrito la libvse y... bueno, poco a poco. Ahora sí se puede ir por detrás de la escena sin que la cámara se vuelva loca, siempre apunta a la escena... aunque si la cámara se acerca demasiado a su target empieza a apuntar hacia arriba.
Lo de desaparecer el sprite sigue ahi ¿has tocado algo fuera de la vse_target? bueno, ya lo miraré. Y es curioso pero desaparece el sprite cuando la cámara supera la Y de este ¿guarda relación con lo anterior?.

Con el código puedo mirarlo tranquilamente, aunque ahora mismo tengo demasiados frentes abiertos :S (tres con el proyecto, la demo de VSE para Splinter, esto... y alguna cosa más que no merece la pena contar).
Qué raro que hayas recurrido a funciones de Bennu en lugar de escribir las operaciones directamente.
Title: Re: mov_vse
Post by: DCelso on March 19, 2010, 07:23:37 AM
no, que va, he escrito las operaciones directamente, el getdist ese que ves y el getangle son funciones hechas por mí en c, pero así hago que se vea más claro y tal. He probado pruebas de rendimiento con el test y no afecta a los FPS por si lo decías por eso.

En cuanto a la desaparición del sprite, ¿Que prueba has hecho para conseguirlo en el platf3d? O ha sido en el test06 solamente.

Y sí, además del target, modifiqué el render para que no mostrara las líneas esas que salían antes.
También modifiqué la lógica de agrandar y extrechar el sprite automáticamente para que cuando el map del sprite fuese tan chico que valiera 0 no cascase la lib.
También toqué todo el código para eliminar algunas variables no usadas, código muerto, cambios de algunas lógicas para que se vieran más claras o aportaran mejoras en el rendimiento, etc. Así que puede que algun cambio afecte al sprite, pero vamos no debería.

Tenía algunas cosas pendientes antes de soltar el código por eso era tan reacio a dejarlo pero si va a servir para que me ayudes pues lo dejo.
Queda esto por hacer
* Fallo que hace que el sprite desaparezca.
* Ver si el comportamiento de target está bien.
* Fallo de renderizado de texturas de 16 bits.
* Soporte de texturas de 32 bits. (Aunque esto no se yo si para el suelto tiene mucho sentido, pero como bennu las soporta ¿por qué no esta lib? :D)
* Organización interna de algunas funciones, y modularización de algoritmos repetitivos.
Title: Re: mov_vse
Post by: Drumpi on March 19, 2010, 01:45:30 PM
Perdona que no le dedique más tiempo a la librería, pero es que estoy realmente liado, y en casa no me dejan ni trabajar :S

Respecto a la prueba del sprite, en el test06 he visto que pasa cuando se mueve un poco más a la izquierda del centro de la pantalla. Pero en el plataf3d lo que he hecho es mover la cámara hacia la escena (pulsando QA), alejándolo ligeramente con DE, verás que cuando la cámara se pone detrás del sprite (como si se jugase a un Crash Bandicoot) desaparece.
Sospecho que pasa lo mismo con el test06, porque la cámara está con cierto ángulo y todo eso, no lo se, ya digo que no me dejan ni respirar.
Title: Re: mov_vse
Post by: Windgate on March 19, 2010, 01:59:25 PM
Lo he probado, es tremendamente simple, pero me ha gustado, algo así de simple debería funcionar en GP2X y otros dispositivos que no soportarían un render 3D real.

Os doy el merecido karma DCelso y Drumpi, ¿Alguien más? xD

Para el test sería interesante mostrar la pantalla más grande, es tan pequeña y tan pixelado lo que se ve que si no te lo dicen no parece que sea pseudo-3D
Title: Re: mov_vse
Post by: Drumpi on March 19, 2010, 02:19:43 PM
Yo de momento no he hecho nada, DCelso es el que está arreglando el código.
También deberías darle el karma a linkernel, que fue el primero en portarlo. Por lo visto DCelso no quiere los karmas que se merece :D :D :D

Lo de mostrar la pantalla más grande, basta con cambiar el tamaño del mapa que se crea para usarlo. Y eso de que no parece 3D, es porque no has movido la cámara :P
Lo de que no esté tan pixelado ya es más difícil, es como pedírselo al modo7.
Title: Re: mov_vse
Post by: DCelso on March 19, 2010, 03:36:02 PM
Quote from: Drumpi on March 19, 2010, 02:19:43 PM
Yo de momento no he hecho nada, DCelso es el que está arreglando el código.
También deberías darle el karma a linkernel, que fue el primero en portarlo. Por lo visto DCelso no quiere los karmas que se merece :D :D :D

Lo de mostrar la pantalla más grande, basta con cambiar el tamaño del mapa que se crea para usarlo. Y eso de que no parece 3D, es porque no has movido la cámara :P
Lo de que no esté tan pixelado ya es más difícil, es como pedírselo al modo7.
Con esta afirmación parece que he basado mi código en el port de l1k3rn3l cuando no es así. Mi port está basado directamente en la lib v.80 de tristán para fenix.
Yo me enteré de que estaba portado después de haber hecho mi port :(, y fué debido a que freeyourmind intentó portarlo porque drumpi afirmó en varias ocasiones que sería genial tener un port de vse para bennu, y al no conseguirlo me sugirió que lo intentara yo.
Ni Druimpi ni free ni yo conocíamos el port del bennupack si lo hubiéramos sabido alguno seguro que este port (el mío) de vse nunca hubiera existido.

En cuanto a los karmas, a ver, lo que no quería era que me die¡ran karmas por portar una lib que ya estaba portada de antes a bennu.
Pero ahora por las modificaciones creo que sí me los merezco (¿No?):D. Bueno, también Drumpi por su ayuda en los test y en sus conocimientos en trigonometría para 3D.
Y free por "obligarme" a meterme en estos lares, y a SplinterGU por BennuGD y a tí por probarlo, y a ....
Title: Re: mov_vse
Post by: FreeYourMind on March 19, 2010, 03:48:44 PM
Es lo que ya he afirmado antes, los Karmas os estan afectando el espirito, será mejor tener cuidado  ;D

Por otro lado, me duele más que ni habeis probado mi logo/efecto usando el size_y, maldito efecto karma   :-[
Title: Re: mov_vse
Post by: DCelso on March 19, 2010, 04:09:00 PM
hombre, todos estamos liados y ya con la imagen pues nos hacemos una idea :D
Title: Re: mov_vse
Post by: FreeYourMind on March 19, 2010, 04:13:05 PM
Que va, es que la imagen no dice nada del efecto... Es de los que hay que verlos... Sin excusas vamos, lo pruebas en 5 segundos, llamando el dcb y listo...
Title: Re: mov_vse
Post by: Drumpi on March 19, 2010, 08:17:38 PM
¿Entonces no son unas letras que parece que giran, que se pueden ver por detrás y eso? ¿No es el mismo efecto que uso en Echo con el nombre del arma que acabas de conseguir?
Title: Re: mov_vse
Post by: DCelso on March 19, 2010, 08:25:25 PM
yo ya lo he visto, y sipo es eso es el logo suyo que se ve bien y se va girando como si tuviera atravesado un pincho para trinchar pollos por el medio y estuviera en el horno dando vueltas.
Lo que pasa es que el muy... no le ha puesto botón de salir y me las he visto negras para cerrarlo (bueno no tan negras pero que no bastaba con darle a la x de la ventana eh). Te voy a dar un -karma por esto eah :D.
Title: Re: mov_vse
Post by: DCelso on March 19, 2010, 08:28:38 PM
eh drumpi, como llevas ese platform 3d to warrindongo.
Por cierto el error de que desaparezca el sprite no lo encuentro, fijo que es una chorrada pero es que no doy con la tecla, lo peor es que no tengo backups con versiones anteriores, me parece que me toca empezar de cero otra vez e ir poco a poco introduciendo cambios a ver cual fue el que lo causó :(.
Title: Re: mov_vse
Post by: Drumpi on March 19, 2010, 08:39:32 PM
Hoy me he estado peleando con OpenEmbedded, para instalarlo y compilarme un Angstrom para la Pandor.... emmmm, BeagleBoard ^^U
He parado hace media hora para ver qué me habían recomendado en los foros y poner los nuevos problemas. Los 5 minutos que he parado han sido para subir a GP32Spain la nueva versión de Echo, y estoy esperando respuesta de pixel en el foro general para subir la ready-for-all a la web de proyectos Bennu.

Cuando dices el platform ¿te refieres a solucionar problemas del test o al juego que me dijo Splinter que hiciera? De lo primero ya digo que no he hecho nada, y de lo segundo, ayer noche estuve creandome un programita que me ha hecho un FPG de 8bits con varios tiles para poner en un mapa de alturas y generar suelos y rampas a diversas alturas. Luego tendré que ponerme con el editor de terrenos, pero aun no sé cómo poner los puentes (si usar una lista con los trozos de los puentes o directamente un array tridimensional de tiles de durezas).
Title: Re: mov_vse
Post by: FreeYourMind on March 19, 2010, 09:08:51 PM
Quote from: Drumpi on March 19, 2010, 08:17:38 PM
¿Entonces no son unas letras que parece que giran, que se pueden ver por detrás y eso? ¿No es el mismo efecto que uso en Echo con el nombre del arma que acabas de conseguir?

Si, me fije en el tuyo (ha puntuado en los votos en el apartado gráficos don't worry), pero no lo hacias por gráficos ? Lo hacias tambien por código (no miré como lo hacias, pero alguien me dijo que era todo animaciones por gráficos) ?
Title: Re: mov_vse
Post by: Drumpi on March 20, 2010, 01:45:46 AM
No: size_y + flag 2 + un toque de trigonometría para hacerlo más suave/creible/parecido a la realidad :D
Debe estar en events.inc, un proceso llamado get_weapon o similar ^^
Title: Re: mov_vse
Post by: DCelso on March 24, 2010, 01:09:16 AM
nueva versión de esta lib, he corregido el problema que hacía que desapareciera antes de tiempo en ciertos casos.
Title: Re: mov_vse
Post by: DCelso on March 24, 2010, 06:16:58 PM
drumpi, cuando quieras.
Title: Re: mov_vse
Post by: Drumpi on March 24, 2010, 06:56:13 PM
Ups, sorry, te tengo abandonado ^^U
Es que entre que pongo discos a grabar y organizo el disco duro y todo, se me va la cabeza.
Voy a bajarla y la pruebo, luego te digo ^^U
Title: Re: mov_vse
Post by: Drumpi on March 24, 2010, 07:33:34 PM
Bueno, aprovechando un rato en el que estoy completando un disco, le he dado un vistacillo rápido:
Perfecto, los sprites ya no desaparecen ¡muy buen trabajo!
Ya no hay info de depurado ¿esta versión la has hecho desde el código original o arreglando la anterior? En fin, sospecho (ojo, digo que sospecho, no he mirado el código) que en el target, el fallo que puede estar dando es que el ángulo de elevación que calcula lo hace al revés, es decir, cuando debería dar -30º, este se pone a +30º, porque cuando te acercas con la cámara empieza a subir, pero no tiende a infinito, sino a mirar al techo ¿podrías intentar a ver si es lo que digo? es decir, cambiar de signo al resultado del cálculo del ángulo de elevación.

Ya sólo quedaría er el tema de los 16bits y del escalado con la distancia. Tengo muchas ganas de ayudarte, DCelso, de verdad, pero las prioridades son las prioridades :'(
El tema de los 16bits habría que preguntarle a Splinter, creo que en Bennu hay una serie de funciones que ayudan a que sea transparente para el programador usar maps de 8, 16 y 32 bits.

Por cierto se me viene a la cabeza, por curiosidad ¿Se puede hacer que, en lugar de pintar lineas verticales hasta el más profundo de los abismos, se pinten hasta una z=0? ¿Y que en lugar de pintar lineas verticales, que pinte sólo una superficie 3D, con grosor=1 en cada punto? ¿o no tienes ni idea del tema ^^U?
Title: Re: mov_vse
Post by: DCelso on March 24, 2010, 10:29:01 PM
Acertaste, npi pero npi completamente eh ;).
Title: Re: mov_vse
Post by: DCelso on March 24, 2010, 10:53:44 PM
He puesto estas fórmulas y además he pasado los ángulos a valores positivos pero sigue sin furular bien

b = vse_fget_angle(VoxSpaceIdents[id_voxelspace]->x,
VoxSpaceIdents[id_voxelspace]->y, x, y);
if (b<0) b+= 360000;
a = vse_fget_angle(0,
VoxSpaceIdents[id_voxelspace]->z/VoxSpaceIdents[id_voxelspace]->dslope, get_dist(VoxSpaceIdents[id_voxelspace]->x,VoxSpaceIdents[id_voxelspace]->y,x,y) , -z*2);
if (a<0) a+= 360000;

Title: Re: mov_vse
Post by: Drumpi on March 25, 2010, 12:37:00 PM
Quote from: DCelso on March 24, 2010, 10:29:01 PM
Acertaste, npi pero npi completamente eh ;).

Bueno, no pasa nada, así que sólo te informaré de aquello que no tenga que ver con voxels ni 3d... como hasta ahora, vamos.

Quote from: DCelso on March 24, 2010, 10:53:44 PM
He puesto estas fórmulas y además he pasado los ángulos a valores positivos pero sigue sin furular bien

b = vse_fget_angle(VoxSpaceIdents[id_voxelspace]->x,
VoxSpaceIdents[id_voxelspace]->y, x, y);
if (b<0) b+= 360000;
a = vse_fget_angle(0,
VoxSpaceIdents[id_voxelspace]->z/VoxSpaceIdents[id_voxelspace]->dslope, get_dist(VoxSpaceIdents[id_voxelspace]->x,VoxSpaceIdents[id_voxelspace]->y,x,y) , -z*2);
if (a<0) a+= 360000;



No, sólo tenías que coger las fórmulas anteriores y hacer lo siguiente. Era a el ángulo de inclinación ¿no? pues:

a= - vse_get_angle ("el resto como estaba antes").

B déjalo como estaba que iba bien. A no puedes hacer eso, pues A es un ángulo que valdrá entre 90º (mirando hacia arriba, en vertical) y -90º (mirando hacia abajo), nunca saldrá de esos valores, no tendría sentido... bueno, sí lo tendría, pero entonces la fórmula del otro ángulo sería muy distinta :D. De momento nos limitaremos a lo funcional, ya aplicaremos los giros en los tres ejes cuando nuestros conocimientos sean suficientes ^^U

Prueba a poner el -, a ver si así funciona bien y podemos rastrear el problema (supongo que será por poner el -z*2, debería ser símplemente z o vsecamera->z, no se el nombre de su variable/estructura).
Title: Re: mov_vse
Post by: Drumpi on March 28, 2010, 12:48:20 AM
Si estás muy liado, vuelve a pasarme el código y lo miro yo (y de paso compruebo si funciona en Linux), para el cálculo del ángulo creo que si podré sacar una tarde.
Me interesaría ver la última versión y la anterior al último arreglo (la que sale en el quote del mensaje anterior).
Title: Re: mov_vse
Post by: Drumpi on April 15, 2010, 12:13:45 PM
DCelso, cuando puedas, mírame a ver si me puedes pasar las dos últimas versiones de la librería, si no, comprueba que no es lo del signo cambiado.
Me interesa comprobar si puedo arreglar lo del target y ver el rendimiento en GP2X de cara al próximo concurso.
Y aun hay que mirar lo del autosize de los sprites, que me parece que no va del todo bien.
Title: Re: mov_vse
Post by: DCelso on April 15, 2010, 05:15:50 PM
ok, ya probé lo de cambiar el signo pero nada.
Te paso el código por si tu quieres probar más fórmulas, es el código de libvse.dll, ya que mod_vse.dll no hace falta recompilarlo para estos menesteres.
Title: Re: mov_vse
Post by: Drumpi on April 16, 2010, 12:54:15 AM
Pues llevo rato buscando pero de versiones anteriores sólo tengo una de libvse, pero no de mod_vse, por lo que si, puedo compilar para probar fórmulas, pero no podré probarlo en otros SO ^^U
Nah, no hay prisa, a ver si por casualidad puedo arreglar algo.
¿Los .projects que incluye son de Dev-c++ o de algún otro IDE?
Title: Re: mov_vse
Post by: DCelso on April 16, 2010, 01:04:24 AM
ok, es simplemente un wrapper así que si verdaderamente lo queres recompilar para linux podrías usar el generador de wrappers que colgué por ahí, haciendo pruebas con éste, creo que perdí sus fuentes por eso puede que no estén colgadas por aquí, a ver si con tiempo las busco o las rehago :D.
Pero bueno, no son importantes por ahora, simplemente recompilando libvse podemos hacer pruebas.
en cuanto a .project y .cproject, he repetido ya sendas veces que son de Eclipse, pero bueno, no me canso de repetirlo, son archivos para el Eclipse más concretamente .project guarda información de cualquier tipo de proyecto realizado en eclipse y .cproject guarda información de proyectos C.