dx_lib32 2.2.0 ya disponible - final de trayecto

[[EX3]]

Gracias :) tanto trabajo dio su fruto aunque tarde para el proyecto que se diseño en principio, pero bueno, como decia un compañero en otro post, lo aprendido en el desarrollo no me lo quita nadie :)

Además veo que  muchas de las funciones se podrían usar junto a las de mi propio motor, sin ningún problema.

El unico problema seria intentar que tu motor y otra libreria que use DirectX, sea dx_lib32 o la que fuera, tuvieran que pintar sobre la misma ventana. DirectX se hace con el contexto grafico de la ventana donde dibuja, por lo que no seria posible hacer dos contextos de DirectX sobre la misma ventana para que pintasen, al menos en pantalla completa que es donde el render toma control total de la pantalla, ya que en modo ventana no lo tengo tan claro al ser sobre sobre un area concreta de la interfaz de usuario de Windows. La verdad que ni idea por que no he probado ni una cosa ni la otra pero si decides probarlo me cuentas que tal fue el experimento ;)

Salu2...

[Ocho]

El unico problema seria intentar que tu motor y otra libreria que use DirectX, sea dx_lib32 o la que fuera, tuvieran que pintar sobre la misma ventana. DirectX se hace con el contexto grafico de la ventana donde dibuja, por lo que no seria posible hacer dos contextos de DirectX sobre la misma ventana para que pintasen, al menos en pantalla completa que es donde el render toma control total de la pantalla, ya que en modo ventana no lo tengo tan claro al ser sobre sobre un area concreta de la interfaz de usuario de Windows. La verdad que ni idea por que no he probado ni una cosa ni la otra pero si decides probarlo me cuentas que tal fue el experimento ;)

Tus apreciaciones son correctas. Yo veo que es improbable que se pueda compartir la pantalla. Aunque no imposible. Me refería más a la reproducción de video, de sonido y control de teclado, ratón etc. Las librerías se pueden combinar y usar de manera alterna. Por ejemplo puedo usar mi sistema de dibujo y tu sistema de control de sonido, música o teclado. Supongo que además es probable que se puedan usar  las dos proyecciones graficas sobre diferentes Pictures en una misma ventana. En cuanto a la pantalla completa, creo que habría que compartir el dispositivo de pantalla, en mi caso si que es posible, por que devuelvo punteros a de  todos los dispositivos, vértices, índices y texturas. He probado ha usar las dos librerías a la vez y funciona. Me he puesto ha pantalla completa y he utilizado dx_lib32 para reproducir música sin problemas.  ;)

[[EX3]]

Genial entonces :D No habia caido en la parte de Audio y Video (no se por que siempre estoy pensando en graficos :P) Es cierto que como cualquier otra libreria puede combinarse con otras librerias o motores para cubrir otro usos :)

Salu2...

[erdavid_]

hola buenas estoy intentando hacer un programita de reconocimiento visual, e conseguido k me reconozca visualmente una imagen,
xo para k funcione e tenido k usar picturebox con funciones getpixel y putpixel (api) y x lo tanto el proceso es muy lento y x lo tanto tube k buskar x ai una libreria k agilizara los procesos. Weno buskando x ai encontre la libreria esta, k esta muy bien desde luego, xo no consigo utilizar las funciones surf. Mi pregunta es k si podrias poner algun ejemplo de como utilizar los arrays las funciones surf como se carga en una superficie de esas y como se vuelve a pasar a un mapa, x k no consigo acerlo x mas vueltas k le doy. Muchas gracias.

[LeandroA]

Felicitaciones [EX3], me alegro mucho de que ayas podido concretar tu proyecto, es notable que todos estos años de esfuerzos valieron la pena, tampoco descarto que saques otra versión, pero bueno eso lo dirá el tiempo.
me gusto mucho la parte de los efectos de culminación y la definicion de vértice.
lo que hubiera estado bueno implementar el tema de las regiones, o quizás esta y no lo vi en los ejemplos, pero por ejemplo poder crear una región a partir de un Sprite para dar mas opciones en lo que refiere a colisiones.

Bueno felicitaciones nuevamente nos estamos viendo.

[Martin21]

Hola primero me presento: soy Martin Piñeiro estudiante secundario del Pio IX de capital federal,Argentina. Primero te felicito por la libreria dxlib32 que esta buenisima de echo me ayudo mucho a crear mi propio reproductor de musica para el cole (en VB6). Dsp de recibir una muy buena nota por el programa lo deje por un tiempo; pero ahora que lo reviso no logro hacer andar el Audio.MUSIC_SetCurrentPosition ni Audio.MUSIC_GetCurrentPosition. Leyendo este post vi que la libreria tiene algunos bugs entre ellos el de posicionar la lectura. Mi pregunta es si ¿hay alguna forma de arreglar esto? ^_^' porque es indispensable para mi que el reproductor de musica pueda ir para adelante y para atras. Ademas quiero pedirte mas informacion de la libreria como por ej que archivos de musica reproduce ademas de los ya mencionados en la web :

- Soporte de formato de sonido de onda WAV
- Soporte de formatos nativos de música: MIDI, WAV, MP3
- Sistema de codecs a través de DirectShow para dar soporte de nuevos formatos de música: WMA, OGG Vorbis...

