La virgen santa madre de dios.

Al igual que Hechelion, quoteraría a todo, pero es que me es imposible hacerlo.

En respuesta general a todo: a parte de los "tilesets" de modelos 3D, ningún otro juego del mercado usa tilesets para los gráficos.
Además ya que comentais que los modelos 3D usan tilesets (lo cual ya sabía), es un uso mínimo, ya que las texturas de los modelos suponen una carga mínima en comparación con el uso de las texturas y demás efectos gráficos, así que no tiene sentido decir que los modelos 3D usan tilesets por que así alijeran el framerate.

Por otro lado, no sé si habeis trasteado con juegos más o menos modernos, pero por si acaso no lo sabéis, éstos cargan en memoria TODO DE UNA SOLA VEZ, es decir, no cargan y descargan cosas a medida que se juega, si no que lo hacen al empezar el nivel, y es por eso que algunos tardan bastante en cargar.
Si no fuera así, sólo tardarían unos segundos en empezar, y el framerate sería ínfimo durante la partida.
De hecho, os puedo poner ejemplos reales: he hecho MODs y mapas para Quake 4 y os digo que por muchas texturas sueltas que use, el framerrate del juego se mantiene estable. Sólo baja cuando hay estructuras complejas o saturación de efectos gráficos, pero nunca por la IA ni cosas similares.

También hablais de que los modelos 3D usan tilesets. Y no se hace por que sea más eficiente o más bonito, si no por que es má fácil de usar un tileset para los skins de armas y monstruos que usar varias texturas diferentes.
Sin embargo, la carga CPU/GPU/lo_que_quieras de las texturas de los modelos es ínfima comparada con la carga de cpu/gpu/... del resto de los contenidos del juego.

También tenemos por otro lado la famosa "llamada para buscar" el tile dentro del tileset.
Está claro que para un jueguecillo simple no representa mucho, pero para algo ya más pesado, el tener que realizar no_se_cuantas llamadas para buscar el tile correspondiente puede ser algo considerable, y quizás más que la sobrecarga de la GPU/CPU para abrir y cerrar ese mismo número de texturas sueltas.

Así que por un lado tenemos ficheros sueltos:
Interpretar Mapa->Abrir textura->Colocar textura

y por el otro, tilesets:
Interpretar Mapa->buscar lugar y posición del tile (fichero de índices)->abrir tileset->buscar tile (buscar=ir a coordenadas)->Colocar tile
Y para accesos a posterior, sólo nos saltamos el paso de "abrir tileset"


No sabría decir cuantos ciclos necesitarán cada uno de ellos, pero yo votaría por que el segundo necesita más.


Eso sí, si hablamos de acceso a disco (que es lento), el método de tilesets es mejor que el de ficheros. Cosa que es indiscutible,


Y aún así, para juegos realizados con dx_lib32, no creo que se note ninguna diferencia de frames por segundo de un método al otro (y en absoluto no estoy desmereciendo dx_lib32), pero de usar tilesets a usar ficheros sueltos, me ahorro el tener que diseñar, implementar, y mantener una rutina y programar un editor que es básicamente imprescindible para el manejo adecuado de los tilesets, mientras que con ficheros sueltos, sólo tengo que seguir unas reglas de nomenclatura sencillas, sin ni siquiera tener que usar más herramientas.

Sea como sea, se agradece vuestra oponión.
Quizás experimente algún método que use tilesets y ficheros sueltos.
Así todos contentos xD

Saludos. :-)

No me refería a eso.
Su pongamos que, como en mi caso, necesito usar gran cantidad de texturas de suelos, paredes y sprites  (para usar como animaciones o como decoraciones).
Si uso tilesets, por supuesto que puedo tener varios tilesets que contengan un tipo determinado de gráficos, por ejemplo "tilesteSueloCiudad.png", "tilesetSueloBosque.png", etc...
La cosa es que si en uno de los supuestos mapas sólo tengo que usar tres tipos de tiles que estan dentro de "tilesetSueloCiudad", más otros tres tiles diferentes de "tilesetSueloBosque", pues estoy obligado a cargar en memoria todo el tileset entero, a pesar de que voy a usar solamente un par o tres tiles de cada uno de ellos. Se ve claramente que hay un uso innecesario de memoria RAM. Puede que para un RPG que usa sólo dos o tres tilesets, no signifique mucho, pero los gráficos que yo tengo que usar podrían llegar a los 150 ó 200 Mb entre todos. Si a ello le sumamos los sonidos más la música (son MP3s de unos 25-30 Megas), podríamos alcanzar los 300Mb sin ni siquiera darnos cuenta.

