Foros

Estes días he estado intentar acelerar mis ports de intros de 1k/4k que utilizan glsl/sm3.0 en software rendering. Hasta la fecha, dichos ports habían estado trabajando bajo GDI y pudiendose ejecutar a muy bajas resoluciones y framerates. Con GDI he estado utilizando la versatil función StrechDIBits, que según el msdn:

— The StretchDIBits function copies the color data for a rectangle of pixels in a device-independent bitmap (DIB) to the specified destination rectangle. If the destination rectangle is larger than the source rectangle, this function stretches the rows and columns of color data to fit the destination rectangle. If the destination rectangle is smaller than the source rectangle, this function compresses the rows and columns by using the specified raster operation. —

Una maravillosa función que te permite reescalar tu ventana sin ninguna complicación y tener un buffer preparado y calentito para pintar en el sin ningún costoso proceso adicional…

Aún a pesar de lo maravillosa que sea dicha función, establecí un “aleatorio supuesto” de que podía influír muy negativamente en el bajo framerate que estaban obteniendo mis ports, por lo que decidí intentar utilizar la vieja Direct draw. Tras 2 tardes malgastadas aprendiendo todo lo que es el proceso para inicializar Direct Draw (nunca había utilizado directx hasta hoy), hice un wrapper de todo y lo conseguí incluir en mi framework.

Pero cual es mi sorpresa cuando utilizo Direct Draw para ejecutar los ports, esperando ver una mejoría notable frente a GDI? Que el framerate que obtengo es en todos los casos (resoluciones 32bits) peor. Sinceramente, no entiendo el porqué.

Los bucles de render utilizando ambas maneras son estes:

-GDI: http://pastebin.com/m7dae9446
-Direct Draw: http://pastebin.com/m139ad6c

Todo me lleva a pensar que el overhead de utilizar BeginFrame/EndFrame en la versión de directx hace q inevitablemente tenga q ser por narices más lento q la versión GDI… Pero por lo poco que se, creo que es imposible evitar el tener q utilizar dichas funciones si quieres controlar correctamente tu aplicación direct draw.

Pero todas estas pruebas me llevan al siguiente interrogante. ¿Por qué muchas demos antiguas utilizaban el sistema Direct Draw para demos de tipo Soft Rendering? La mayoría de las que le he visto los sources utilizan simplemente Direct Draw para obtener acceso a memoria de video y nada más, los cálculos de los efectos están implementados en sus respectivos engines…

Más engorrosa de inicializar, ocupa “muchísimo” más espacio, más lenta (supuestamente si no se demuestra lo contrario) …

¿No hay ninguna mejor alternativa que StrechDIBits para este tipo de aplicaciones que simplemente necesitan un buffer donde dibujar? (En windows, no msdos)

Sigo investigando…

Bueno, voy seguir los consejos de Gargaj a ver q tal:

<GargajCNS> what i’d recommend is
<GargajCNS> do the rendering in a buffer
<GargajCNS> and then just only open the dx surface for a little time while you copy into it
<GargajCNS> because otherwise you can stall the AGP writes

Pero luego, tus demos como correran en Chrome OS?

Fácil, en el 2050, cuando me ponga a hacer demos tendré a mis hijos o nietos que harán los ports ;D

todas las cosas que he hecho en soft-rendering bajo Windows usan GDI con StrechDIBits. Ójala fuera tan buen programador como para que el límite de velocidad de mis efectos fuera StrechDIBits y no el efecto en sí. Conclusión, no pierdas el tiempo con DX ni DDraw. Abre tu ventana, pinta en un buffer y pintalo con StrechDIBits. Esto es todo lo que necesitas: http://escena.org/wiki/page/UnaVentanaDondePintar/

Si la demo te va lenta, no es GDI, es tu demo

Ummm, el caso es que ya había perdido dos tardes con la engorrosa direct draw, y bueno, no es que me haya echo mucha gracia perder así el tiempo pero ahora puedo escoger entre GDI/Directx/Opengl en mi framework.

La verdad, no estaba haciendo las cosas muy bien con direct draw (por desconocimiento). Algo que ahora es obvio para mi, como la diferencia entre el width y el pitch enlace , antes yo estaba utilizando el width en la función update de la superficie y para algunas resoluciones en fullscreen hacía que el resultado fuese desastroso, otra cosa es que no estaba renderizando en buffer y despues copiando a superficie… y demás movidillas.

De todas formas, ahora ya todo funciona a las 100000 maravillas y puedo sacar las siguientes conclusiones. Efectivamente, si que se puede notar un cambio de velocidad entre directx y gdi… Pero esta diferencia se va a notar principalmente no en ventanas que sean de igual tamaño. Sino que a la hora de redimensionar la ventana, si estás utilizando StrechDiBits y estiras/agrandas la ventana, se producirá una brutal caída en el rendimiento, y sin embargo, utilizando direct draw, el rendimiento se mantendrá y además, el filtrado que se produce es increiblemente bueno, muchísimo mejor resultado que el utilizado por strechdibits. Lo que te permite utilizar una resolución baja y obtener resultados bastante buenos.

100% de acuerdo, lo estoy notando ahora que me voy a poner a intentar optimizar varias intros del estilo (1 quad-1 bendición-sm3.0) que he portado a software rendering. De las que llevo portadas: chocolux, crawlspace, massive clods, metatunnel, monjori, roadofribbon y valleyball. Estoy obteniendo los siguientes resultados en resolución de 320×200.

Por orden de ejecución: crawlspace(20fps)<monjori(13fps)<chocolux(12fps)<metatunnel(2fps)<massiveclods(2fps)<roadofribbon(1fps)<valleyball(1fps).

Estoy utilizando mi librería matemática que no tiene versión simd aún, pero supongo que será el siguiente paso obvio implementarla. Además, la pena es que no pueda usar multithreading debido al monoprocesador q tengo… De todas maneras, seguiré intentando optimizarlas hasta conseguir buenos resultados en 320×200, aunque de momento es una meta que veo bastante lejana

Por cierto, si alguien se aburre en algún momento, me podría dar algunos datos de las velocidades a la que se le ejecutan dichos ports y en q procesador? Nota: la tardanza de la valleyball inicial es debido al precálculo que hace 4klang, que es el sinte q utilizan… He subido el archivo a mediafire, Pack ports Intros glsl sm3.0 . En el irc pera me había comentado otra web de hosting pero s m ha olvidado , y este es de los primeros que encontré googleando “free upload files” .

@kneda Yo te lo pruebo si le haces un cambio al programa …

• Que guarde en el fichero de log las ejecuciones, no sólo la última
• y que de paso guarde la media de fps, para no tener que andar con lapiz y papel.
  Con eso y sabiendo que quieres que “cate” te lo hago en un ti-ta

Yo te lo pruebo si haces una demo

Y yo si haces dos.