La verdad igual te quiero felicitar porque sin esta libreria nunca podria haber creado mi reproductor en tan poco tiempo (3 meses).

Desde ya muchas gracias. :D

Pd: si no hubiera usado esta libreria hubiera terminado como todos mis compañeros usando el windows media player incorporado en el form y con solo 10 lineas hubiera echo todo. experiencia  = 0.

[[EX3]]

Pues segun releo mis respuestas en este hilo me temo que con la version actual no se puede utilizar dicha funcion por el error de conversion comentado. Siento el problema :(

Sobre los formatos, es como explica lo que has citado, soporte nativo de WAV, MIDI, MP3 y cualquier formato que soporte Windows Media via codecs, como el codec de OGG que esta disponible en la web de la libreria. Esto es, si instalas un codec de MP4 para Windows Media en teoria deberia aceptarlo tambien dx_lib32.

Salu2...

P.D.: Un comentario que os puede interesar a mas de uno, dado que estoy con el desarrollo de mi juego y a su vez usando la libreria en el, estoy depurando y corrigiendo los errores que quedaron sueltos en la version publicada en la web y que van saliendo en la marcha: el posicionamiento de musica, error al cargar archivos de sonido wav muy pequeños con el nuevo sistema de efectos, el error de las funciones _HIT de dx_Input, y alguno mas que no tengo apuntado pero que se han corregido en una version aparte que estoy usando para el desarrollo del juego. La idea es una vez este terminado el motor del juego y las pruebas no den errores respecto a dx_lib32 publicar una actualizacion con esta version que estoy usando.

[Hechelion]

Eso es una excelente noticia, la verdad el problema del HIT me estaba obligando a editar muchas líneas de "Konquista".
Quedamos a la espera de la nueva revisión entonces.

Saludos y felicitaciones por el trabajo.

[Martin21]

Gracias por responder. Esperare con ansias la actualizacion del dxlib32.

[Ubermann]

Es una pena que se termine aquí todo, sobretodo para aquellos usuarios, como es mi caso, que acaban de descubrirla.

Entiendo que con tus proyectos actuales no tengas tiempo, pero de verdad que es una pena que lo dejes.  :'(

En cualquier caso, ¿sería posible ver alguna cosa nueva implementada en un futuro cercano?
O incluso, ¿por qué no hacer una extensión de la dx_lib32 con soporte para manejo de gráficos 3D? Sería como un

branch del proyecto principal, o incluso un proyecto diferente, algo así como dx3d_lib32, por ejemplo.


Y ya que hablamos de cosas nuevas, yo sí echo en falta algunas cosas como:

- Soporte para formato de imagen GIF. En la ayuda no dice nada de que soporte GIF. Es decir, soporte 100%, que lea

el archivo y almacene toda la información de cada frame en memoria.

- Soporte para formatos contenedores ZIP así como PK2 (quake2), PK3(quake3) y WAD(Doom). Añadiendo soporte  para

esos otros formatos nos ofrecería mucha más flexibilidad a la hora de trabajar con los juegos que usan dichos

formatos, por ejemplo, desde poder crear herramientas para esos juegos hasta poder incluso crear engines enteros, o

juegos que usen esos datos sin necesidad de extraerlos y/o distribuirlos (con el derivado problema legal que ello

podría acarrear).

- Pixel Shaders. No creo que sea muy difícil, y menos aún cuando ya parte del trabajo está hecho.

- Rutas. Es decir, un sistema que permita trazar líneas entre dos puntos (virtualmente, NO dibujarlas) y que calcule posibles colisiones en su trayecto. Es decir, trazar una línea y comprobar si un punto interseca con dicha línea.

- Y ya que dx_lib32 está pensada para juegos, creo que es necesario (no sé si ahora está implementado, pero por si acaso...) implementar alguna función de espera como "Wait(miliSeconds As Long)". Así se evitaría el uso de controles Timer, que la verdad, a mi nunca me han gustado. Esta función detiene la ejecución de la función actual, pero no la del programa en general. Sería como "pausar" un thread en una ejecución  multihilo de entre varios que se están ejecutando, pero hacerlo durante un tiempo definido, NO hasta que el jugador lo reactive de nuevo.

[Mars Attacks]

Ubermann, no lo deja tanto por tiempo como por una limitación inevitable de windows con respecto al lenguaje, que impide la creación de stand-alones funcionales.

[[EX3]]

Ubermann, no lo deja tanto por tiempo como por una limitación inevitable de windows con respecto al lenguaje, que impide la creación de stand-alones funcionales.

Es mas que eso ;)

Es una pena que se termine aquí todo, sobretodo para aquellos usuarios, como es mi caso, que acaban de descubrirla.

Entiendo que con tus proyectos actuales no tengas tiempo, pero de verdad que es una pena que lo dejes.  :'(

En cualquier caso, ¿sería posible ver alguna cosa nueva implementada en un futuro cercano?