Sin embargo, con un PAK o un directorio y subdirectorios, simplemente cargaremos las imágenes que necesitemos exclusivamente.
Sé que es peor cargar y leer "cada dos por tres", pero tampoco es ese el caso, ya que los gráficos a usar se cargan solamente en memoria cuando se inicia el nivel, por lo tanto de estar usando 150Mb pasaríamos a usar poco más de 20Mb. Además con la potencia actual de los ordenadores apenas serían unos segundos de carga. Otra cosa, y esto es indiscutible, es que tuviera que cargar y "descargar" gráficos de memoria a cada frame.

Ahi estas teniendo un problema de diseño si has de cargar 300mb o mas datos en memoria (aunque sea repartida entre la memoria grafica de la GPU y la memoria RAM del sistema). Si usas tilesets es para organizar que necesitas cargar en memoria y que no, no para cargar todo. Obviamente si usas tilesets no vas a cargarlos para leer 3 texturas de uno y 3 de otro, se trata de que las organices de forma que con un tileset grande tengas todos los tiles de un escenario por ejemplo. Si yo tengo que definir un escenario que es un hangar lo mas seguro es que tenga todos los tiles de la tematica hangar en el mismo tileset y no repartidos en varios como suelo, paredes, etc... esto es puro tema de diseño al crear los tilesets, no de que no sean óptimos.

No, si ya entiendo eso lo que comentas de que cada tileset tiene su propia clasificación, pero ¿qué ocurre si tienes que usar texturas de bosque y texturas de nave espacial? Seguramente tengas un tileset para bosque y otra para nave espacial, por lo cual vas a tener que cargar en memoria ambos tilesets para acceder a las texturas correspondientes.
Y la cosa se podría complicar si tienes que usar texturas de nave espacial, de bosque y de ciudad (por ejemplo para simular un escenario urbano con naturaleza y elementos como naves espaciales pequeñas).

Lógicamente, y es imposible estar en desacuerdo contigo, se organizará la cosa lo mejor posible.

No sería posible para tilesets que no pueden tener un orden o tamaño definidos, por ejemplo, yo tengo tres "animaciones" de monstruos. Cada animación posee "frames" y "states".
Un frame es cada uno de las imágenes que conforman una parte de la animación (como por ejemplo, mover el pié izquierdo cuando camina). Es quizás otra manera de llamar a los tiles.
Un state es cada uno de los tipos de "animación", por ejemplo, el state "atacar", el state "correr", etc...

En teoría, no habría problema si todos los monstruos tuviesen sus tiles del mismo tamaño y en posiciones relativas equivalentes, pero como no es así, resultaría imposible mediante un método "universal" conocer exactamente qué posición y qué dimensiones tiene cada tile de cada monstruo.

Si te fijas en el tileset del marine, ningun tile es del mismo tamaño, las piernas no tienen el mismo tamaño entre si por ejemplo, puedes comprobarlo :) Ese editor permitia definir tiles del tamaño que fuesen y en la posicion que estuvieran dentro de la textura. Tu en un mismo tileset puedes tener tranquilamente distintas animaciones del mismo personaje de los tamaños que quieras y ordenarlas como quieras en tu lista de frames, una cosa es como venga distribuidos los tiles en la textura y otra como ordenes tu la lista de frames.

Creo que ya entiendo cómo has implementado lo de los tiles: si mal no he entendido, básicamente usas dos ficheros: uno con los tiles (uno o los que sean) y otro con los índices de posiciones y demás info.

Siendo así, ya lo veo más viable, pero aún así, no sé hasta qué punto podría ser interesante el uso de tilesets para juegos que usan una gran cantidad de gráficos, todos ellos diferentes entre sí.

Pero de todas maneras, intentaré experimentar con algo como lo que tú hiciste (tileset/s + fichero de índices), pero con mis propias rutinas.
Quizás pueda conseguir una solución interesante...

Sin embargo, con directorios o PAKs, simplemente hago una llamada a un método que carge la imagen cuyo archivo se llama, por ejemplo, "zombieWalk01.png", y así con todos los frames de "zombieWalk".

Con tilesets igual. La textura por un lado y tu archivo que defina la tabla de tiles y animaciones por otro. Ventajas? En dicho archivo puedes definir parametros de tu animacion, tiempos de lapso entre frames, sentido predefinido de la animacion, si es bucle o no, puntos de control para definir puntos calientes en tus tiles (si has programado con Div Game Studio sabras de que te hablo) y cualquier cosa que necesites. Esa flexibilidad el archivo PAK no te lo da. Tu "zombiewalk" seria sencillamente una animacion con un nombre definida en la tabla de animaciones que internamente no dejaria de ser una lista de las claves de los tiles que la forman, en que orden van y que tiempo de lapso tiene entre ellas.

Es decir, lo que he comentado justo arriba.

Pues más organizado que un directorio y subdirectorios no encuentro yo otra manera, y mças aún si dentro de "suelosBosque" puede haber varios tipos diferentes, como por ejemplo "hierba", "árboles", "agua", "tierra" y dentro de cada uno de ellos más clasificaciones todavía.

