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 
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. :-)