Hombre, mas que falta de tiempo... teniendo en cuenta que Visual Basic 6.0 es una tecnologia muerta y muy en desventaja con lenguajes actuales, que la libreria en si es un proyecto personal para un juego que llevo años tratando de sacar adelante (no la diseñe pensando exclusivamente en sacar un proyecto para la gente pero si para compartirla) y que actualmente, despues de casi 9 años de aprendizaje, desarrollo y mantenimiento (sobre todo desde que la version 1.03 que publique alla por el 2004 y mas todavia con la 2.0 desde el 2006) no me merece la pena en absoluto seguir trabajando en ella. Piensa tambien que yo pretendo hacer juegos, no desarrollar tecnologia. dx_lib32 existe por que cuando la plantee y comence a desarrollar yo solo conocia Visual Basic 6.0 y en este lenguaje entonces no habia nada similar mas alla de la API adaptada de DirectX por lo que no me quedo mas remedio que "guisarmelo" yo mismo :P No habra mas ampliaciones, mejoras ni correcciones en la libreria ya que si no la totalidad practicamente la libreria esta al completo de lo que planteaba hacer y muchas mas cosas de las que necesitaba :)

O incluso, ¿por qué no hacer una extensión de la dx_lib32 con soporte para manejo de gráficos 3D? Sería como un

branch del proyecto principal, o incluso un proyecto diferente, algo así como dx3d_lib32, por ejemplo.

Si buscas encontraras librerias para programacion 3D para Visual Basic 6.0 (TrueVision3D creo que todavia sigue en la red) pero sinceramente, con la cantidad de motores 3D como Unity3D y similares no me mereceria la pena programarme un motor 3D ni en XNA si quiera.

Lo siguiente que pides son cosas mas enfocadas a un motor de juegos que a una libreria de apoyo como es dx_lib32:

Y ya que hablamos de cosas nuevas, yo sí echo en falta algunas cosas como:

- Soporte para formato de imagen GIF. En la ayuda no dice nada de que soporte GIF. Es decir, soporte 100%, que lea

el archivo y almacene toda la información de cada frame en memoria.

Lo primero es que el formato GIF, a parte de anticuado, es un formato muy sucio por la calidad que tiene (pocos colores, el canal de transparencia es en base a un color, los problemas de compresion, etc...). Para estas cosas se usan tiles en secuencia en una misma textura que luego lees por bloques (usando MAP_SetRegion en este caso), por ejemplo:

Y lo ideoneo es usar PNG, mantiene la calidad completa de la imagen, comprime mejor que muchos otros formatos y permite definir tranparencias a distintos niveles de opacidad (degradados).

- Soporte para formatos contenedores ZIP así como PK2 (quake2), PK3(quake3) y WAD(Doom). Añadiendo soporte  para

esos otros formatos nos ofrecería mucha más flexibilidad a la hora de trabajar con los juegos que usan dichos

formatos, por ejemplo, desde poder crear herramientas para esos juegos hasta poder incluso crear engines enteros, o

juegos que usen esos datos sin necesidad de extraerlos y/o distribuirlos (con el derivado problema legal que ello

podría acarrear).

Nada te impide usar un componente externo para usar ZIP's o PK3 (que es exactamente el mismo formato que el ZIP). Piensa que para implementar la lectura de estos formatos (o cualquiera) se ha de tener informacion sobre sus estructuras y demas y saber implementarlas y es mucho trabajo si tengo tambien que trabajar otras areas de la libreria como graficos o audio. A mi el formato PAK me servia de sobra para mi proposito, por eso no busque implementar otro formato (y de hecho en desarrollos en .NET usaba el formato ZIP gracias a una libreria gratuita que hay para tal fin, si no, hubiera seguido usando el formato PAK).

- Pixel Shaders. No creo que sea muy difícil, y menos aún cuando ya parte del trabajo está hecho.