Bueno, esto es discutible, para mi es mas organizado tener un tileset con todos los graficos de "arboles de bosque", por otro tener "arboles de costa", etc... aqui puede ser mas gusto que otra cosa. Esa organizacion de directorios yo lo aplico pero en un nivel por encima de lo que es un tileset, osea, lo usaria para organizar los tilesets en si, asi como el resto de recursos (sonidos, mapas, etc...), pero yo es que yo no considero un tile un recurso si no parte de un recurso (esto es como si dijeras de en vez de usar fuentes de texto crearas un grafico por cada caracter de la fuente en si, seria lo mismo).

Supongamos un juego de plataformas "sidescroll" (osea, tipo mario bros). En el nivel 1, el jugador empieza a la izquierda de todo en un ambiente costero (tiles de arena, de agua, de árboles de costa, etc...). A medida que avanza hacia la derecha, se va transformando en bosque (hierba, árboles de bosque, tierra, etc...) y finalmente se convierte en una ciudad futurista (tiles de edificios, de asfalto, partes metálicas, lices de neon, etc...).
En esta caso, y que es bastante normal, tendrías que cargar tres tilesets diferentes.
Si cada tileset ocupa 5 Mb, pues ya estás consumiendo 25Mb, sólo para buscar 10 o 15 tiles diferentes.

Pero por otro lado, con PAKs sólo consumes la memoria de los gráficos que necesites. Claro que vas a realizar más accesos a disco y demás.

Es decir, lo que uno tiene de ventaja, otro lo tiene de desventaja.
Creo que podría ser cuestión de gustos :-P

Pero es que el problema de eficiencia aparece cuando tienes que usar tiles de diferentes tilesets: no sólo se desperdicia RAM si no que también tienes que realizar varios accesos a disco, uno por cada tileset cargado.

Lo primero que con accesos no me refiero a disco (cargar la textura desde el disco duro) si no a la accion que realiza la GPU al dibujar una textura que es cambiar la textura del buffer por otra. Ese acceso tiene un coste de rendimiento a la larga. Un par de ejemplos:

Un tileset (el del marine que te mostre mas arriba), 100 marines en pantalla con distintas configuraciones, contando con que cada marine tiene, digamos, 4 partes (piernas, brazos, torso, cabeza), por cada marine solo accedo una vez a la textura a la hora de dibujarlo aun cambiando el tile de animación o estado (disparo, carrera, etc...) ya que todas las partes estan dentro de la misma textura. 1 x 100 = 100 accesos, si dibujo todos los marines de una tacada no hay cambio de textura al dibujar, entonces solo tendria un solo acceso a la textura para dibujar los 100 marines.

Una textura por tile (texturas de brazos, piernas, cabezas, armas, etc...), 100 marines (igual configuración, 4 piezas) por cada marine tendría que acceder en un solo frame (sin animar) a 4 texturas distintas (4 x 100 = 400 cambios de textura al dibujar los 100 marines) y siendo animado multiplica esos 400 accesos por fotogramas que tenga la animacion. Aunque dibujes todos los marines de una tacada seguirías teniendo 400 accesos a texturas en memoria.

Entonces, que metodo realiza mas accesos por frame? Cual consume mas proceso para hacer lo mismo?

Pero, hablando de PAKs/Dirs, se pueden cargar todos los frames del marine (creo que son 50 o así), al principio del nivel, mientras éste se carga, por lo que ya tendrías en memoria todos los frames de susodicho marine.

Ese es el problema: que la clasificación de gráficos con tilesets no la veo tan óptima como con PAKs/Dirs.
Además, usando tilesets, tu programa tiene una modabilidad (no sé si en español sería algo así como "capacidad de ser modificados los gráficos y demás") limitada, ya que el motor de tu juego sólo podrá trabajar con tilesets que usen una distribución idéntica a la original, para la cual ha sido pensada. Alguien que quiera usar un tileset diferente no podrá.

Falso. Si alguien quiere usar su propio tileset con mi motor sencillamente tendria que usar la misma herramienta que use yo, que es la te mostre mas arriba, tendria que cargar su textura, definir los tiles y organizarlos a su antojo, definir sus puntos de control si los necesita, y las animaciones que tuviera o necesitara. Despues solo daria a un boton para generar el archivo con la tabla de tiles y animaciones listo para ser usado al momento en el motor (que dicho sea, la clase Sprite que usaba mi motor realizaba todo el proceso en una sola y unica llamada, al cargar dicho archivo se preparaba toda la informacion de tiles y animaciones de forma automatica, mas facil imposible).

Sí, eso sí, pero si la persona que quiere hacer alguna modificación tendrá que crear también el fichero de índices, además de tener que usar ese programa que has puesto arriba para organizar los tilesets y sus tiles.

Pero con ficheros dentro de PAKs/Dirs, simplemente habría que nombrar a los archivos con un nombre cualquiera más un índice, sin necesidad de usar otras herramientas.

