Desactivar Opciones De La Targeta

[Loover]

 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

[[EX3]]

 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:

¿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)  

[Haddd]

 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.

[Loover]

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

[Haddd]

 No necesitas ZBuffer si trabajas en 2D.

[Loover]

 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.

[[EX3]]

 Haddd dijo:

Ya me funciona, no instalé las dx_lib32!!!  :huh:

xDD ya me habias asustado joe!

Haddd dijo:

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.

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:

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.

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:

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.

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:

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.

Justo al reves, primero Presento y depues borro:

Código [Seleccionar] Expand

Device.Present ByVal 0, ByVal 0, m_hWnd, ByVal 0
Device.Clear 0, ByVal 0, D3DCLEAR_TARGET, BackColor, 1#, 0
El 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:

Despué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:

¿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:

Bueno, 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:

Pero 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...

[[EX3]]

 La misma version pero con el Bug del VSync solucionado: dxlib32_Alpha1.0_24-12-03.exe

Salu2...

[BeRSeRKeR]

 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.

[Haddd]

 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?

[[EX3]]

 BeRSeRKeR dijo:

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.

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.

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

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:

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.

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.

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?

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

Me 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???

[Loover]

 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?

[BeRSeRKeR]

 

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.

[[EX3]]

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

[MChiz]

 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!