Pues creeme que si, si es difícil (la ultima versión iba haber tenido soporte de pixel shaders), y mas teniendo en cuenta que los pixel shaders no se comportan igual en la API de DirectX de Visual Basic 6.0 que en la API original de C++ (la mayoria de los ejemplos del SDK de DirectX no funcionan en VB6.0) y luego que solo tendriamos soporte para shader model 1.1 (DirectX8) lo cual, creeme, no merece la pena dado el coste de aprender a programar shaders en esa version (lenguaje ASM de la GPU) y por lo limitados que estan respecto a versiones mas modernas como la 2.0 (y sin contar que la libreria estaba pensada para funcionar con tarjetas graficas anteriores a una GeForce 3, que es la primera implementar pixel shaders.

- Rutas. Es decir, un sistema que permita trazar líneas entre dos puntos (virtualmente, NO dibujarlas) y que calcule posibles colisiones en su trayecto. Es decir, trazar una línea y comprobar si un punto interseca con dicha línea.

Esto como decia mas arriba, es mas propio de un motor de juegos que de una libreria de apoyo. Segun el juego hay mil formas de implementar un escenario y su información (un mapa de tiles, un mapa de durezas, vectores...), y de ahi, otras tantas de implementar un algorritmo u otro para busqueda de caminos. Yo por ejemplo, para mi juego, no preciso pathfinding y de haberlo necesitado hubiera implementado dicho codigo en el motor del juego y no en dx_lib32 directamente.

- Y ya que dx_lib32 está pensada para juegos, creo que es necesario (no sé si ahora está implementado, pero por si acaso...) implementar alguna función de espera como "Wait(miliSeconds As Long)". Así se evitaría el uso de controles Timer, que la verdad, a mi nunca me han gustado. Esta función detiene la ejecución de la función actual, pero no la del programa en general. Sería como "pausar" un thread en una ejecución  multihilo de entre varios que se están ejecutando, pero hacerlo durante un tiempo definido, NO hasta que el jugador lo reactive de nuevo.

Idem, esto es cometido de un motor. Tu puedes pensar que usar un Wait() te puede resultar ultil pero otra persona a la hora de hacer su juego puede pensar que le interesa mejor usar un sistema de componentes con su logica propia y realizar las esperas en base a eventos por ejemplo. Esto es puro diseño de programacion y cada cual tiene su forma o su patron preferido. Yo por ejemplo, desde las ultimas versiones de mi motor (el del juego) en VB6.0 y la actual en XNA 4.0, utilizo un sistema de "componentes" para definir entidades (personajes, items, enemigos, las fisicas, menus, el propio escenario, lo que sea que tenga algun codigo de logica) que separa codigo de dibujo de actualizacion de logica, como si fuesen dos ramas distintas, y estos componentes tienen dos estados, visible y enabled, uno determina si se dibuja el objeto y otro si esta activo (si ejecuta su codigo de logica, por ejemplo: la IA de un enemigo, la lectura de input, las colisiones, cualquier accion que realice el objeto). Ya solo con el estado enabled puedes detener un objeto del juego hasta que otro lo active (o un evento del propio objeto). Este patron de diseño es sencillo y claro y se adapta a muchos escenarios en programacion (y es el que se usa en XNA por ejemplo).

Despues de todo este tocho, piensa que muchas cosas que comentabas son puramente funcionalidades de un motor de juegos. dx_lib32 cumple una funcion de base, no esta diseñada para cubrir al completo el desarrollo de un juego pero si facilitar el no tener que preocuparte de lo que ocurre debajo de tu programa (DirectX, Windows, etc...) y piensa que siendo como es de inestable Visual Basic 6.0 no es muy recomendable complicar mucho la programación mas allá de lo que permite el lenguaje en si (programación multihilo por ejemplo es sinonimo de loteria en VB6.0 al igual que intentar exprimir demasiado la orientación a objetos limitada que ofrece). Siempre hay formas mas sencillas de implementar la lógica de un juego y generalmente no es necesario recurrir a programacion multihilo, simplemente saber separar u ordenar por prioridad la lógica de tus elementos (un sistema de componentes como el que mencione antes te puede servir perfectamente).

Salu2 y gracias por el interes en la libreria, en serio, se agradece mucho :)

[Ubermann]

Es una pena que se termine aquí todo, sobretodo para aquellos usuarios, como es mi caso, que acaban de descubrirla.

Entiendo que con tus proyectos actuales no tengas tiempo, pero de verdad que es una pena que lo dejes.  :'(

En cualquier caso, ¿sería posible ver alguna cosa nueva implementada en un futuro cercano?

Hombre, mas que falta de tiempo... teniendo en cuenta que Visual Basic 6.0 es una tecnologia muerta y muy en desventaja con lenguajes actuales, que la libreria en si es un proyecto personal para un juego que llevo años tratando de sacar adelante (no la diseñe pensando exclusivamente en sacar un proyecto para la gente pero si para compartirla) y que actualmente, despues de casi 9 años de aprendizaje, desarrollo y mantenimiento (sobre todo desde que la version 1.03 que publique alla por el 2004 y mas todavia con la 2.0 desde el 2006) no me merece la pena en absoluto seguir trabajando en ella. Piensa tambien que yo pretendo hacer juegos, no desarrollar tecnologia. dx_lib32 existe por que cuando la plantee y comence a desarrollar yo solo conocia Visual Basic 6.0 y en este lenguaje entonces no habia nada similar mas alla de la API adaptada de DirectX por lo que no me quedo mas remedio que "guisarmelo" yo mismo :P No habra mas ampliaciones, mejoras ni correcciones en la libreria ya que si no la totalidad practicamente la libreria esta al completo de lo que planteaba hacer y muchas mas cosas de las que necesitaba :)

En realidad, yo estoy usando dx_lib32 bajo VB5. Y funciona perfectamente.

Y si es por que Vb5/6 están ya desfasados, en verdad tienes razón, pero de todas maneras creo que Visual Basic 5/6 son más que suficientes para implementar juegos 2D como los que se pretenden hacer con dx_lib32.
Otra cosa es que ya nos queramos meter con entidades y demás, pero para eso ya usaríamos otras libs diferentes.

O incluso, ¿por qué no hacer una extensión de la dx_lib32 con soporte para manejo de gráficos 3D? Sería como un

branch del proyecto principal, o incluso un proyecto diferente, algo así como dx3d_lib32, por ejemplo.

Si buscas encontraras librerias para programacion 3D para Visual Basic 6.0 (TrueVision3D creo que todavia sigue en la red) pero sinceramente, con la cantidad de motores 3D como Unity3D y similares no me mereceria la pena programarme un motor 3D ni en XNA si quiera.

He visto por internet más de un juego realizado con Visual Basic 5/6 y Direct3D que, aunque no eran el no-va-más, sí eran interesantes desde el punto de vista de que es posible hacer cosas útiles con Vb5/6 y Direct3D, sin necesidad de XNA.