Si has dedicado tiempo alguna vez haciendo mods para juegos como Half-Life veras que el uso de archivos paquete se utiliza para cosas mas practicas como control de versiones, esto es, yo distribuyo el juego con unos recursos pero mañana tengo que actualizar parte de ellos y en vez de pasarte un unico archivo paquete con todos los recursos + los modificados solo te paso un paquete con los recursos modificados, que al ser mas actuales el motor toma en cuenta a la hora de buscarlos en el arbol de recursos que genera al iniciarse el juego (listas todos los recursos ordenando los paquetes que haya disponibles bien por fecha o bien por nombre como hacia el Half-Life). Mas alla de esto, motores como Half-Life al final usaban tambien tilsets para sus texturas (un formato de archivo que contenia el mapa de texturas y la tabla de referencia a las mismas) y asi tecnologias actuales siguen funcionando con la misma mecanica. Por algo sera, no? :)

No es por desmerecer tu opinión, pero si hablamos de juegos modernos, no sé cuál usa tilesets o algún método análogo para almacenar los gráficos.

De hecho, creo que desde Wolfenstein3D hasta hoy en día, el 90% de los juegos, bién sean 3D ó 2D, usan algún sistema de almacenamiento de gráficos como PAKs, ZIPs, directorios o similares.

Lo que si seria practico con un archivo PAK es hacerte un formato contenedor que, por ejemplo (y es lo que hacia tambien Half-Life con los modelos 3D) es contener  la definicion de tu personaje, sus animaciones, que partes lo forman y el tileset que usa. Eso seria practico por que asi no tendrias archivos sueltos en un directorio si no solidamente en un archivo, pero claro, esto al final no afecta al rendimiento del motor, esto, como lo de los paquetes, es puro mantenimiento para el desarrollador, ya que de esto no se beneficia para nada el jugador ni el juego en si y en estos temas hay que medirse y saber hasta que punto merece la pena invertir esfuerzo en mantenimiento y cuanto en desarrollo del juego en si. Yo, por ejemplo, en mi version actual de XNA ya no uso tilesets con frames de distintos tamaños si no el tileset tradicional de todos los frames en fila y con el mismo tamaño. Esto me ha evitado tener que programarme otro editor de tiles con todas las funciones que veias y el codigo de logica de las animaciones se ha reducido a un par de lineas y a interpretar un XML que autogenera el juego a modo de editor en una simple llamada. Sencillez ante todo.

Bueno, claro, pero es que en este caso estamos hablando de modelos 3D que lógicamente es imposible almacenar en tilesets :P

Y ahí mismo has dicho tu el problema, si alguien quiere, en un motor de XNA, usar un tileset con tiles de 32x32, mezclados con 48x48 o incluso 32x48 o 16x64, ahí ya tendría un problema.
Incluso el propio programador (tú) necesitarías hacerte tus propias rutinas para casos específicos, limitandote a la hora de la "libertad de modificación".

Si tu consideras que organizarte por paquetes es mas beneficioso para ti que usar tilesets adelante pues, puede serte mas o menos comodo separar tiles por textura que andar definiendo tablas de tiles y una sola textura pero desde luego no es optimo por como funcionan las tarjetas graficas a la hora de acceder a su contenido como ya te hemos explicado y no es cuestion solo de enfocarse en gastar poca memoria o en optimizar hasta el maximo si no de tener un equilibrio entre ambos.

Salu2... ;)

Soy un acérrimo seguidor de la organización jerarquizada.

P.D.: Lo que si seria interesante a medio camino de tu idea de los paquetes y los tilesets seria que al cargar los tiles que necesitas los unieras en memoria bajo una misma textura (respetando el tamaño de potencia de 2) que fuera la que usaras como tileset autogenerado para dibujar en el juego, seguirias manteniendo tu sistema de organizacion por directorios en los paquetes y tendrias optimizado la parte del acceso a las texturas en memoria, lo mejor de ambos mundos aunque con un coste de desarrollo mayor :)

No me parece mala idea. Aunque tampoc la veo tan buena, ya que tendríamos que cargar en memoria todos los gráficos de juego desde el principio.
Para el sistema de índices, podría implementarse un directorio (un fichero de texto) dentro del propio PAK (o incluso fuera de éste) que contenga un listado con el nombre de los carpetas y subcarpetas virtuales del PAK, de manera que crear un sistema de indexación durante el runtime (creo que en español sería "tiempo de ejecución") sólo sería cuestión de interpretar el directorio (el archivo de texto), y nombrar a cada gráfico con el nombre de su carpeta contenedora y un índice que indique su "posición" dentro de la carpeta virtual.
También habría que generar por cada gráfico la posición de su esquina superior derecha, su anchura y altura.

No parece muy complicado, aunque a decir verdad, no sé si dx_lib32 ofrece algun método para obtener esta información de un gráfico, al menos su altura y anchura.

