Wenas
Tengo programado un motor 2D a traves de Direct Graphics, este funciona a partir de Sprites y primitivas. Mi problema se presenta cuando la tarjeta grafica la tengo configurada a lo burro: se entiende por ello que el Antialising esta a 4x, Direct3D al maximo y aunque no vaya a cuento con el problema, OpenGL tb al maximo. Esto mejora notablemente el aspecto grafico pero me baja mucho el rendimiento del motor y quisiera saber si existe alguna manera de omitir esa configuracion de la tarjeta como por ejemplo desactivar el Antialising. Mi tarjeta es una GForce3 Titanium 200 64Mb. El motor en modo ventana funciona mas o menos bien dependiendo de la configuracion de la tarjeta y en pantalla completa rara vez me baja de los 60 FPS.
Si por casualidad alguien esta interesado en probar el motor y comprobar por su cuenta el funcionamiento aki teneis los links de descarga:
dx_lib32 version Alpha 1.0 - Librerias de tiempo en ejecucion (Runtimes):
dxlib32_Alpha1.0_24-12-03.exeTest 1 - Prueba de funciones graficas en general:
Test1.zipTest 2 - Simulacion de carta de ajuste:
Test2.zipTest 3 - Prueba de funciones de dibujo de primitivas:
Test3.zipTest 4 - Informacion de hardware:
Test4.zipSalu2...
Menudo gambazo con el título.
Probaría el test, pero como hay un 98% de probabilidades de que no me funcione, me ahorro instalar los runtime y mejor que te diga algo alguien con una tarjeta normal.
A ver si ahorro...
¡Feliz Navidad!
Que problema tienes para ke tengas 98% de posibilidades de ke no te funcione?
Y el "gambazo" con el titulo?
Salu2...
Yo he probado el test1 y no me funciona. No se ve nada, ni me da ningún mensaje.
La instalacion de las runtime te ha dado algun fallo?
Pantallazos de los test en modo ventana y con el antialising desactivado:
(http://usuarios.lycos.es/vhd/dx_lib32/Test1.png)
(http://usuarios.lycos.es/vhd/dx_lib32/Test2.png)
(http://usuarios.lycos.es/vhd/dx_lib32/Test3.png)
(http://usuarios.lycos.es/vhd/dx_lib32/Test4.png)
Si alguien mas no le funciona ke me lo diga, por favor.
Salu2...
Pues porque las cosas tienden a no funcionar en mi ordenador. Sin embargo, lo he probado por curiosidad y enhorabuena, perteneces al selecto 2% de personas que hacen cosas que sí me funcionan.
El gambazo es por la "g" de "targeta" que has metido en el título. Quisquillosidades mías.
Por cierto, si a alguien le interesa:
(http://www.andorstudios.com/marte/esclinchot.jpg)
Un saludo :D
Mars Attack dijo:Citarenhorabuena, perteneces al selecto 2% de personas que hacen cosas que sí me funcionan.
Me alegra saber ke por lo menos te funciona :) , despues del tiempo ke he invertido e invierto todavia e invertire aun en este proyecto, pues es algo ke siempre alegra un poco.
Mars Attack dijo:CitarEl gambazo es por la "g" de "targeta" que has metido en el título. Quisquillosidades mías
Ya me di cuenta al rato de escribir el post, pero como luego no se pueden reeditar, pues... pero vamos, ke yo pensaba que lo decias por el titulo del proyecto o algo asi, siempre tiendo a pensar mal (nooo) (uoh)
Mars Attack dijo:CitarPor cierto, si a alguien le interesa:
Pues a mi me interesa, para ver resultados ajenos a los mios ;)
Salu2...
Cita de: "[EX3"] Me alegra saber ke por lo menos te funciona :)
A mí más, pero después de comparar las especificaciones de tu tarjeta con las de la mía, creo que me voy a llorar un rato al salón.
Bona nit.
(nooo)
Muy buen curre con este motor 2d. He estado mirando el código que adjunta el Test1 y la forma de programarlo se ve sencilla y pontente. ¡Enhorabuena! Además me va muy bien, unos 110 fps de media.
Yo tb estoy programando algo parecido (un motor 2d) y tengo unas dudas acerca de como has implementado todo esto:
1. ¿Utilizas DirectDraw o Direct3d?
2. ¿En caso de que uses Direct3d troceas las imágenes para poder cargarlas de cualquier tamaño?
3. ¿Esas fuentes las haces con el ID3DXFont?
Un saludo y... ¡ Feliz Navidad !
PD: Me piro ya mismo a celebrarlo con una botella de Bombay Sapphire (uoh)
Loover dijo:Citar1. ¿Utilizas DirectDraw o Direct3d?
2. ¿En caso de que uses Direct3d troceas las imágenes para poder cargarlas de cualquier tamaño?
3. ¿Esas fuentes las haces con el ID3DXFont?
Un saludo y... ¡ Feliz Navidad !
1. El motor esta implementado con Direct3D.
2. No troceo las imagenes. Simplemente las cargo y cuando las almaceno guardo su tamaño real junto a la textura y demas datos sobre ella en una estructura, y luego a la hora de dibujarla en pantalla le aplico una escala. Esto es una jodienda si kieres leer algun pixel de la imagen por que no sabras que pixel lees, ya que cuando intentes leer una coordenada exacta leeras otra distinta ya que la imagen se almacena en potencia de dos: ejemplo-> 185x132 seria 256x256.
3. Las fuentes ahora mismo no te puedo decir con exactitud por ke tendria ke mirar el codigo fuente y en estos momentos me encuentro en casa de mis tios, pero si no recuerdo mal creo no uso la interfaz D3DXFont, pero ya te lo confirmo mañana.
Y feliz navidad tb para ti y como no, para todos :D
Salu2 y felices fiestas a todo dios! ;)
Pues a mí también me funciona, paso de poner la imagen :
Adaptador : NVIDIA RIVA TNT2 Model 64/Model 64
Driver : NVDD32.DLL
Version : 14.4523
Revision : 21
Vendor ID : 4318
Tamaño máximo de textura : 2048x2048
Soporta 32 bits de color
Memoria de video total : 29.81 Mb
Pues eso, me va bien, peroooo una pregunta... por qué la necesidad de instalar el motor en el sistema? Supongo que será por comodidad de no ir metiendo dlls y tal en todos los proyectos. Por lo que veo es para VB no?
Saludos!
dx_lib32 son dlls ActiveX (como un control OCX mas o menos) y como son componentes ke se tienen ke registrar para funcionar no podrias ir instalandolas en diferentes carpetas ya que seria una estupidez por ke cada programa que las use llamara siempre a las ultimas dll registradas, no se si me he explicado bien jeje.
Por otro lado hace tiempo se me ocurrio una brillante idea y era que si por ejemplo hacia dos juegos diferentes que utilizaran versiones diferentes de la dx_lib32 estos tuvieran las dlls en la misma carpeta del juego, por ejemplo, y ke las dlls no estuvieran registradas en el sistema. Cuando el juego se iniciara buscara las dlls en su carpeta y las registrara y cuando terminara la ejecucion del juego eliminase el registro, pero esto seria un engorro si tb te dedicas a programar, ademas ke esta tecnica no permitiria ejecutar varias aplicaciones que utilizasen dx_lib32 a la vez.
Yo en principio veo lo veo mas comodo hacerlo como de costumbre, instalar las dlls en la carpeta de sistema, que luego asi tb es mas facil para realizar actualizaciones (claro, siempre y cuando las nuevas versiones sean compatibles con la anterior, ke si no vamos de culo xDD)
Salu2...
P.D.: Alguien puede contestar al cometido del post, por favor :P
Loover, me imagino que
ID3DXFont::DrawText() es lo mismo en C++ que
D3DX.DrawText() en VB, si es asi si utilizaria la interfaz
ID3DXFont. Por si alguien no lo sabe todavia
dx_lib32 esta programado en Visual Basic 6.0.
Loover dijo:Citar(...) peroooo una pregunta... por qué la necesidad de instalar el motor en el sistema? Supongo que será por comodidad de no ir metiendo dlls y tal en todos los proyectos.
Hombre, en principio se supone, mas por ke no lo se con seguridad, que dx_lib32 deberia funcionar en cualquier lenguaje que admita componentes ActiveX (VB, C++, Delphi) ya que no esta atado a ninguna caracteristica especifica de VB o al menos eso creo, pero weno, hasta que no venga alguien y haga la prueba seguira siendo un misterio.
Salu2...
P.D.: Ke tal estaba el Bombay Sapphire? xDDDDD
Haddd dijo:CitarYo he probado el test1 y no me funciona. No se ve nada, ni me da ningún mensaje.
Por pruebas que realize hace algun tiempo se que la
dx_lib32 en algunos ekipos no funciona en modo ventana pero a pantalla completa no le ha fallado a nadie con las ultimas 3 versiones que compile. Es tu caso o tb te falla a pantalla completa??
Salu2...
Bua, que resacón de kilo llevo. (genial)
Gracias por las respuestas.
La verdad es que el sistema que yo uso casi siempre mete la imagen en una única textura como haces tú, porque al tener un tamaño medio de textura máxima las tarjetas del momento de 2048x2048 pues logro meterlas en un único bloque.
Pero creo que tu sistema plantea una serie de problemillas... por ejemplo si la imagen es de 512x512 y el máximo de textura del usuario es de 25x256 al escalarla perderá bastante calidad. Sinembargo si la troceas no. ¿Me equivoco?
Además ahora me planteo el trocearla aún más, como puse en otro post. Pues imagina que tengo una imagen de 513x513... mi sistema la metería en una de 1024x1024 (si el usuario dispone de ese tamaño, sino la trocearía). Pero desde luego eso no sería lo óptimo, desperdiciaría un 74% de textura. Sería mejor una de 512x512, una de 1x512, otra de 512x1 y finalmente una de 1x1 ( O_O ).
No sé, tengo que revisar esa parte en el futuro. Aunque quizás sea mejor desperdiciar memoria que tener tantos cambios de textura.
Reitero mi afirmación de que tu motor mola. Mola mucho (uoh) ¿Para cuando una versión estable y documentada para hacer cosillas con él?
PD: Dios que resacón
Hombre, si es una jodienda si el usuario solo admite 256x256 por si la imagen es muy grande pierde mucha calidad pero weno, en principio yo no usuaria imagenes tan grandes como para que perdieran tanta calidad(excepto casos como el test1 ke utliza una imagen de 700x525 como fondo) pero esa tecnica de partir la textura me desmontaria mi sistema de almacenamiento de texturas, aun asi, ya lo mirare con mas detenimiento.
Loover dijo:Citar¿Para cuando una versión estable y documentada para hacer cosillas con él?
Wenooo... xDDD, hace poco comenze la documentacion de la clase grafica y por culpa de unos arreglos voy a tener ke empezarla de nuevo! xDDDD Hombre, desde hace tiempo la dx_lib32 es ya mas o menos funcional, sobre todo esta ultima que gestiona mejor la memoria que las anteriores, por ejemplo. Ahora lo unico ke le falta es optimizarse un poco mas, pero por lo demas, se podria hacer perfectamente un juego con ella.
A ver si me saco algo mas de tiempo y reparo la web del proyecto y asi subo todos los test (los graficos, los de sonido, de entrada, de video y de sistema; hay para aburrir xDD) y asi mostrar todas las capacidades del proyecto ademas de algun detalle aparte.
Salu2...
P.D.: Por dio! ke alguien me ayude con la cuestion del post! (uoh)
Ya me funciona, no instalé las dx_lib32!!! :huh:
Bueno, me funciona en modo ventana a 170 fps y, sinceramente, me parece muy poco utilizando D3D. Para que te hagas una idea el ejemplo del SDK de billboard me funciona a 500 FPS con 640x480.
En modo full screen SIEMPRE funciona a 75, aunque active o no elk VSync, por lo tienes que mirar algún parámetro que activas mal.
La pregunta es ¿Porqué sólo a 170fps? es muy raro, algo tienes que hacer que sobra. He mirado tu código y parece que cuando haces un render le dices el color, eso me hace suponer que estás haciendo un Clear y después dibujas, y no tiene mucho sentido.
Después, ¿activas el ZBuffer? Porque creo que no lo necesitas para nada, y ganarías velocidad y memoria de vídeo.
¿Tienes todas las texturas en A8R8G8B8 ? ¿Siempre haces blending aunque no haga falta ?
Bueno, no te lo tomes a mal, que yo sólo te digo estas cosas para ver si puedo ayudarte.
Pero lo que decían por allí es que el código me parece muy claro y muy fácil, felicidades.
Hombre, a mi si me va muy bien la demo. No esperaba más de 110 fps en mi cutre Radeon 7200.
El tener el ZBuffer desconectado no se me había ocurrido. ¿Te refieres a tener las imágenes ordenadas por z y dibujarlas en ese orden? Como las que tienen blending...
No necesitas ZBuffer si trabajas en 2D.
Pero si que tengan una coordenada z las imágenes, para indicar cuál dibujar por encima de cuál. Así que habría que ordenarlas.
A mi a pantalla completa no se me autoactiva el vsync sino que los fps van notoriamente más rápidos. Me va muy bien.
Haddd dijo:CitarYa me funciona, no instalé las dx_lib32!!! :huh:
xDD ya me habias asustado joe!
Haddd dijo:CitarBueno, me funciona en modo ventana a 170 fps y, sinceramente, me parece muy poco utilizando D3D. Para que te hagas una idea el ejemplo del SDK de billboard me funciona a 500 FPS con 640x480.
Lo se y me jode no sabes cuanto. Llevo ya mucho tiempo cambiando cosas, quitando tonterias, simplifcando el codigo, en resumen, optimizando como un desgraciado y weno, sus mejoras ha tenido, por ke si vieras en versiones anteriores te daba algo xDDD
Haddd dijo:CitarEn modo full screen SIEMPRE funciona a 75, aunque active o no elk VSync, por lo tienes que mirar algún parámetro que activas mal.
Weno este "bug" ya esta solucionado en la version ke podeis descargar en el proximo post, era una tonteria al iniciar D3D ke me habia comido :P, solo habia activado una parte. Ahora con el VSync desactivado ira igual de rapido que si lo hicierais en modo ventana.
Loover dijo:CitarA mi a pantalla completa no se me autoactiva el vsync sino que los fps van notoriamente más rápidos. Me va muy bien.
Pues si ya te iban los fps a mas de 60 o 75 en pantalla completa sin VSync pseudo-desactivado no kiero saber como te ira con la nueva version (uoh) (genial)
Haddd dijo:CitarLa pregunta es ¿Porqué sólo a 170fps? es muy raro, algo tienes que hacer que sobra. He mirado tu código y parece que cuando haces un render le dices el color, eso me hace suponer que estás haciendo un Clear y después dibujas, y no tiene mucho sentido.
Justo al reves, primero Presento y depues borro:
Device.Present ByVal 0, ByVal 0, m_hWnd, ByVal 0
Device.Clear 0, ByVal 0, D3DCLEAR_TARGET, BackColor, 1#, 0El color es simplemente una opcion ke sumo a la funcion pues para dejar el fondo a otro color ke no sea el negro tipico, alguien habra ke no le guste xDD
Haddd dijo:CitarDespués, ¿activas el ZBuffer? Porque creo que no lo necesitas para nada, y ganarías velocidad y memoria de vídeo.
No uso ZBuffer, no lo veo necesario en la API de programacion. Luego cuando hiciera un juego ahi si implementaria un sistema de ordenamiento para dibujar, o lo ke es lo mismo... un ZBuffer. Mas sencillo y practico, no? ;)
Haddd dijo:Citar¿Tienes todas las texturas en A8R8G8B8 ? ¿Siempre haces blending aunque no haga falta ?
Sip, todas las texturas son A8R8G8B8, asi me aseguro ke cuando leo los pixeles de la textura me devuelve un valor RGB real de 24 o 32 bits si lo deseo. Con lo de blending no te he entendido bien, ¿exactamente a ke te refieres? lo digo por ke creo ke mi concepto de blending puede ser un "pelin" erroneo. (uoh)
Haddd dijo:CitarBueno, no te lo tomes a mal, que yo sólo te digo estas cosas para ver si puedo ayudarte.
Pero como me va a sentar mal? si es lo ke busco, ke saqueis todos los fallos o "supuestos" fallos para asi poder saber ke carajos falla y poder hacer una version mas estable xDD
Haddd dijo:CitarPero lo que decían por allí es que el código me parece muy claro y muy fácil, felicidades.
Gracias, me alegra saber ke resulta tan facil manejar mi API (ole)
Salu2...
La misma version pero con el Bug del VSync solucionado:
dxlib32_Alpha1.0_24-12-03.exeSalu2...
Una optimización podría ser, como dice Haddd, no limpiar el frame buffer. Con eso el incremento de fps debería ser notable. En lugar de limpiar, lo que podrías hacer es dibujar un quad que ocupe toda la pantalla con el color que desées y que pintarías lo primero de todo (background). Supongo que eso siempre será más rápido que hacer un "Clear".
Y con respecto al ZBuffer, no se trata de un ZBuffer "per pixel" sino que cada sprite tendrá una componente Z. Entonces sólo tendrías que ordenar el array de sprites por esa Z y finalmente renderizar en ese orden. De esa forma aceleras las cosas. Además, así también solucionas posibles problemas con el alpha blending.
Y con respecto al blending. Lo que querrá decir Haddd es que si no vas a utilizar transparencias, que no tengas el Alpha Blending activado (D3DRS_ALPHABLENDENABLE).
Saludos.
Olé!! :D
Me alegra que seas de que piensa que las críticas constructivas son el único camino a los 1.000 fps!! :lol:
Bueno, si haces un present y después un Clear TAMPOCO tendrías porqué tener esta ralentización. Quizás VB te está jugando una mala pasada, aunque por ahí está el Truevision 3D que me parece que está hecho en VB que creo que va a tope.
Y otra cosa que me mosquea un poquito, dices que tienes que utilizar R8G8B8 para poder acceder a las texturas, pero..¿para qué quieres acceder? ¿No estarás pintando pixel a pixel para hacer las transparencias?
BeRSeRKeR dijo:CitarY con respecto al ZBuffer, no se trata de un ZBuffer "per pixel" sino que cada sprite tendrá una componente Z. Entonces sólo tendrías que ordenar el array de sprites por esa Z y finalmente renderizar en ese orden. De esa forma aceleras las cosas. Además, así también solucionas posibles problemas con el alpha blending.
Lo de hacer una lista de sprites para dibujar lo pense en su dia pero como utilizo la interfaz D3DXSprite para los graficos y luego primitivas para el dibujo de lineas, puntos, etc... no podria intercalar en principio las operaciones de dibujo de graficos y primitivas. Cuando llamas a la funcion de dibujo esta ya hace la llamada para pintar el grafico o primitiva, la funcion Frame() solo se encarga de hacer la presentacion en pantalla y limpiar despues el backbuffer.
CitarY con respecto al blending. Lo que querrá decir Haddd es que si no vas a utilizar transparencias, que no tengas el Alpha Blending activado (D3DRS_ALPHABLENDENABLE).
D3DRS_ALPHABLENDENABLE lo tengo ke tener activado por ke si no no me usa el ColorKey de la textura. Solo lo desactivo para la funcion DRAW_Background().
Haddd dijo:CitarBueno, si haces un present y después un Clear TAMPOCO tendrías porqué tener esta ralentización. Quizás VB te está jugando una mala pasada, aunque por ahí está el Truevision 3D que me parece que está hecho en VB que creo que va a tope.
VB me juega muchas malas pasadas cuando trabaja con D3D, no se caen bien el uno al otro o vete a saber ke xDD. Con decirte ke una funcion que programe para gestionar elementos vacios del array que contiene las texturas me producia un error grave y me cerraba la aplicacion pero que si no programaba con D3D esta funcion iba sin problemas pos imaginate. Por culpa de esto tengo hacer de vez en cuando alguna chapuza de esas ke rayan los oidos :wacko:
El TrueVision Engine lo estuve probando y por lo ultimo ke lei en su web, ya pasado un tiempo desde la ultima vez ke lo vi, creo haber leido ke las APIs las reprogramaron bajo C++, pero no estoy seguro, aun asi, la gente decia maravillas de el.
CitarY otra cosa que me mosquea un poquito, dices que tienes que utilizar R8G8B8 para poder acceder a las texturas, pero..¿para qué quieres acceder? ¿No estarás pintando pixel a pixel para hacer las transparencias?
Haaaalaa halaa!! ande vas, tio? no soy tan bestia para hacer eso!!! xDDD Ke va. dx_GFX tiene una funcion para leer pixeles de las texturas almacenadas en memoria, y diras tu y mas gente, ¿y para ke narices kiero leer un pixel de una textura???, pues por ejemplo para hacer mapas de durezas como en Div Games Studio o para cualquier otra cosa ke se te ocurra, simplemente. Por cierto, si hiciera las transparencia pixel a pixel me pasaria como la antigua dx_lib32 (la ke estaba programada con DirectDraw) ke no pasaria de los 16 fps y un motor programado con DDraw ke no pase de los 16FPS ya es delito de pena de muerte xDDD
CitarMe alegra que seas de que piensa que las críticas constructivas son el único camino a los 1.000 fps!! :lol:
Las criticas siempre se tienen ke entender como constructivas y tomarlas con buen humor, si no vamos mal paraos xDDD
Salu2...
P.D.: Alguien ke haya probado ya la ultima mejora de la dx_lib32, lo del VSync???
Dios como me gusta este tema, pasarlo al de programación 2d, jajaja.
Mira, te voy a contar como lo hago yo por si te sirve de algo. (En OGL) Pero supongo que en D3D será prácticamente igual. Cuando acabe de portarlo ya te diré.
Lo que hay que evitar, es dibujar con alpha blending activado aquellas imágenes que no la vayan a utilizar. Por lo tanto, a la hora de crear una "superficie" (por llamarlo de alguna manera, no me refiero a las surfaces de DDraw) le paso como parámetro un tipo:
LOV_Opaque
LOV_Sprite
LOV_Alpha
Según el tipo, se almacena en una lista u otra (3 listas) ordenada por Z. A la hora de renderizar, dibujo primero la lista de los opacos, con nada raro activado. Luego los Sprites, con alpha testing activado. Y por último los Alpha, con blending activado. Esto va fostiado, pillos unos framerates cojonudos así.
Un saludo!
PD: Tengo un par de preguntas.
Una para [EX3] => ¿Cuando haces el GetPixel tienes en cuenta si la imagen está escalada? Porque si el GetPixel es con respecto a la resolución de ventana, si la imagen esta escala tema. Habría que tener en cuenta el factor de escala, la rotación, etc.
Para BeRSeRKeR: ¿Eso de no limpiar el frameBuffer. Es algo que se puede hacer en todo tipo de aplicaciones? ¿O solo en esta en cuestión? ¿Y si se puede en todas, pq existe esa función y no una por defecto que coloque ese quad negro que has dicho? Vamos, ¿para que sirve exactamente limpiar el framebuffer y en qué casos?
Cita de: "Loover"Para BeRSeRKeR: ¿Eso de no limpiar el frameBuffer. Es algo que se puede hacer en todo tipo de aplicaciones? ¿O solo en esta en cuestión? ¿Y si se puede en todas, pq existe esa función y no una por defecto que coloque ese quad negro que has dicho? Vamos, ¿para que sirve exactamente limpiar el framebuffer y en qué casos?
Lo de limpiar el frame buffer realmente en un juego no se suele utilizar ya que se pinta en todo el frame buffer por lo que no tiene sentido limpiarlo si vas a sobreescribir en cada frame.
Lo de dibujar el quad de fondo es precisamente para eso, para que se pinte en todo el frame buffer y así ahorrarnos el Clear. Supongo que así será más rápido que limpiarlo.
Juegos como quake3 tienen desactivado por defecto el Clear del frame buffer. Para que os hagáis una idea, si lo activas (/r_clear 1), el frame rate desciende entre 10-20 fps (aunque con la velocidad que lleva el contador de fps es un poco complicado saberlo con exactitud. Lo suyo sería hacer un timedemo).
Saludos.
Loover, el Get_Pixel() no lee los pixeles de la imagen dibujada en pantalla, si no la imagen tal cual la tienes en memoria almacenada. Cualquiera ke haya programado con Div Games Studio sabra, a parte de haberlo explicado en el anterior post, para que sirve leer un pixel de un mapa en memoria (mapas de durezas es el uso mas comun)
Salu2...
Hola!
Berserker, has leido en algun sitio que utilizar un quad a pantalla completa es mas rapido que hacer un Clear? Lo digo porque yo lei no se donde que la funcion Clear procesa muchos ( MUCHOS ) pixels de una tajada, asi que supongo que sera mas rapido que rasterizar poligonos. Ahora me has dejado con la duda :blink:
talogo!
Pues desde mi ignorancia suprema veo ilógico que el Clear tarde más que pintar un quad, dudo que sea así.
Lo que sí veo lógico es que si se va a redibujar toda la pantalla se pueda obviar el Clear.
Ahora bien, luego igual me hace cosas extrañas el resultado, como degradados superchulos que no estaban programados (y que quedan realmente bien) o tonos distintos en los planos con transparencia (que también quedan bien XD)...
Ahora que lo pienso, es verdad lo de que el quake no limpia el framebuffer. Basta con no poner cielo en un mapa para ver ese efecto rarito al dibujarse una cosa después de otra...
Lo que no entiendo, es si poner el quad es más rápido, qué sentido tiene poner esa función. ¿Realmente es más rápido?
Hombre, pues yo acabo de hacer la prueba y ke kereis ke os diga, me va mas rapido con el clear ke con un quad (Test3, el de primitivas, con Clear() = 343 FPS, sin clear usando mi funcion DRAW_Fill_Screen() = 263 FPS)
Mi funcion, DRAW_Fill_Screen() simplemente pinta un poligono de 4 lados con el color especificado ocupando toda la pantalla, pero visto lo visto ahora cambiare esto por un clear, ke parece mas agil.
Por cierto, otra definicion ke no tengo muy clara, cuando hablais de un quad estais hablando de un poligono de 4 lados (usease dos triangulos)?, por que si no es asi he metido la gamba con mi funcion hasta limites insospechados xDDD
Salu2...
A ver, Berserker no quería decir que era más rápido un Quad(es decir, 2 triángulos) que un Clear. Lo que quería decir es que si después del Clear dibujar un Quad para el bitmap de fondo que ocupa toda la pantalla, te puedes ahorrar el Clear. Pero un Clear es muuuucho más rápido que un Quad.
¿Por cierto [EXT] que filtros has usado para las imágenes? Estoy usando filtros Linear de Direct3d y me lo deja todo demasiado difuminado. Esto no me pasaba en OGL. Es decir, cuando tenía la imagen en su tamaño normal sin escalado ni rotación en OGL con los filtros linear se veía perfecta, en Direct3d se me ve difuminada :S. ¿Alguien sabe pq pasa esto?
He hecho un timedemo para saber con mayor precisión la diferencia de rendimiento y el resultado es:
Con limpieza del frame buffer -> 134,4 fps
Sin limpieza del frame buffer -> 157,4 fps
O sea 23 fps más si no limpias el frame buffer...
Saludos.
Cita de: "[EX3"] Hombre, pues yo acabo de hacer la prueba y ke kereis ke os diga, me va mas rapido con el clear ke con un quad (Test3, el de primitivas, con Clear() = 343 FPS, sin clear usando mi funcion DRAW_Fill_Screen() = 263 FPS)
Supongo que tienes desactivado la escritura en el zbuffer. Eso también ayuda a incrementar el rendimiento. Sobre todo cuando no necesitas el depth buffer para nada...
Saludos.
Loover, yo no uso filtros por ke trabajo con la interfaz
DXSprite para el dibujo de todo tipo de graficos, de ahi ke tuviese ke usar escalas para dibujar correctamente los graficos, y esta interfaz no trabaja con los filtros (o por lo menos yo no veo ke le afecte) y el resultado es el ke ves, ni muy difuminado ni muy pixelizado, lo justo jeje.
BeRSeRKeR dijo:CitarSupongo que tienes desactivado la escritura en el zbuffer. Eso también ayuda a incrementar el rendimiento. Sobre todo cuando no necesitas el depth buffer para nada...
dx_lib32 al trabajar solo en 2D no usa el zbuffer para nada y como tu bien dices gana asi mas velocidad.
Salu2...
Hi again.
Una pregunta, ¿como has implementado lo de las primitivas?
Te refieres al dibujo de primitivas? lo hago a traves de la funcion DrawPrimitiveUP() y dependiendo del tipo de primitiva ke fuese a dibujar (linea, punto, caja(doble triangulo)) cambio el primer parametro.
Aca te pongo el codigo de la funcion de dibujo de lineas como ejemplo:
Dim LineStrip(1) As TLVERTEX '//Para dibujar lineas.
'Dibuja una linea:
Public Function DRAW_Line(X1 As Long, Y1 As Long, X2 As Long, Y2 As Long, Color As Long) As Long
On Error GoTo Errout
LineStrip(0) = CreateTLVertex(CLng(X1), CLng(Y1), 0, 1, Color, 0, 0, 0)
LineStrip(1) = CreateTLVertex(CLng(X2), CLng(Y2), 0, 1, Color, 0, 0, 0)
Device.SetRenderState D3DRS_ALPHABLENDENABLE, 1
Device.DrawPrimitiveUP D3DPT_LINESTRIP, 1, LineStrip(0), Len(LineStrip(0))
DRAW_Line = 1
Exit Function
Errout:
DRAW_Line = 0
End Function
El AlphaBlend se desactiva en cada llamada a la funcion de renderizado Frame().
Salu2...
P.D.: Existe alguna manera mas agil de dibujar primitivas (en general), por ke mi funcion DRAW_Circle() peta ke da gusto ya que tiene ke dibujar cada punto a traves de DRAW_Point(), razon por la ke el Test 3 va mas lento de lo normal.
No me refería a como dibujar primitivas con tu librería... sino a como has implementado esas primitivas usando direct3d.
Por ejemplo DRAW_Point()
Pos igual pero para un punto:
Dim PointStrip As TLVERTEX '//Para dibujar puntos.
'Dibuja un punto:
Public Function DRAW_Point(X As Long, Y As Long, Color As Long) As Long
On Error GoTo Errout
PointStrip = CreateTLVertex(CLng(X), CLng(Y), 0, 1, Color, 0, 0, 0)
Device.SetRenderState D3DRS_ALPHABLENDENABLE, 1
Device.DrawPrimitiveUP D3DPT_POINTLIST, 1, PointStrip, Len(PointStrip)
DRAW_Point = 1
Exit Function
Errout:
DRAW_Point = 0
End Function
y la funcion de dibujo de circulos, la ke tanto me peta jeje:
'Dibuja una circunferencia (By Luis):
Public Function DRAW_Circle(X As Long, Y As Long, Radio As Long, Color As Long) As Long
On Error GoTo Errout
Dim i As Long, j As Long
For i = (X - Radio) To (X + Radio)
For j = (Y - Radio) To (Y + Radio)
If Abs((((i - X) * (i - X)) + ((j - Y) * (j - Y)) - (Radio * Radio))) < Radio Then
Call DRAW_Point(i, j, Color)
End If
Next j
Next i
DRAW_Circle = 1
Exit Function
Errout:
DRAW_Circle = 0
End Function
Salu2...
Muchas gracias, aunque así de primeras al no estar en c++ me despista un poco. Probaré a ver.
Venga, me lanzo a la aventura, voy a intentar pasar el codigo de la funcion a C++ xDDD
TLVERTEX PointStrip; //Para dibujar puntos.
//Dibuja un punto:
DWORD DRAW_Point(DWORD X, DWORD Y, DWORD Color); //Era DWORD lo mismo que Long en VB (Entero Largo)???
{
//NOTA: CreateTLVertex() es una funcion externa, no de DirectX.
PointStrip==CreateTLVertex(X, Y, NULL, 1, Color, NULL, NULL, NULL);
Device->SetRenderState(D3DRS_ALPHABLENDENABLE, 1);
Device->DrawPrimitiveUP(D3DPT_POINTLIST, 1, PointStrip, Len(PointStrip)); //No se cual es el sustituto de la funcion Len() de VB.
Return = 0
}
Habra errores a tutiplen xDD, eske hace tela ke no toco el C++.
Aki te posteo en VB el codigo de esa funcion, ke no es mas ke un wraper, creo ke lo llaman, nuse xDD:
'This structure describes a transformed and lit vertex - it's identical to the DirectX7 type "D3DTLVERTEX"
Private Type TLVERTEX
X As Single
Y As Single
z As Single
rhw As Single
Color As Long
specular As Long
tu As Single
tv As Single
End Type
'//This is just a simple wrapper function that makes filling the structures much much easier...
Private Function CreateTLVertex(X As Single, Y As Single, z As Single, rhw As Single, Color As Long, specular As Long, tu As Single, tv As Single) As TLVERTEX
'//NB: whilst you can pass floating point values for the coordinates (single)
' there is little point - Direct3D will just approximate the coordinate by rounding
' which may well produce unwanted results....
CreateTLVertex.X = X
CreateTLVertex.Y = Y
CreateTLVertex.z = z
CreateTLVertex.rhw = rhw
CreateTLVertex.Color = Color
CreateTLVertex.specular = specular
CreateTLVertex.tu = tu
CreateTLVertex.tv = tv
End Function
Salu2...
P.D.: Ke alguien me lo corrija, ke kiero saber si todavia conservo algo de la sintaxis de C++ xDD.
Gracias [EX3] No andaba muy desencaminada tu forma:
>> Esto en el .h:
// Pixel
struct structPixel
{
// Posición
float mX, mY, mZ;
// Coordenadas de textura
//float mU, mV;
// Color
DWORD mColor;
};
typedef struct structPixel PIXEL;
#define D3DFVF_PIXEL (D3DFVF_XYZ | D3DFVF_DIFFUSE)
>> Esto en el .cpp
/*
==================
Coloca un pixel en pantalla con el color y coordenada especificados
==================
*/
inline void LOV_Render::PutPixel (int pX,
int pY,
byte pR,
byte pG,
byte pB,
byte pA)
{
// Pixel
PIXEL mPixel;
// Rellenamos la estructura
mPixel.mX = (float) pX;
mPixel.mY = (float) pY;
mPixel.mZ = (float) 0.0f;
mPixel.mColor = D3DCOLOR_RGBA (pR, pG, pB, pA);
// Color
mInfo.mDevice->SetTextureStageState (0, D3DTSS_COLORARG1, D3DTA_DIFFUSE);
// Dibujamos el pixel
mInfo.mDevice->SetFVF (D3DFVF_PIXEL);
mInfo.mDevice->DrawPrimitiveUP (D3DPT_POINTLIST, 1, &mPixel, sizeof (PIXEL));
}
/*
==================
Dibuja un círculo
==================
*/
inline void LOV_Render::Circle (int pX,
int pY,
int pRadius,
byte pR,
byte pG,
byte pB,
byte pA)
{
for (int i = pX - pRadius; i < pX + pRadius + 1; i++)
{
for (int j = pY - pRadius; j < pY + pRadius + 1; j++)
{
if (abs ((((i - pX) * (i - pX)) + ((j - pY) * (j - pY)) - (pRadius * pRadius))) < pRadius)
{
PutPixel (i, j, pR, pG, pB, pA);
}
}
}
}
Y si que es verdad, va más lento que el caballo del malo. Pero si haces pruebas verás que es el PutPixel, (prueba a quitar el PutPixel al dibujar el círculo y verás que no baja ni un fps) parece ser que Direct3D no está pensado para este tipo de menesteres, con 6 o 7 círculos bajan uno 300fps (nooo) Ya me veo dibujando circulos sobre una textura y escalándolos... ummmm Vivan los métodos cutre salchicheros.
Tal vez sería más rápido dibujar el círculo en una sóla llamada a DrawPrimitive. Y en vez de con puntos, dibujarlo con líneas. De este forma también podrías especificar círculos con diferente nivel de detalle.
Saludos.
Hombre, la verdad, esta funcion esta sacada de un programa escrito en Pascal para DOS.
Simplemente kise meter funciones de primitivas por ke un motor 2D sin funciones de primitivas, pos no se, como ke keda un poco cojo, no?
Mas adelante, si me veo con ganas, me intetare buscar la forma de hacer la funcion como tu dices, por lineas y pudiendo especificar el grado de detalle e incluso la posibilidad de hacerle relleno.
Salu2...
P.D.: Si me puedierais facilitar la direccion de alguna pagina ke trate el tema lo agradeceria mucho.