Respecto a lo que dices de usar engines ya prediseñados para crear nuestros propios juegos, pues yo jamás estoy a favor de ellos. No me gusta usar algo que no sé realmente cómo dibuja las imágenes en pantalla, ni cómo carga o descarga de memoria los datos, etc...
Además, si comparamos dichos engines con la programación pura, no suelen estar tan optimizados como un motor que hago yo a medida para mi juego, eliminando funciones que consumen tiempo de procesador y que no voy a usar, cosa que no puedes hacer con los motores ya prediseñados.

Lo siguiente que pides son cosas mas enfocadas a un motor de juegos que a una libreria de apoyo como es dx_lib32:

Y ya que hablamos de cosas nuevas, yo sí echo en falta algunas cosas como:

- Soporte para formato de imagen GIF. En la ayuda no dice nada de que soporte GIF. Es decir, soporte 100%, que lea

el archivo y almacene toda la información de cada frame en memoria.

Lo primero es que el formato GIF, a parte de anticuado, es un formato muy sucio por la calidad que tiene (pocos colores, el canal de transparencia es en base a un color, los problemas de compresion, etc...). Para estas cosas se usan tiles en secuencia en una misma textura que luego lees por bloques (usando MAP_SetRegion en este caso), por ejemplo:

Y lo ideoneo es usar PNG, mantiene la calidad completa de la imagen, comprime mejor que muchos otros formatos y permite definir tranparencias a distintos niveles de opacidad (degradados).

Sí, yo también estoy a favor del formato PNG siempre, pero no entiendo eso que dices de "pocos" colores. Si te refieres a que un formato de colores indexados, pues no sé por qué van a tener que ser pocos colores, siempre puedes hacer una paleta de colores de tantos colores como desees.

- Soporte para formatos contenedores ZIP así como PK2 (quake2), PK3(quake3) y WAD(Doom). Añadiendo soporte  para

esos otros formatos nos ofrecería mucha más flexibilidad a la hora de trabajar con los juegos que usan dichos

formatos, por ejemplo, desde poder crear herramientas para esos juegos hasta poder incluso crear engines enteros, o

juegos que usen esos datos sin necesidad de extraerlos y/o distribuirlos (con el derivado problema legal que ello

podría acarrear).

Nada te impide usar un componente externo para usar ZIP's o PK3 (que es exactamente el mismo formato que el ZIP). Piensa que para implementar la lectura de estos formatos (o cualquiera) se ha de tener informacion sobre sus estructuras y demas y saber implementarlas y es mucho trabajo si tengo tambien que trabajar otras areas de la libreria como graficos o audio. A mi el formato PAK me servia de sobra para mi proposito, por eso no busque implementar otro formato (y de hecho en desarrollos en .NET usaba el formato ZIP gracias a una libreria gratuita que hay para tal fin, si no, hubiera seguido usando el formato PAK).

Me refería a formato ZIP comprimido y PK2, PK3 y WAD sin comprimir.

Además, estos tres últimos formatos son bastante conocidos y puedes ver cómo funcionan echándole un vistazo al código fuente del Quake 2, Quake 3 y Doom, que han sido liberados bajo la GNU/GPL, o incluso viendo el código fuente de Source Ports de dichos juegos.
También hay multitud de herramientas diseñadas para manejar dichos formatos, y, aunque seguramente están en C/C++, podrían ser de utilidad para lo que es la lógica del funcionamiento.

Yo sé cómo funciona el formato WAD de Doom (creo que el de Half Life varía un poco), y no es nada difícil:
contiene tres partes:
1.- Una cabecera: está el principio del archivo. Informa de qué tipo de WAD se trata (si es oficial de iDSoftware o modificado). También indica dónde empieza el Directorio (ver abajo)
2.- Un Directorio. Está al final del archivo, y contiene la posición de cada uno de los contenidos del WAD, es decir, de la posición en donde empieza cada una de las imágenes, sonidos, músicas etc...
3.- Los Contenidos del archivo. Es decir, la música, imágenes, sonidos y demás. Empiezan con un valor que indica el tamaño en bit (o bytes?, ya no me acuerdo) de dicho contenido.
Para saber qué tipo de contenido estamos leyendo, ahora mismo no me acuerdo si esto se indicaba en el principio de cada uno de ellos, o en cada entrada del directorio.

Como ves no es muy difícil. De hecho yo había hecho algo para visualizar los contenidos de un WAD en C hace ya algún tiempo y con pocas líneas de código.
He intentado hacer algo similar en VB5, pero nunca me llegó a funcionar.

- Pixel Shaders. No creo que sea muy difícil, y menos aún cuando ya parte del trabajo está hecho.