Además, otra ventaja que acabo de darme cuenta: permite una gran libertad a la hora de ser modificado por otros usuarios: éstos solamente tendrían que crear un fichero con un listado de la estructura de directorios y subdirectorios del PAK.
Luego, el editor de mapa, se encargaría de realizar el sistema de indexación y añadir los gráficos a la lista de gráficos.
Y finalmente, el juego haría lo mismo que el editor de mapas, pero pondría las texturas apropiadas según se indique en el mapa.
Es más, podría generarse el archivo de índices una única vez y almacenarlo en cualquier sitio, incluso dentro del propio PAK. Esto evitaría tener que generarlo y perder tiempo más de una vez.

Creo que nos hemos entendido mal y creo que yo soy el culpable: he programado siempre en entornos y con gente en Inglés, y algunos conceptos pueden no ser correctos.
Vayamos por partes:

Para empezar, el tileset parece ser menos eficiente en cuanto a memoria usada. Hay que darse cuenta que para usarlo hay que cargar toda la imagen entera en memoria. Para imágenes pequeñas no es un problema, pero cuando hay que usar muchas imágenes y de tamaño considerable, el consumo de memoria puede ser elevado (en mi proyecto tengo que usar más de 20 tilesets y cada uno de 512x512)

Craso error, es mas optimo usar una textura con todos los tiles o fotogramas de una animacion y dibujar secciones de dicha textura que tener varias texturas en memoria por tile y dibujarlas independientemente. A la tarjeta grafica le resulta mas costoso ir cambiando la textura a dibujar que acceder a una sola textura y dibujar una seccion de ella. dx_lib32 de hecho optimiza esta tarea al trabajar con tilesets ya que detecta si la textura a dibujar es la msima aun siendo disttinto los parametros de dibujo, por lo cual evita el cambio de textura y su coste de rendimiento.

No me refería a eso.
Su pongamos que, como en mi caso, necesito usar gran cantidad de texturas de suelos, paredes y sprites  (para usar como animaciones o como decoraciones).
Si uso tilesets, por supuesto que puedo tener varios tilesets que contengan un tipo determinado de gráficos, por ejemplo "tilesteSueloCiudad.png", "tilesetSueloBosque.png", etc...
La cosa es que si en uno de los supuestos mapas sólo tengo que usar tres tipos de tiles que estan dentro de "tilesetSueloCiudad", más otros tres tiles diferentes de "tilesetSueloBosque", pues estoy obligado a cargar en memoria todo el tileset entero, a pesar de que voy a usar solamente un par o tres tiles de cada uno de ellos. Se ve claramente que hay un uso innecesario de memoria RAM. Puede que para un RPG que usa sólo dos o tres tilesets, no signifique mucho, pero los gráficos que yo tengo que usar podrían llegar a los 150 ó 200 Mb entre todos. Si a ello le sumamos los sonidos más la música (son MP3s de unos 25-30 Megas), podríamos alcanzar los 300Mb sin ni siquiera darnos cuenta.

Sin embargo, con un PAK o un directorio y subdirectorios, simplemente cargaremos las imágenes que necesitemos exclusivamente.
Sé que es peor cargar y leer "cada dos por tres", pero tampoco es ese el caso, ya que los gráficos a usar se cargan solamente en memoria cuando se inicia el nivel, por lo tanto de estar usando 150Mb pasaríamos a usar poco más de 20Mb. Además con la potencia actual de los ordenadores apenas serían unos segundos de carga. Otra cosa, y esto es indiscutible, es que tuviera que cargar y "descargar" gráficos de memoria a cada frame.

Por otro lado, con el tileset no hay manera de organizar mediante un nombre descriptivo y un índice cada conjunto de imágenes dentro del propio tileset. Lo único que se puede hacer es saber en qué fila/columna está tal o cual tile y mediante bastantes líneas de código, acceder a dicha "celda" dependiendo de lo que quieras mostrar.

Si lo hay, de hecho mi ultima version del motor trabajaba un formato de archivo que era una tabla de tiles al que asignabas nombres e incluso podias definir secuencias de animacion mediante dichas claves, todo ello a traves de la siguiente herramienta que tuve que hacerme:

<imagen_no_quoteada>

Una lista o diccionario de rectangulos (X, Y, Width, Height) con una clave y el manejo de tilesets veras que es mas sencillo de lo que pensabas ;)

No sería posible para tilesets que no pueden tener un orden o tamaño definidos, por ejemplo, yo tengo tres "animaciones" de monstruos. Cada animación posee "frames" y "states".
Un frame es cada uno de las imágenes que conforman una parte de la animación (como por ejemplo, mover el pié izquierdo cuando camina). Es quizás otra manera de llamar a los tiles.
Un state es cada uno de los tipos de "animación", por ejemplo, el state "atacar", el state "correr", etc...

