Parametro "Z"

[giant.sQuid]

hola soy nuevo en foro, y tambien manejando la libreria, tengo una duda acerca del VertexData(), ya que como sabemos, solo utilizan los parametros "X" e "Y" , y "Color" q es opcional, pero tambien tien un parametro "Z", que por mas que se le sea asignado un valor, este no modifica el resultado final, es decir el la textura esta igual de distocionada que si no lo tendria. quisiera saber que aplicacion tiene este parametro.
Yo estoy trabajando en un, nose si decir "Motor", creo q es mas bien un conjunto de funciones, classes,etc, que ayudan graficar en un entorno tridimencinal, es decir  |:|, manejarce con "x,y,z" y que los codigos se ocupen de graficarlo con perspectiva y el la forma correcta.Volviendo al tema, en ese seria una aplicacion para dicho parametro,  pero nose me ocurre para q mas...
esto es lo que vi:

..........

   Texture = Graphics.MAP_Load(App.Path & "\texture.png", 0) ' Cargamos la textura para el sprite.
   
   '  "Definimos los vertices en orden de las agujas del reloj:"
   ' es mas bien una "z"
   ' 0 - ------------- 1
   ' |                      |
   ' |                      |
   ' |                      |
   ' |                      |
   ' |                      |
   ' |                      |
   ' |                      |
   ' 2 - ------------- 3
   
   VertexData(0).X = 32: VertexData(0).Y = 96:      VertexData(0).Z = valor0  --   : VertexData(0).Color = &HFFFFFFFF
   VertexData(1).X = 128: VertexData(1).Y = 0:      VertexData(1).Z = valor1  --   :VertexData(1).Color = &HFFFFFFFF
   VertexData(2).X = 256: VertexData(2).Y = 256: VertexData(2).Z = valor2   --   : VertexData(2).Color = &HFFFFFFFF
   VertexData(3).X = 256: VertexData(3).Y = 64:    VertexData(3).Z = valor3  --   :VertexData(3).Color = &HFFFFFFFF
   
   Do While Render
       Graphics.DRAW_VertexMap Texture, VertexData(), 0, VertexSpecular(), Blendop_Color, Mirror_None, Filter_Trilinear ' Dibujamos la textura.
       Graphics.Frame ' Renderizamos la escena.
   Loop
End Sub

.........

tambien me di cuenta que el orden de los vertices es diferente a como se expresaba en ejemplo original.

ah! y tambien es lo mismo con Graphics.DRAW_Map Texture, X, Y, "Z", 0, 0
tambien es invariable a la hora de renderizar...

saludos!  ;)

[[EX3]]

Buenas, giant.sQuid.

Como bien te ha comentado Hechelion en el otro post mi librería trabaja íntegramente en 2D. La coordenada Z no es mas que un mecanismo para ordenar la lista de llamadas gráficas de la libreria tal y como explica el apéndice ZBuffer de la documentación, pero trabaja a nivel de "objeto", lo que vendría a ser un sprite, una primitiva o una cadena de texto pero no a nivel de vértices como si fuera un espacio 3D. Piensa en esa coordenada como si fuera una capa, como en Photoshop.

DRAW_VertexMap solo utiliza el valor Z del primer vértice como referencia de que orden tiene que tomar el sprite al dibujarse respecto al resto de llamadas, funciona igual que DRAW_Map y sus variantes.

Salu2...

P.D.: Lo del orden de los vértices, cierto, me acabo de dar cuenta de la errata, perdón :P

[Manu343726]

Ya que mencionas lo del oreden de los vertices del sprite.
Yo también me había topado con ese problema. ¿Podriais confirarme cual es el orden correcto?
Cada vez que uso DRAW_Trapezoid y los demás tengo que probar ochenta veces hasta que hacierto con el orden. Y no estoy seguro de si el orden que pongo me gira la figura.

Gracias de antemano.

[[EX3]]