Pues creeme que si, si es difícil (la ultima versión iba haber tenido soporte de pixel shaders), y mas teniendo en cuenta que los pixel shaders no se comportan igual en la API de DirectX de Visual Basic 6.0 que en la API original de C++ (la mayoria de los ejemplos del SDK de DirectX no funcionan en VB6.0) y luego que solo tendriamos soporte para shader model 1.1 (DirectX8) lo cual, creeme, no merece la pena dado el coste de aprender a programar shaders en esa version (lenguaje ASM de la GPU) y por lo limitados que estan respecto a versiones mas modernas como la 2.0 (y sin contar que la libreria estaba pensada para funcionar con tarjetas graficas anteriores a una GeForce 3, que es la primera implementar pixel shaders.

Yo en realidad no tenía mucho interes en shaders, pero como he leído por alguna parte del foro que alguien preguntaba por ellos, pues simplemente lo puse, a ver si colaba xD

- Rutas. Es decir, un sistema que permita trazar líneas entre dos puntos (virtualmente, NO dibujarlas) y que calcule posibles colisiones en su trayecto. Es decir, trazar una línea y comprobar si un punto interseca con dicha línea.

Esto como decia mas arriba, es mas propio de un motor de juegos que de una libreria de apoyo. Segun el juego hay mil formas de implementar un escenario y su información (un mapa de tiles, un mapa de durezas, vectores...), y de ahi, otras tantas de implementar un algorritmo u otro para busqueda de caminos. Yo por ejemplo, para mi juego, no preciso pathfinding y de haberlo necesitado hubiera implementado dicho codigo en el motor del juego y no en dx_lib32 directamente.

Bién, aquí creo que hay un problema de entendimiento.
No me refiero a pathfinding en absoluto, si no a algo así como el Algoritmo de Bresenham.

- Y ya que dx_lib32 está pensada para juegos, creo que es necesario (no sé si ahora está implementado, pero por si acaso...) implementar alguna función de espera como "Wait(miliSeconds As Long)". Así se evitaría el uso de controles Timer, que la verdad, a mi nunca me han gustado. Esta función detiene la ejecución de la función actual, pero no la del programa en general. Sería como "pausar" un thread en una ejecución  multihilo de entre varios que se están ejecutando, pero hacerlo durante un tiempo definido, NO hasta que el jugador lo reactive de nuevo.

Idem, esto es cometido de un motor. Tu puedes pensar que usar un Wait() te puede resultar ultil pero otra persona a la hora de hacer su juego puede pensar que le interesa mejor usar un sistema de componentes con su logica propia y realizar las esperas en base a eventos por ejemplo. Esto es puro diseño de programacion y cada cual tiene su forma o su patron preferido. Yo por ejemplo, desde las ultimas versiones de mi motor (el del juego) en VB6.0 y la actual en XNA 4.0, utilizo un sistema de "componentes" para definir entidades (personajes, items, enemigos, las fisicas, menus, el propio escenario, lo que sea que tenga algun codigo de logica) que separa codigo de dibujo de actualizacion de logica, como si fuesen dos ramas distintas, y estos componentes tienen dos estados, visible y enabled, uno determina si se dibuja el objeto y otro si esta activo (si ejecuta su codigo de logica, por ejemplo: la IA de un enemigo, la lectura de input, las colisiones, cualquier accion que realice el objeto). Ya solo con el estado enabled puedes detener un objeto del juego hasta que otro lo active (o un evento del propio objeto). Este patron de diseño es sencillo y claro y se adapta a muchos escenarios en programacion (y es el que se usa en XNA por ejemplo).

Me refiero al Wait() como función opcional que puede usar el programador cuando desee.
Sé que es fácil hacer algo así usando la función Time(), pero vamos, que incluir algo así en dx_lib32 pues tampoco es tan largo de hacer.

Despues de todo este tocho, piensa que muchas cosas que comentabas son puramente funcionalidades de un motor de juegos. dx_lib32 cumple una funcion de base, no esta diseñada para cubrir al completo el desarrollo de un juego pero si facilitar el no tener que preocuparte de lo que ocurre debajo de tu programa (DirectX, Windows, etc...) y piensa que siendo como es de inestable Visual Basic 6.0 no es muy recomendable complicar mucho la programación mas allá de lo que permite el lenguaje en si (programación multihilo por ejemplo es sinonimo de loteria en VB6.0 al igual que intentar exprimir demasiado la orientación a objetos limitada que ofrece). Siempre hay formas mas sencillas de implementar la lógica de un juego y generalmente no es necesario recurrir a programacion multihilo, simplemente saber separar u ordenar por prioridad la lógica de tus elementos (un sistema de componentes como el que mencione antes te puede servir perfectamente).

Salu2 y gracias por el interes en la libreria, en serio, se agradece mucho :)

A decir verdad, la ejecución multihilo en un juego 2D sencillo como los que se ven por aquí, no lo veo realmente necesario, aunque puede ser útil en alguna situación.


Sea como sea, gracias por compartir tu trabajo con la comunidad. :-)

[[EX3]]

En realidad, yo estoy usando dx_lib32 bajo VB5. Y funciona perfectamente.

Y si es por que Vb5/6 están ya desfasados, en verdad tienes razón, pero de todas maneras creo que Visual Basic 5/6 son más que suficientes para implementar juegos 2D como los que se pretenden hacer con dx_lib32.
Otra cosa es que ya nos queramos meter con entidades y demás, pero para eso ya usaríamos otras libs diferentes.

Si dx_lib32 suficiente para ello es, el problema es cuando tienes que hacer un desarrollo minimamente complejo como el que estoy desarrollando (un motor escalable para un juego plataformas tipo Another World) y la idea es que el codigo este bien organizado y sea sencillo de mantener (complejo y sencillo es un duo dificil de conseguir). Yo opte por implementar en lo maximo que permite el lenguaje la orientacion a objetos en lo que al motor del juego se referia. El asunto que entre varias librerias como formaban el motor y el cruce de referencias que generaban se ve Visual Basic 6.0 internamente llegaba a un punto en el que se perdia a mapear las clases y dependencias en codigo, lo que a veces imposibilitaba el poder programar contra un objeto que esta en codigo pero que el interprete no veia.