En teoría, no habría problema si todos los monstruos tuviesen sus tiles del mismo tamaño y en posiciones relativas equivalentes, pero como no es así, resultaría imposible mediante un método "universal" conocer exactamente qué posición y qué dimensiones tiene cada tile de cada monstruo.

Sin embargo, con directorios o PAKs, simplemente hago una llamada a un método que carge la imagen cuyo archivo se llama, por ejemplo, "zombieWalk01.png", y así con todos los frames de "zombieWalk".

Otro problema que veo: los tilesets que puedo usar y que representan suelos y paredes NO están ordenados, por lo que podría ser horrible tener que averiguar en cada momento dónde está tal o cual tipo de "suelo" o "pared".

No entiendo. Un tileset solo es una textura que contiene tiles, no informacion sobre si es suelo o una animacion o si es fisico o no. Tienes que separar graficos de logica, que un tile sea o no suelo no lo define el grafico si no la programacion que tenga detras tu elemento en pantalla que dibuje el tile.

No me has entendido. Se supone que si usas tilesets, a cada uno de ellos les pondrás un nombre descriptivo. Ya sé que son imágenes xD

Además, en cuanto al consumo de memoria, es destacablemente inferior al de los tileset, ya que solamente hay que cargar en memoria la/s imagen/es que necesitemos usar, que, en mi caso, son de 32x32.

Es mas organizacion que optimizacion en cuanto a programacion. Yo uso tilesets y no los cargo todos. Yo agrupo los tiles de un conjunto de estilos por texturas, si tengo un escenario que va a ser jungla solo cargo el set de tiles que tienen los graficos de jungla, si tengo un escenario que es un hangar solo cargo el set de tiles que tiene los graficos del hangar. Con los personajes igual, solo tengo un set de tiles por personaje, por ejemplo:

<imagen_que_no_voy_a_quotear>

Pues más organizado que un directorio y subdirectorios no encuentro yo otra manera, y mças aún si dentro de "suelosBosque" puede haber varios tipos diferentes, como por ejemplo "hierba", "árboles", "agua", "tierra" y dentro de cada uno de ellos más clasificaciones todavía.

Mi personaje es procedural. No esta formado directamente por frames completos si no por "piezas" (fijate en mi avatar) ya que asi doto de multiples acciones que con pocos sprites puedo programarlas, por ejemplo, que apunte en un angulo segun la posicion del raton, y que de esta forma me permite juntar acciones con otras, por ejemplo, usar cualquier arma con la animacion de carrera y con el casco que quiera. Esta organizacion junto a una programacion generica me permite usar multiples configuraciones para mostrar por ejemplo distintos tipos de soldados en pantalla usando un unico tilset. Aqui solo estoy usando una  unica textura que a la vez pueden usar distintas instancias del marine que no han de ser el player por ejemplo, podrian ser npc's o enemigos inclusive. En este caso la tarjeta grafica solo estaria accediendo a una unica textura todo el tiempo para representar todos los marines en pantalla que quiera poner en mi juego y no a distintas texturas por fotograma de animacion por cada instancia del marine (1 textura = 1 acceso = multiples marines, varias texturas = multiples accesos x (n) marines). El escenario seria otro buen ejemplo, una o dos texturas con los sets que uses en el escenario, 1 solo acceso por textura al dibujar todos los tiles que lo forman.

Pero es que el problema de eficiencia aparece cuando tienes que usar tiles de diferentes tilesets: no sólo se desperdicia RAM si no que también tienes que realizar varios accesos a disco, uno por cada tileset cargado.

La cuestión es: ¿qué ventaja, si es que hay alguna, tienen los tilesets frente al uso de PAKs y/o directorios?

A modo resumen, principalmente el rendimiento y optimizacion de memoria a parte de las posibilidades que ofrece el trabajar con tilesets (el ejemplo del marine). Piensa que los tilesets se llevan usando desde el principio de los desarrollos de juegoos con sprites en maquinas tan limitadas como los Spectrum, las Atari, las NES, Commodore64 y cualquier maquina que tuviera que trabajar con gran cantidad de graficos bitmap en tiempo real, algunas de esas maquinas apenas no tenian potencia suficiente como para andar cambiando de tilesets en tiempo de juego como la NES, que solo usa un mapa completo de tiles para representar los juegos (en cualquier emulador puedes ver esto mediante los exploradores de tiles que tienen):

<imagen_no_quoteada>

Cierto es, tambien, que si tu juego va a ser pequeño y no va a usar una cantidad ingente de graficos pues separar cada tile en una textura suelta tampoco va a ser un problema serio, pero vamos, un RPG o un Shooter desde luego no son el tipo de juegos que usen pocos graficos :)