Como el render de dx_lib32 trabaja sobre la capa de Direct3D, cosa que no quiere decir que funcione como un motor 3D ;), los sprites y las figuras geometricas (cubos, circulos, trapezoides, etc...) se forman mediante quads, que viene a ser la union de dos triangulos unidos por sus vertices. Un ejemplo para ilustrar :)


Este seria el orden en que se deben definir los vértices y no en el sentido de las agujas del reloj como erróneamente menciono en la documentación, que seria mas un zig-zag o la ruta formada de una 'z' como menciona en su post giant.sQuid.

Salu2... :)

[giant.sQuid]

bueno si, simpre me parecio ovbio que fue la DX fue construida para entorno plano 2D ;) , lo que vine a plantear es que se puede si se kiere. La libreria es solo un herramienta y esta en las manos de quien  la utiliza el que hacer con ella. Si nos ponemos a pensar el VB tampoco es muy apto para desarrollar juegos,(de hecho pocos los son), y creo q ese es el chiste. De otras manera ningun [EX3] hubiera desarrollado ningun DX_lib32. La mejor parte es, nose.. la aventura si quiere lo que aprendi, y aprendo, y ni hablar de lo que se puede descubrir en este entorno.
Como bien dicen, podria desarrollarlo en otro lenguaje mas conveniete, que es probloable que lo haga, pero mas alla del lenguaje, este etorno opera en un lenguaje por encima de cualkier otro, el matematico, asi que sin importar que programacion sepamos, la descripcion matematica siempre va a ser la misma. Asi que yo, (q no se un pómo), le recomiendo que se tiren de cabeza y que reniegen, que q se enojen, pateen, pero al final va a valer la pena meter mano en esto.
   :P
Salu2.

[[EX3]]

bueno si, simpre me parecio ovbio que fue la DX fue construida para entorno plano 2D ;) , lo que vine a plantear es que se puede si se kiere.

Me remito a la explicacion que hecho en el otro post sobre por que no se puede trabajar volúmenes 3D con rutinas 2D:
http://www.stratos-ad.com/forums/index.php?topic=14009.msg146260#msg146260

Como bien dicen, podria desarrollarlo en otro lenguaje mas conveniete, que es probloable que lo haga, pero mas alla del lenguaje, este etorno opera en un lenguaje por encima de cualkier otro, el matematico, asi que sin importar que programacion sepamos, la descripcion matematica siempre va a ser la misma. Asi que yo, (q no se un pómo), le recomiendo que se tiren de cabeza y que reniegen, que q se enojen, pateen, pero al final va a valer la pena meter mano en esto.

Ten cuidado o luego te pasara como a mi que después de 7 años de duro trabajo desarrollando esta librería y tratando de sacar adelante mi proyecto del juego con ella he tenido que tirarlo todo por ser virtualmente imposible sacar el proyecto por las limitaciones de Visual Basic 6.0 y demás problemas de base que arrastraba por dicho lenguaje (la programación del motor se hizo demasiado compleja para el lenguaje) y eso casi nos cuesta el primer premio de una competición que ganamos el año pasado por los pelos a un par de strateros (casi me corto las venas :P) Quiero decir con esto, que tengas claro que puedes y no puedes hacer con la herramienta que uses por que por mucho ingenio y mucha persistencia, si la herramienta te limita no podras hacer milagros.

Salu2...

P.D.: Si un dia monto un blog tendre que escribir un articulo explicando los pros y los contras de usar una herramienta para lo que no ha sido diseñado en base a la experiencia de desarrollar las dos versiones de dx_lib32 y los 6 intentos del TLSA.Engine 0:-)

[giant.sQuid]

jej ok.
Les comento que antes hacer esta locura, estaba metiendo mano en el openGL con FreeBasic, pero me perdia con las rotaciones de material, moviento de camara, pero ahora ya estoy totalmente familiarizado,hasta podria decir que "soy mejor persona" 0:-)jaja. Almenos espero  subir de nivel como avanzar en ese preoyecto q descuidé el año pasado jeje.

salu2, nos vemos!