He visto por internet más de un juego realizado con Visual Basic 5/6 y Direct3D que, aunque no eran el no-va-más, sí eran interesantes desde el punto de vista de que es posible hacer cosas útiles con Vb5/6 y Direct3D, sin necesidad de XNA.

Hay cantidad de juegos como dices que aprovechan muy bien la API de DirectX8 para Visual Basic pero suelen ser proyecto cuyo codigo esta diseñado a medida del desarrollo, no suelen ser motores "genericos" para multiples desarrollos. Sobre lo de XNA en Visual Basic 6.0... me da que dificil que encuentres algun proyecto asi tratándose de un framework de .NET :P

Respecto a lo que dices de usar engines ya prediseñados para crear nuestros propios juegos, pues yo jamás estoy a favor de ellos. No me gusta usar algo que no sé realmente cómo dibuja las imágenes en pantalla, ni cómo carga o descarga de memoria los datos, etc...
Además, si comparamos dichos engines con la programación pura, no suelen estar tan optimizados como un motor que hago yo a medida para mi juego, eliminando funciones que consumen tiempo de procesador y que no voy a usar, cosa que no puedes hacer con los motores ya prediseñados.

Ahi estoy totalmente en desacuerdo. Me explico. Esa idea equivocada de tener que saber como trabaja debajo x herramienta no tiene sentido cuando el proposito es, en este caso desarrollar un juego. Yo no necesito saber como trabaja DirectX por debajo, solo necesito saber que tengo que usar para dibujar un sprite por ejemplo. Sobre optimizacion, generalmente estos motores que hablo, Unity3D por ejemplo, estaran mucho mas optimizados de lo que podria estar tu codigo o el mio por el simple hecho de que detras de esos motores trabajan grupos de ingenieros cada cual dedicado a su tarea especifica, en graficos por ejemplo tendran gente que sepa como crear una pipeline optimizada tanto para mover un grupo de sprites en escena como un conjunto de geometria con transformaciones dinamicas y que el motor sepa lo que tiene que procesar o no para consumir recursos de mas, es como si dijeramos, segun el desarrollo que tengas hecho de tu juego el motor define un camino optimo para llegar a ese resultado que no tiene que ser el mismo para cualquier otro juego que desarrolles (piensa que son sistemas dinamicos). Tampoco pienses que estos motores son point&click, tienes que programar y no poco, pero programar la logica de tu juego, la logica de tus personajes, enemigos, objetos, etc... el resto, el diseño de niveles, el como y donde colocas las cosas, es visual, de igual forma que en Visual Basic los formularios no los programas, los dibujas y arrastras controles, solo programas los eventos. Esto es igual.

Ten en cuenta tambien que estos motores, Unity3D, Unreal Engine (UDK en su version indie) o mas sencillos como GameMaker por ejemplo, suelen ser modulares. Tu puedes descartar funcionalidades del motor que no necesites o no uses e incluso poder programarte externamente librerias para ampliar o reemplazar partes del motor para algun proposito concreto (en Unreal Engine por ejemplo existen varios juegos que implementan su propio motor de iluminacion como Mirror's Edge). Lo unico que no puede gustarte de estas herramientas es como se realicen algunas tareas. Yo por ejemplo Unity3D, me gusta su sistema de scripting por que es C# (.NET) pero este motor tiene un paradigma concreto de componentes que mas que no gustarme no "entiendo" del todo a estas alturas (aunque no me impidio desarrollar un pong en poco mas de 10 minutos o hacer un escenario 3D con un modelo animado controlable). Lo unico "malo" si se puede decir asi, es que tienes que adaptarte un minimo a como funcionan, pero eso para nada te limita (es como si estuvieramos hablando de paradigmas de programacion modular y programacion orientada a objetos, realmente puedes hacer lo mismo con uno y con otro solo que de distinta forma).

Lo importante de este tipo de herramientas es que si vas a desarrollar juegos te interesa que la herramienta te ofrezca lo que necesitas para tu cometido, que te evite tarea innecesaria como gestionar texturas, animaciones o la logica de colisiones, e incluso, hoy dia, que te brinden un entorno integrado donde realizar la mayor parte del diseño de tu juego (imagina un Visual Basic 6.0 que aparte de editor de formulario tuviera un editor de escenarios donde diseñar niveles y poner personajes). Yo si tengo que hacer un juego 3D con fisicas no me voy a programar un motor desde cero y mucho menos fisicas realistas cuando ya me lo da un motor preparado (ej. Unity3D) al igual que en .NET no estoy programando una dx_lib32 teniendo XNA y un sin fin de herramientas mas.

Si haces juegos haces juegos, pero hacer motores y hacer juegos... no siempre es compatible, lo ideal es programar lo necesario y eso deberia ser solo el juego, no la herramienta :)

Sí, yo también estoy a favor del formato PNG siempre, pero no entiendo eso que dices de "pocos" colores. Si te refieres a que un formato de colores indexados, pues no sé por qué van a tener que ser pocos colores, siempre puedes hacer una paleta de colores de tantos colores como desees.