Ese es el problema: que la clasificación de gráficos con tilesets no la veo tan óptima como con PAKs/Dirs.
Además, usando tilesets, tu programa tiene una modabilidad (no sé si en español sería algo así como "capacidad de ser modificados los gráficos y demás") limitada, ya que el motor de tu juego sólo podrá trabajar con tilesets que usen una distribución idéntica a la original, para la cual ha sido pensada. Alguien que quiera usar un tileset diferente no podrá.

Ah, y claro, estamos hablando de un juego 2D tipo plataforma, o RPG o shooter, es decir, cosas relativamente sencillas y que necesitan usar multitud de imágenes diferentes si tener que usar ese mismo número de variables.

Un RPG o un shooter no son precisamente juego sencillos, ni si quiera un plataformas. Que sea 2D no implica que sea mas sencillo que un juego 3D en cuanto a programacion (no siempre). Recuerda que yo llevo años tratando de sacar un juego tipo Prince of Persia (1989) / Another World (1991) / FlashBack (1992) y estos tienen mucha complejidad detras los graficos que muestran y sobre todo contando para las maquinas para las que se desarrollaron por entonces :)

Salu2...

Me refiero a comparar juegos de ese tipo con juegos con IA más compleja y un desarrollo gráfico más avanzado.

Un saludo y gracias por tu opinión. :-)

P.D. Hechelion, perdona, pero no tengo tiempo de responderte en este momento. Editaré el mensaje en cuanto pueda para poder responder.

En el timer puedo controlar cuando se clica pero no "donde" se clica... dentro del boton tengo la zona de impacto...  se podria llegar a hacer lo que dices calculando la zona de impacto en el mismo timer pero tengo muchos "botones"...

Gracias por tu sugerencia de todos modos

Ah vale, ya entiendo lo que quieres hacer...

También puedes intentar lo siguiente, que a narices tiene que funcionar, y es muy sencillo.

Primero necesitarás que los objetos botón que has creado pertenezcan a una matriz de objetos, como seguramente ya habrás hecho. De esta manera todos los ellos tienen un índice único y puedes acceder a sus propiedades y métodos fácilmente.

En segundo lugar, en el Timer pones lo que es el control de clicks, para saber si el usuario a presionado click derecho o izquierdo.
Cuando alguno de estos botones sea pulsado, llamas a otro método que con un bucle (for...next es lo que necesitas) compruebe si el puntero está encima de alguno de los botones. En caso afirmativo, ya tendrás exactamente qué botón se ha pulsado, y en consecuencia podrás llamar a la función o sub que necesites.

El procedimiento para comprobar si el ratón está encima de algún botón podría ser algo así (pseudocódigo más o menos)

Código [Seleccionar] Expand


for i = 0 to maxButtons - 1
    if (ratonX > boton(i).left AND ratonX < boton(i).left + boton(i).width) AND _
       (ratonY > boton(i).top AND ratonY < boton(i).Y + boton(i).height) then
        'es decir, si la coordenada X del ratón está entre los límites horizontales del botón, y
        'la coordenada Y entre los límites verticales, entonces el ratón está sobre el botón número "i"
       
        MsgBox "¡¡¡He pulsado sobre el botón con índice igual a " & str(i) & "!!!"
    endif
next

No sé si eso te podría servir.

No sé si he entendido bién lo que quieres hacer, pero ¿por qué no pones en los botones un método al cual se accede a través de la detección del click dentro del timer?

Ejemplo:

Dentro de tu clase botón:

Código [Seleccionar] Expand

Public Sub myMetodo()
    MsgBox "Hola Mundo"
end Sub


y en el timer llamas a dicho método cuando se haga clic.

No sé si es eso lo que quieres llegar a conseguir.

Aún sigo trasteando con dx_lib32 antes de ponerme en serio a hacer algo que tengo planeado.

Ahora le ha tocado el turno al manejo de imágenes.
Como nunca antes había manejado tilesets, pues me puse a ello para ver qué ventajas y desventajas tenía.
Pues bién, tras haber probado con un programilla sencillo (simplemente abrir un tileset y mostrar uno de los tiles de 16x16), me he dado cuenta de que usar un PAK o simplemente un directorio con cada imagen, desde mi punto de vista, me parece mucho más útil.

Para empezar, el tileset parece ser menos eficiente en cuanto a memoria usada. Hay que darse cuenta que para usarlo hay que cargar toda la imagen entera en memoria. Para imágenes pequeñas no es un problema, pero cuando hay que usar muchas imágenes y de tamaño considerable, el consumo de memoria puede ser elevado (en mi proyecto tengo que usar más de 20 tilesets y cada uno de 512x512)

Por otro lado, con el tileset no hay manera de organizar mediante un nombre descriptivo y un índice cada conjunto de imágenes dentro del propio tileset. Lo único que se puede hacer es saber en qué fila/columna está tal o cual tile y mediante bastantes líneas de código, acceder a dicha "celda" dependiendo de lo que quieras mostrar.

