Acabo de colgar la libreria 2d en la que he estado trabajando desde hace bastante tiempo. Algunos de vosotros ya la conoceis, o al menos habeis visto los ejemplos.
Looverlib es una libreria 2d open source implementada bajo c++ y Direct3d por lo que utiliza aceleración por hardware para el render. No usa DirectDraw ni ID3DXSprite, sino Direct3d 9.0 montando todas las imágenes sobre texturas de una manera completamente transparente para el usuario, aprovechando de esta manera la aceleración por hardware al 100% y permitiendo sprites de tamaños increibles incluso con alpha blending activado.
LooverLib no es muy extensa, cualquier proyecto que la use utilizará apenas unas 7 clases, pero es muy potente, tremendamente intuitiva, está completamente documentada y... posiblementes esto sea lo mejor, es Open Source bajo licencia LGPL.
Con esas 7 clases tendrás una solución completa a todo lo que un juego 2d puede pedir gráficamente. Formatos de imágenes, mapas de bits, mapas de durezas, filtros tipo photoshop, animaciones por script, superficies de cualquier tamaño, scrolls cortados en el tamaño de bloque que tu desees realizando descarte autómatico incluso cuando están rotados o escalados, fuentes de texto con herramienta para crearlas incluída (MudgeFont), entintados, fades, transparencias, alpha blending, color key, primitivas gráficas, posibilidad del uso de entidades y un largo etc.
A ver si podeis visitar la web, bajaros el código, consultar la documentación, ver los ejemplos, etc, etc, etc :)
¡Un saludo!
Web de LooverLib(http://www.pixelartgames.com/looverlib/Documentacion/html/surfa2.jpg)
Enhorabuena por el proyecto Loover, muy completo y tiene pinta de ser muy sencillo de usar, genial :)
Salu2...
Saludos Loover,
Ya sabes que yo soy grafo xD , pero he estado pegandole una ojeada a los ejemplos y se ve muy bien, por lo que veo se pueden hacer todo tipo de efectos graficos , mola, solo decirte... que enhorabuena por el trabajo, creo que has hecho una gran labor y seguro que esto ayuda a los que quieran hacer un juego 2d, ^_^' , si algun dia me decido por aprender a programar de forma seria... ten por seguro que usare tu libreria xD, solo desearte mucha suerte y ... espero que mucha gente le saque partido a la looverlibreria xD
Te lo has currado mazo :)
Estoy convencido de que mas de uno, le sera muy util :)
enhorabuena! (ole)
¡Gracias de veras por vuestras críticas tan positivas!
Venga! A ver quien se moja y hace un ejemplillo o algo.
¿Se ofrece alguien para hacer un logo :P ?
Solo he echado un ligero vistazo a los ejemplo y tiene muuuuuy buena pinta.
La única pega que le veo es el uso de DLLs. Para un ejemplo simplón tienes que sar varias DLLs que engordan mucho el programa.
Qué quieres, las tengo manía :P
Gracias de nuevo.
CitarLa única pega que le veo es el uso de DLLs. Para un ejemplo simplón tienes que sar varias DLLs que engordan mucho el programa.
Y si no uso DLL donde meto el código? En un bocata de jamón? :) (ñam)
Si prefieres engodar el .exe siempre puedes usar la .lib y linkarla estáticamente. Tienes el código fuente completo para compilar como libreria dinámica, estática o como te plazca. Eso sí, si modificas el código de la librería, ya sabes, hay que publicarlo, es LGPL. Lo que no implica que tengas que publicar el código del juego, pero eso ya lo sabrás.
Solo he usado una libreria, la LooverLib para lo que es la librería en sí. Y la ilu.dll y devil.dll que son para el manejo de imágenes. No me parece mucho, la verdad.
Si incluyo en cada ejemplo las dll es para que la gente no se moleste en tener que bajar los binarios y pegarlos al lado del .exe cada vez :) 2 megas y pico que ocupa el ejemplo más grande no es demasiado para los tiempos que corren.
Cita de: "Loover"Y si no uso DLL donde meto el código? En un bocata de jamón? :)
¿En una librería estática?
El resto (que no son tuyas) puedes dejarlas cono DLL, pero ya que la tuya dices que es ligera (son unas pocas clases, ¿no?), ¿por qué no dejarla en una librería estática?
Entiendo que si una librería ocupa un güebo de megas y que todas sus partes son "necesarias", se deje como DLL para compartirla entre aplicaciones (aunque no estoy del todo de acuerdo), pero si es una librería ligerita, ¿para qué una DLL? O sea... ¿por que "imponer" una DLL?
Bueno, soy totalmente anti DLLs, los que están a favor podéis ignorarme xD
Volviendo al tema, es tu librería y la distribuyes como mejor te parezca. Sigue siendo un buen trabajo.
Creo que edité mientras contestabas Sés porque he dicho justo lo mismo que tú al final, xD
No impongo nada, lo doy todo y la gente que lo use como quiera. El que quiera usarla estáticamente, adelante, solo tiene que recompilarla como librería estática.
Por cierto, usando
UPX, la libreria pasa de 500k a unos ciento y pico.
;)
Bueno, ¿que os ha parecido la documentación? ¿Se entiende todo? Y el código de los ejemplos, ¿tambien se entiende?
Ese tipo de cosas son las que más me interesan. Bueno, y que alguien se ofreza a hacer un loguito, snif.
He bajado los ejemplos de scroll y animación. Le he echado un vistazo al código y la verdad es que me parece realmente bueno. Recuerdo la librería que hice yo en 2D y calculo que estaría a un 40% de la que tu has hecho. Has resuelto el problema de las animaciones y de los bloques, aunque no entiendo cómo lo haces realmente porque si cargas todo el fondo de un bitmap enorme, pierdes en realidad la ventaja más importante de los bloques que es el ahorro de memoria.
Enhorabuena (ole)
Gracias Hadd!
CitarLe he echado un vistazo al código y la verdad es que me parece realmente bueno. Recuerdo la librería que hice yo en 2D y calculo que estaría a un 40% de la que tu has hecho
Bueno, eso es porque tu te has centrado en el 3d, ¡y con que resultados! ;)
Citaraunque no entiendo cómo lo haces realmente porque si cargas todo el fondo de un bitmap enorme
Bueno, te pegaría un tirón de orejas y te díria que te toca leer la documentación pero mejor lo explico rápido. Para cargar un fondo, tienes dos opciones. O lo montas como una imagen en un objeto LOV_Image, con lo que podrías usarlo por ejemplo como mapa de durezas, como base para aplicar máscaras o historias (como en el ejemplo del generador de mapas tipo worms). En este caso es simplemente un array de bytes, vamos, un mapa de bits. Nada de bloques.
Otra opción, la que tienes que usar si quieres dibujarlo en pantalla. Es pasarlo de un objeto LOV_Image a un objeto LOV_Surface (lo que puedes hacer automáticamente) o bien cargarlo directamente desde el fichero gráfico como LOV_Surface. En este caso (ver métodos Add de LOV_SurfaceManager) puedes dejar que LooverLib lo corte en bloques "texturas" del tamaño máximo que pueda, esto dependerá del tamaño máximo permitido por tu tarjeta y de la forma que el recorte sea más óptimo. O bien puedes indicar que lo corte en bloques de un ancho y un alto dado (esto es bueno para scrolls). Y es más, activando el parámetro mBlockCull, puedes indicar que los bloques que queden fuera del vierPort, no se dibujen. Y todo esto de forma transparente, permitiendo al usuario cargar imágenes no portencia de dos tan grandes como quiera (como esos fondos gigantescos de la cueva) y haciéndolo todo automáticamente.
Es decir, el uso de bloques internameten de manera transparente para el usuario resuelve varias cosas de un plumazo:
- Posibilidad de cargar imágenes no potencia de 2
- Posibilidad de hacer scrolls fácilmente
- Simplicidad increible al implementar la clase de fuentes (al estar en un bitmap, basta con dividirlo en bloques, y ya pasa a ser otra LOV_Surface más)
Pero claro, esto es util para scrolls no tileables, como el fondo de la cueva.
Aunque lo mismo no te referias a esto y te referias como bloques a "tiles" de un editor de mapas tipo mario. Bueno, eso ya depende del editor en cuestión, por supuesto que usando mapas de tiles se ahorrará memoria. En un futuro, me gustaría dar la posibilidad de usar un editor de tiles de los que circulan por ahí y que LooverLib lea esos mapas y los dibuje, pero esto realmente, no es nada complicado. Basta con cargar esos tiles como LOV_Surface y dibujarlos según indique el mapa. Nada que no pueda hacer cualquiera de vosotros. No sé si meterle más cosas, o dejarla ya así, por no complicar más la libreria.
Un saludo!
Para los que hayan probado el ejemplo de Imágenes y nos le haya funcionado, lo siento. Se me había olvidado poner una imagen ("tierra2.png") en el zip.
Mira que no me lo habeis dicho ninguno de stratos sino un colega! xD
Enhorabuena
Por lo que he visto me parecen muy guapas las librerías. Muy currado el trabajo.
Segun dices son opensource. No se si has pensado portar las librerías a linux. Tampoco se si es posible hacerlo usando OpenGL. Lo digo desde la mas completa ignorancia. No se si es posible hacerlo con lo que tienes.
Muy buen trabajo, y 1 saludo
Todo es posible.
A largo plazo sería algo que me gustaría mucho. Separar el render en un plugin y portarlo a opengl. Y dar la posibilidad de usar D3d u ogl. Y de esta manera portarla a linux e incluso a mac.
Ahora no me veo con fuerzas, pero, es opensource. Cualquiera que se animara a ayudarme con este proyecto sería bienvenido.
¿y qué hay de las colisiones? Te recuerdo que yo tengo una rutina de colisión perfecta al pixel. ¿Cómo lo resuelves? Si quieres más datos, ya pue un post hace mucho tiempo, pero bueno, puedo recordarte el sistema.
Las colisiones que tenía implementadas al final las quité. Por que me di cuenta que más que la colisión en sí, lo importante es todo el sistema físico que las acompaña. Es decir, detectar si hay colisión o no, sirve más bien para poco. Hay que detectar también el vector resultante, el area de colisión, etc, etc, para que junto con el sistema de física las partículas que lo conforman tengan respuestas correctas.
Así que, como yo considero que las colisiones deben estar dentro, o formar parte, de lo que es un sistema de física, y LooverLib se centra en el apartado gráfico, decidí quitarlas.
Cualquiera puede usar la libreria física que quiera, como ODE, junto con LooverLib.
Es decir, LooverLib es gráficos 2d. No es una solución completa para juegos, ni para física. Nada de eventos, nada de música.
Pero eso sí, en cuanto al sistema gráfico es muy potente. LooverLib debe ser usada para lo que está concebida: resolver totalmente el apartado gráfico 2d de una aplicación multimedia o juego.
Ya, pero no me negarás que para un juego 2D las colisiones por lo menos de cajas deberían estar implementadas. Por que no se va nadie a descargar ODE para utilizar un sistema de colisiones para un juego 2D. Tienes razón en lo que dices, de que un sistema puede ser muy complejo, pero lo básico, básico, debería implementarlo. Es una opinión, claro :D
En mi concepción de un juego 2d con física, ojo, en la mía, la parte de colisiones debe estar implementada como una clase más por encima de las clases de respuesta de colisión. Si yo pongo colisiones en esta libreria, cualquiera que use un motor de físicas luego ni se las mirará, porque ya las tendrá. De todos modos, el próximo juego que voy a hacer, va a utilizar física, siempre podría hacer una LooverLibPhysic.
Aún así, si alguien quiere las clases que implementé de colisiones, por regiones, cajas, etc, siempre puede pedírmelas. Pero de poco le servirán en un juego de física robusta, porque solo detectan colisión en sí, nada de respuestas del vector resultante, etc.
Pero mi decisión de diseño en ese aspecto esta tomada, LooverLib solo da soporte gráfico 2d.
Felicitaciones.
(ole)
Cita de: "Haddd"¿y qué hay de las colisiones? Te recuerdo que yo tengo una rutina de colisión perfecta al pixel. ¿Cómo lo resuelves? Si quieres más datos, ya pue un post hace mucho tiempo, pero bueno, puedo recordarte el sistema.
Haddd, stoy mazo vago jeje, donde se puede ver eso de el sistema de colisiones q disenaste? a mi me interesa para incluir con la lib.
PD: sorry por el enie...alguien sabe como leches la puedo poner en un teclado ingles??? jeje
Puede que no este mal pero faltan cosas que seria de mucha utilidad.
Los cuadros de animacion no sulen estar en ficheros separados si no todos en una misma imagen, quiza deberias adaptar el script que tienes para que coja una imagen y te coja los frames de animacion del objeto segun las cordenadas que le fijes.
Las colisiones me parecen fundamentales, si bala toca avion - avion explota, no hay fisica por ningun lado. Lo mejor seria a base de usar rectangulos para cada objeto, si puedes hacer zoom's la colision al pixel puede ser muy compleja y seria mejor dejarla para el final si pica. La colision de las primitivas graficas si que seria interesante hacerla mas compleja, mas o menos como ya has comentado, aun que sea solo para poder hacer rebotar los objetos segun interese.
Y finalmente, algo que simplemente no puedes dejar de lado, los mapas a base de tiles son imprescindibles!
Saludos.
Usando Querys de oclusión.:
1. ZBuffer=true, ZWrite=false, ZFunc=LessEqual. Valor de TODOS los sprites de Z=0
1. Haces una primera pasada de forma que dibujas todos los sprites. Lees la Query de cada sprite. Eso te dice el nº de pixels que se dibuja de cada sprite. Y ya los tienes dibujados.
2. Limpias el ZBuffer.
3. ZBuffer=true, ZWrite=true, ZFunc=LessEqual
4. Renderizas el del protagonista (Z=0) (o el que quieres comprobar si colisiona).
5. Renderizas los que pueden colisionar(Z=0.1). Lees la Query de cada uno. Como se dibujan detrás del primero, si hubiera alguna colisión, la Z fallaría en algún punto, y por tanto el nº de pixels dibujados ahora sería menor que el que hemos guardado en el paso 1.
Bueno, eso tiene un montón de optimizaciones. Pero es pixel perfect (ole) La grandísima ventaja es que si rotas el sprite, también funciona, cosa que los otros sistemas no lo permiten.
Bueno, si usais esta técnica, por favor, decid que ha sido idea mía en los créditos ;)
Ya sabeis, a compartir información!!! (uoh)
CitarLos cuadros de animacion no sulen estar en ficheros separados si no todos en una misma imagen, quiza deberias adaptar el script que tienes para que coja una imagen y te coja los frames de animacion del objeto segun las cordenadas que le fijes.
Fácil, lo haré. ¿Puedes mandarme al correo algún ejemplo y que datos necesitaría? Y si es posible una config que describa como cargarlo para saber exactamente a que te refieres.
CitarLas colisiones me parecen fundamentales, si bala toca avion - avion explota, no hay fisica por ningun lado. Lo mejor seria a base de usar rectangulos para cada objeto, si puedes hacer zoom's la colision al pixel puede ser muy compleja y seria mejor dejarla para el final si pica. La colision de las primitivas graficas si que seria interesante hacerla mas compleja, mas o menos como ya has comentado, aun que sea solo para poder hacer rebotar los objetos segun interese.
Bala toca avion. Eso es tan facil como hacer un GetWidth y GetHeight de ambas superficies, y junto con la posicion compararlo. Pero bueno, ya que tanto insistis y al final me habeis convencido :D, las incluiré de nuevo. El caso es que las tengo hasta documentadas pero las quité en el último momento. Tengo implementadas colisiones por aristas, por área, por círculo y por rectángulo. Se las volveré a meter. Pero desde luego, nada de vectores resultantes ni historias, eso irá en la libreria de física. La colisión por pixel, vendrá más adelante también, ya que estamos. Gracias Hadd, recordaba tu post :)
CitarY finalmente, algo que simplemente no puedes dejar de lado, los mapas a base de tiles son imprescindibles!
Tan facil como cargar cada tile en un LOV_Surface y dibujarlos en el orden del mapa. Me estoy decidiendo por un editor de tiles open source. Ya le eché el ojo a uno, cuestión de tiempo.
Gracias por las recomendaciones!
Cita de: "_Grey"Los cuadros de animacion no sulen estar en ficheros separados si no todos en una misma imagen, quiza deberias adaptar el script que tienes para que coja una imagen y te coja los frames de animacion del objeto segun las cordenadas que le fijes.
No sé a qué juegos te refieres, pero ya me dirás como manejas una imagen que contenga los 1000 fotogramas de un sprite... aunque con unos 50 ya te saldría una imagen "grandecita".
Lo mejor es un fichero con un formato propio con todas las imágenes, aunque lo más portable es algo como lo que ha hecho.
Publiqué dos mensajes por error, borro este.
Sés refiriéndose a _Grey:
CitarNo sé a qué juegos te refieres, pero ya me dirás como manejas una imagen que contenga los 1000 fotogramas de un sprite... aunque con unos 50 ya te saldría una imagen "grandecita".
Lo mejor es un fichero con un formato propio con todas las imágenes, aunque lo más portable es algo como lo que ha hecho.
Ese es el problema, que ese tipo de cosas son a gusto del usuario. Creo que lo mejor es usar unos formatos propios, los más portables posibles, y el que quiera usar la libreria tenga que amoldarse a ellos. Siempre puedes recortar los sprites después de todo. Porque sino, por la misma regla de tres, tendría que hacer cargadores tiles de todos los formatos de mapas que haya.
Algo que nadie ha comentado aún es ya que se utiliza aceleración por hardware, ¿porqué no implementar un sistema de partículas? Y es porque no sé si esperarme a tener montada la libreria de física, y a partir de ella montar el sistema de partículas. Aunque creo que finalmente lo haré directamente en LooverLib.
Tengo que hacer una lista de cosas por hacer para la próxima versión.
Lo de Sés me descoloca un poco, igual no me explique del todo bien.
Lo que quiero decir es que cuando se trabaja en un juego 2D lo normal es usar una imagen con todos los cuadros de animacion del personaje tal como esto:
(http://perso.wanadoo.es/e/enigsoft/TECH.gif)
Dejando a un lado de si es de calidad o no ....... (era joven e impetuoso ... :rolleyes: :rolleyes: :rolleyes: )
En lugar de usar imagenes en ficheros independientes, como veo que hace Loover.
Quiza abria que cambiar el script que se usa para cargar la animacion, por ejemplo, basandome en el fichero de animacion de tu ejemplo Animacion, para la nave azul que se ve en el dibujo podria ser algo asi:
// Aquí definimos los frames
.FRAMES
{
// Avion 1 : nombre imagen - coordenadas (x,y)-(x1,y1) de ese frame concreto de la animacion
.PATH animaciones\advance
.NAME Avion1 .FILE tech.pcx 0 0 26 22
.NAME Avion2 .FILE tech.pcx 27 0 53 22
.NAME Avion3 .FILE tech.pcx 54 0 80 22
.NAME Avion4 .FILE tech.pcx 81 0 107 22
.NAME Avion5 .FILE tech.pcx 108 0 134 22
.NAME Avion6 .FILE tech.pcx 135 0 162 22
.NAME Avion7 .FILE tech.pcx 162 0 189 22
.NAME Avion8 .FILE tech.pcx 189 0 216 22
.NAME Avion9 .FILE tech.pcx 216 0 242 22
}
// Aquí definimos las secuencias
.SEQUENCES
{
// Si no se especifica .TIME por defecto será 150ms
.NAME RockAvanzando
.FRAME Avion1
.FRAME Avion2
.FRAME Avion3
.FRAME Avion4
.FRAME Avion5
.FRAME Avion6
.FRAME Avion7
.FRAME Avion8
.FRAME Avion9
}
Los numeros que se ven, no son mas que las coordenadas x,y del recuadro que enmarca la imagen de animacion de ese sprite, dentro de la imagen mayor. Quiza seria mas comodo indicar el fichero grafico una sola vez indicandole un nombre y luego referenciarlo con el nombre que se le a dado.
Quiza sea mejor usar un formato propio como comentais. En fin solo proponia algo asi, por que no es muy usual un fichero grafico completo para cada cuadro de animacion, si no embutirlo en un fichero para la ocasion, formato propio, o simplemete usando una imagen normal como esta para luego sacar los cuadros de animacion.
Seguramente ahora se vera claro.
Saludos.
PD: Quiza alguien vio este mensaje con un [EDITANDO], se me escapo el enviar, espero que no fuese molesto.
Lo que si es seguro que tengo que hacer, y que va a ser lo más inmediato junto con colocar de nuevo las colisiones, son unos métodos Add para los manager que carguen los recursos desde memoria. Para de este modo poder cargar los gráficos, scripts, etc desde por ejemplo un .pak o fichero contenedor.
Eso si que es algo imprescindible.
Citarcuando se trabaja en un juego 2D lo normal es usar una imagen con todos los cuadros de animacion del personaje
Ummmmm yo nunca lo he hecho no debo ser normal xDD , siempre depende el juego y tal, para mi es bastante mas comodo fotogramas independientes que hacer una imagen enorme ^_^' , supongo que eso sera a gustos, la unica vez que he hecho eso que comentas fue para un juego de moviles ... pero claro, ahi el espacio está muy limitado y es util ya que los graficos son superpequeños, pero no me veo metiendo los 220 frames de animación de 240x350 pixels en un megagrafico enorme , alomejor hablo sin conocimientos (por que no soy programador), pero creo que no seria demasiado comodo :-S, no se, la verdad es que cada uno hace las cosas de formas diferentes y debe ser dificil tener a todos contentos. Animo loover campeon! xD, las colisiones aunque sean las basicas si que las veo necesarias (por si algún dia aprendo a programar y quiero usar tu libreria xD ) ;-)
Hombre zwitter hay que ser muy bruto para meter tanto frame un archivo solo. Sin embargo, si puedes dividirlo, por ejemplo, andando-derecha. El motivo de usar este metodo supongo que ya lo conocerás. Más archivos pequeños = más espacio en disco duro y para colmo tarda "bastante" más en encontrarlo (algo muy relativo ya que hablamos de milisegundos o hasta menos) . Aunque no lo parezca, tarda menos en coger los bits que nesesitas de una imagen grande :) .
Loover, estaba pensando en usar tu librería para la versión Windows de mi engine, ya que hay más usuarios con buenos drivers para DX7 que para OGL, pero leyendo el thread me he dado cuenta de que usas DX9 !! ¿cuál es tu excusa para usar DX9 en vez de 7?, porque no creo que sea por el HLSL XD
:P
Si te comprometes a usarla te la paso a D3D7.
De todos modos, la razón de que esté en D3D9 es por si la gente de stratos que tiene motores (siendo la mayoría de estos bajo D3D9) se anima a usarla junto con su parte 3D.
Lo que debo hacer es separar el sistema de render en un plugin. De tal manera que pueda cargar diferentes renders, D3d7, D3d8.1, D3d9, Ogl, ¿Software? Etc
Por cierto, no se recupera cuando sales a windows (Alt+Tab) y regresas a la aplicacion.
Quiza sea una parte de las complejas, pero hasta entonces podrias hacer cosas como tratar las texturas como "D3DPOOL_MANAGED" o "D3DPOOL_SYSTEMMEM" y solo tendras que recuperar el Device y poco mas (hablo de memoria...).
En cualquier caso creo que deberia ser la libreria quien lo haga.
Saludos.
Cierto _Grey, lo del alt tab es un problema que me mosquea. Estuve leyendo el post de EX3 (creo que era) preguntando por eso y tal pero creo que no se encontró una solución en ese hilo.
Alguien sabe como puedo solucionar eso?
El otro dia leyendo un libro.....
Puedes prevenirlo. Puedes desactivar el ALT+TAB y ALT+ESC con el parametro SPI_SETSWITCHTASKDISABLE de la funcion de sistema SystemParametersInfo(), ni siquiera lo he probado, pero la puedes encontrar en la documentacion.
Pero si lo quieres hacer bien es mas complejo, algunos objetos de DirectX lo requeriran otros no, y algunos puedes "adaptarlos" para que no sea necesario, como lo dicho para las texturas en el anterioro msg.
Tengo que reconocer que mi "parche" para solucionar esto a dado algun problemilla, pero es mas bien por dejarlo para el final y no hacerlo para todos... pero mas o menos es algo asi:
Lo que has de hacer es liberar los objetos que lo necesitan (A golpe de Release(), es como lo hago) y luego lo creas de nuevo, cargando los ficheros otra vez, como al inicio.
Puede combertirse en algo complejo adaptar el codigo ya creado, de todas formas como no usas vertexbuffers (Las quitaste al final, nop?) Puedes crear las texturas para que no necesiten ser "recargadas", el dispositivo lo liberas y lo creas otra vez. Basicamente es eso, en la documentacion encontraras mas info, el trabajo de verdad es adaptar las estructuras u objetos para que sepan que recurso han de cargar otra vez.
Si acaso para empezar has lo minimo dejando las texturas como "D3DPOOL_MANAGED" o "D3DPOOL_SYSTEMMEM" igual es suficiente, pero quiza el rendimiento baja con ese tipo de texturas, es cuestion de hacerlo.
Por cierto eso de HLSL...... sinceramente pensaba que usabas Dx9 para poder usar pixel shaders y hacer efectos vistosos. Hace algun tiempo alguien puso el link de un motor 2D que los usaba y quedaba muy ..... "visual", pero lo mejor seria poder renderizar la imagen en una textura y despues pasarle el filtro con el pixel shader, aqui las posibilidades serian muy grandes... incluso sin pixel shaders, si los objetos de figuras geometricas de tu motor soportara la posibilidad de texturar los poligonos.Esto ultimo casi me extraña que no este , o por lo menos no lo e visto por ningun lado.
Saludos.
Una versión de mi motor que puse aquí utilizaba pixel shaders para 2D. Quizás te refieras a esa versión. :D
Por cierto, ¿no hay comentario sobre la explicación de las colisiones perpixel que he puesto antes?
Citarincluso sin pixel shaders, si los objetos de figuras geometricas de tu motor soportara la posibilidad de texturar los poligonos
Lo puedo poner como una primitiva más, buena idea.
Pero no, no pienso usar Pixel Shaders. Por lo menos no de momento, ni siquiera a medio plazo. Lo siguiente que voy a hacer es separar el render en un plugin. Luego portarla a D3D8, luego a OGL. Eso así por lo pronto. E ir metiendo a la par algunas funciones simplonas como esas de colisiones que ya tengo, o la de relleno de polígonos en la sección primitivas, objetc picking, etc.
Una vez portada a OGL el siguiente paso sería que funcionara en Linux.
A la misma vez iré añadiendo herramientas. Un editor de tiles, un empaquetador de recursos, etc.
Y todo esto cuando tenga tiempo y no esté con otras cosas. Pero no voy a dejarla abandonada.
No quiero usar Pixel Shaders porque el único ambiente en el que podría tener cierto éxito mi libreria es en el del shareware. Y los requisitos de los ordenadores de los compradores de ese tipo de juegos son muy bajos. Nada de Pixel Shaders.
En serio que me gustaría mucho que la gente se animara a usarla. Me gustaría abrir un foro de la libreria pero no sé que sistema de foros elegir. ¿No podriais hacerme un hueco en la sección proyectos, jiji? Que cara tengo.
POSTDATA:
Hadd en su tiempo ya te dije que el algoritmo para detección de colisión por pixel estaba bastante bien. Faltaría que lo completaras con vectores resultantes, area afectada, etc.
De todos modos, me parece demasiado dependiente del Hardware ese sistema. Oclussion Querys no lo tienen todas las tarjetas. ¿Existe lo mismo en OGL?
Si no te interesan los pixel shaders, y piensas en bajar una version de Direct3D, piensa en la 7. Los posibles usuarios te lo agradeceran si piensas en el shareware, y si añades las texturas a las figuras geometricas y lo combinas con la posibilidad de "renderizar" la imagen a una textura se pueden conseguir efectos mas que buenos sin pixel shaders solo a base de poligonos.
Pero si piensas en Linux casi mejor portarla a OGL, tu veras.
Saludos.
D3d7, D3d8, D3d9, Ogl, software? Los tengo todos en el punto de mira una vez que separe el render en un plugin. Al iniciar la clase render, bastará con escoger uno u otro y punto. Es solo programar bien la base. Lo bueno de que sea una libreria 2d, es que se puede atisbar un "final" en el que quede algo realmente decente. Con el 3d está todo tan abierto y siempre saliendo más y más cosas que da así como apuro ponerse como otro motor 3d más. Pero claro esa es mi opinión, y ni muchos es la realidad de muchos de vosotros. Basta con ver el genial motor Hadd.
Es que no le veo mucha utilidad bajar de la 9 a la 8, pero si lo que te interesa es mantener los requisitos "bajos" y crees que puede ser interesante para produciones share, la 7 es ideal, se van a OGL o a la 8 por que es mas facil, lo cual podria hacer mas interesante la libreria (No te garantizo que nadie la use, segun la promociones).
Pero claro, si piensas en Linux OGL estara entre tu objetivo mas principal. La version de software, simplemente pasaria de ella, es irse a un hard demasiado bajo, quiero decir si quieres poder hacer todo tipo de efectos, transparencias ,rotaciones zooms, y demas.... si necesitas por soft seguramente no habra maquina.
Saludos.