El formato GIF solo acepta 256 colores (8 bits), un PNG estamos hablando de 32bits de color (16 millones de colores). Trabajar con paletas... eso tenia sentido años atras justamente por que no se podia trabajar con mas de 256 colores y habia que hacer trucos para simular distintas gamas de colores, hoy dia tienes la comodidad de no depender de las paletas. Amen a parte, DirectX no trabaja con formato GIF, no es capaz de leerlo (ni estático ni animado), lo cual significa que si hubiera tenido que usarlo en mi librería hubiera supuesto mas programación, por lo tanto mas perdida de tiempo.

Me refería a formato ZIP comprimido y PK2, PK3 y WAD sin comprimir.

Además, estos tres últimos formatos son bastante conocidos y puedes ver cómo funcionan echándole un vistazo al código fuente del Quake 2, Quake 3 y Doom, que han sido liberados bajo la GNU/GPL, o incluso viendo el código fuente de Source Ports de dichos juegos.
También hay multitud de herramientas diseñadas para manejar dichos formatos, y, aunque seguramente están en C/C++, podrían ser de utilidad para lo que es la lógica del funcionamiento.

Para formatos ZIP como te decia existen infinidad de componentes y librerias para Visual Basic 6.0, lo cual no tenia sentido que yo me programara funciones propias. El por que dx_lib32 implementa el formato PAK viene simplemente a que un programador de otra comunidad se dedico a portar la implementacion de Valve de Half-Life de C++ a Visual Basic 6.0 y de que existia un editor gratuito muy simple y comodo para editarlos (el que esta en la seccion de descargas). El codigo fuente del formato PK3 y similares los tienes en la web, si les hechas un vistazo veras que no son implementaciones sencillas y que muchas partes del codigo no son traducibles a Visual Basic 6.0 ni con ayuda de la API de Windows.

Yo en realidad no tenía mucho interes en shaders, pero como he leído por alguna parte del foro que alguien preguntaba por ellos, pues simplemente lo puse, a ver si colaba xD

Yo en su momento los estuve mirando de implementar simplemente por buscar una via rapida de implementar efectos de iluminacion que con blendestates no era capaz (o conseguir efectos como tonalidades sepia). Hubiera quedado interesante pero no pudo ser por lo comentado antes :-/

Bién, aquí creo que hay un problema de entendimiento.
No me refiero a pathfinding en absoluto, si no a algo así como el Algoritmo de Bresenham.

Ese algorritmo te puede servir si representas tu escenario como un mapa de bits por ejemplo (un mapa de durezas) pero en un espacio vectorial como yo uso en mi juego, en el que cada objeto tiene su tamaño propio en incluso diferente profundidad ahi no me sirve, tendria que usar un sistema de nodos para implementar A-Star por ejemplo :) A esto me refiero, hay muchas formas de representar escenarios y segun la necesidad varias implementaciones para cada situacion y profundizando mas, cada implementacion se puede modificar para adaptarla casos concretos (ej: mezclar A-Star con Dijkstra's).

Me refiero al Wait() como función opcional que puede usar el programador cuando desee.
Sé que es fácil hacer algo así usando la función Time(), pero vamos, que incluir algo así en dx_lib32 pues tampoco es tan largo de hacer.

Pero hacer una espera "selectiva" (selectiva = detener ciertos objetos del codigo un intervalo de tiempo) como dices sin multihilo ya viene a ser realizar una espera en un intervalo de tiempo que puedes hacer con los cronometros que ofrece dx_lib32 (y no me refiero a los cronometros de procesos para ejecutar métodos a intervalos si no los cronometros de tiempo) e implementando un sistema similar al de componentes que te mencionaba donde esa espera la realice el código de lógica del propio objeto.

A decir verdad, la ejecución multihilo en un juego 2D sencillo como los que se ven por aquí, no lo veo realmente necesario, aunque puede ser útil en alguna situación.

La programacion multihilo es un caos muy a tener en cuenta ya que hay saber controlar muy bien temas como cuando lees y cuando escribes en una variable y que no lo hagas al mismo tiempo desde distintos sitios. Es un tema muy complejo y que de hecho Visual Basic 6.0 es incapaz de soportar sin fallas serias, ademas, plantear y diseñar codigo para un sistema multihilo es muy complicado: donde esta el principio de un ciclo de la escena y donde acaba, o como controlas el orden en que se dibuja antes o despues un objeto, o como comunicas coherentemente objetos en un determinado momento de tu juego y que solo mande un mensaje a la vez y no varios al mismo tiempo, etc... La mayoria de los escenarios de un sistema multihilo se pueden desarrollar perfectamente en un sistema monohilo, ahi es cuestion de saber implementar sistemas de esperas, prioridad y separacion de tareas, otra vez sirva de ejemplo el sistema de componentes y entidades. Dicho sistema que uso en mi juego me permite definir tanto una prioridad para el orden de dibujo de los objetos como una prioridad para el orden en que se ejecutan los objetos en la escena. Esto me permite por ejemplo que un grupo de objetos se dibujen antes que el resto pero que se ejecuten en ultima instancia antes que los demas (quizas te interesa que el jugador se dibuje sobre los demas, osea, el ultimo, pero necesites que se ejecute antes que el resto de objetos, osea, que se ejecute el primero).

Salu2...

P.D.: Buff, creo que llevaba años que no soltaba post tan largos :D