Otro problema que veo: los tilesets que puedo usar y que representan suelos y paredes NO están ordenados, por lo que podría ser horrible tener que averiguar en cada momento dónde está tal o cual tipo de "suelo" o "pared".




Sin embargo, si nos fijamos en un PAK o un directorio, podremos tener varios subdirectorios cada uno con un tipo de imagen, y cada imagen con un nombre descriptivo y un índice, como por ejemplo "player1.png", "player2.png", "player3.png", o incluso "sueloMetal1.png", "sueloMetal2.png", etc...

Por lo tanto el acceso a una imagen en concreto es realmente fácil.

Además, en cuanto al consumo de memoria, es destacablemente inferior al de los tileset, ya que solamente hay que cargar en memoria la/s imagen/es que necesitemos usar, que, en mi caso, son de 32x32.



La cuestión es: ¿qué ventaja, si es que hay alguna, tienen los tilesets frente al uso de PAKs y/o directorios?


Ah, y claro, estamos hablando de un juego 2D tipo plataforma, o RPG o shooter, es decir, cosas relativamente sencillas y que necesitan usar multitud de imágenes diferentes si tener que usar ese mismo número de variables.

No es un bug, es un error en la documentacion del que ya hable hace nada en este post del compañero de las 3D :)

http://www.stratos-ad.com/forums/index.php?topic=14008.msg146121#msg146121

Ahi viene descrito el orden correcto de los vertices de como los interpreta la funcion.

Salu2...

EDIT: aunque la correcion se refiere a la funcion DRAW_Trapezoid el funcionamiento es identico para VertexMap.

Sí, aunque al final lo descubrí por mi mismo y no creas que no me rompí la cabeza al principio para averiguar qué pasaba :P

Creo que es ese el nombre de la función.
Se trata de la función que dibuja una textura dadas las coordenadas de sus cuatro ángulos.

Según pone en la documentación, los vértices vienen definidos por una matriz de clase "Vertex" con una dimensión que va desde el índice 0 hasta el 3 (es decir, cuatro elementos).

Además también pone que los vértices leen en el sentido de las agujas de reloj, como en el siguiente esquema:

Código [Seleccionar] Expand

V0 ---- V1
|        |
|        |
V3 ---- V2


Hasta aquí todo correcto, pero a la hora de probarlo, me he encontrado con que la textura renderizada usando este método y siguiendo las instrucciones, no se mostraba como se supone que tenía que hacerlo.

Trasteando con ella, he encontrado algo que parece un pequeño bug con las coordenadas de dicha función.

Si las coordenadas de los vértices se leen en otro orden diferente, todo funciona 100%, concretamente así:
(leidas en el sentido de las agujas de reloj)

Código [Seleccionar] Expand

V0 ---- V1
|        |
|        |
V2 ---- V3

Ahora bién, esto parece un poco extraño ya que ese orden no parece nada lógico.
Sin embargo, y si mi intuición no me falla, quizás la sea un problema de orientación de las coordenadas.
No he tenido tiempo de probarlo, pero creo que los vértices tendrían que ser leídos en SENTIDO CONTRARIO al de las agujas de reloj, y de la siguiente manera:

Código [Seleccionar] Expand

V1 ---- V0
|        |
|        |
V2 ---- V3

Como ya he dicho, no he probado esto todavía, pero creo que en realidad es así.
Lo testearé y mañana os comento...

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

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.

Hola.

Antes de nada, presentarme, ya que soy nuevo por este foro.
Me ha bajado la librería hace unos días, y aunque no he hecho nada importante, creo que puede cumplir mis expectativas, aunque a primera mano, tras trastear un poco y leer la ayuda muy por encima.

Bueno, básicamente me registré en el foro por que al leer este mensaje y sus respuestas me acordé de un par de cosillas que había estado mmirando hace ya bastante tiempo.
Se trata de realizar una escena 3D mediante gráficos 2D usando diferentes técnicas.

Estas técnicas son conocidas por juegos que las usaron por primera vez, como por ejemplo Dungeon Master, Chaos Strikes Back, idTech Engine 1 (Doom/Hexen/Heretic/...)

Son básicamente el Raycasting, Raytracing y el 3DStatic Drawing (creo que se llamaba así).

Tengan en cuenta que por aquellos años, sobretodo los anteriores al Win95, no había DirectX y mucho menos OpenGL, así que se inventaron técnicas para simular susodichas escenas que parecían 3D.
Hoy en día les llaman a eso 2.5D, en vez de 3D, ya que no es realmente 3D.

Pueden buscar por internet, que seguro que encuentran gran cantidad de manuales para implementarlos, sobretodo del Raycasting.

Ahora bien, olvídense del Raycasting y Raytracing si dx_lib32 o el código que tengan pensado desarroyar no estén bién optimizados en cuanto a funciones de perspectiva y escalado se refiere.

Un saludo y espero que les sea de utilidad.