Bien, el problema quiza no sea un problema, la cosa es q estoy intentando hacer un engine isometrico utilizando directdraw, y como tengo la intencion de implementar translucencia utilizando alpha blend, decidi hacerme mis propios blt, utilizando asm en linea bajo c++.
Me he currado un blt que me coloca unos 700 bloques de 64x32 a 30 fps utilizando colorkey y con una res 640x480x16. Pero la verdad me parece un rendimiento bastante pobre, ya que imagino un mapeado, con transparencia e iluminación, y creo que necesitare bastante mar rendimiento. He buscado información, pero casi todo me lleva a utilizar mmx, y eso lo haria incompatible con maquinas antiguas.
Utilizo el siguiente planteamiento:
- Triple buffer en vram
- Surface de trabajo en memoria principal
- Surface de graficos en memoria principal
* utilizando mi blt coloco los bloques del surface de graficos al de trabajo
* una vez concluido el frame, copio el surface de trabajo al backbufer con bltfast
* hago un flip.
¿Podria sacar mas rendimiento utilizando alguna otra tecnica, q no pase por colocar todos los surfaces en vram?
gracias de antemano.
Se me olvidaba, todo lo anterior son resultados en un k6-2 450 con una ati rage 8m y 192dRam
La verdad es que como tu dices el rendimiento es pobre, pero quizás sea porque la tarjeta no da para más. Piensa que le estás enviando TODO el buffer, eso son 640x480x2 bytes=614.400 bytes x 30 Frames=18.432.000 bytes por segundo. Y estos datos sólo son de copiar con el BltFast.
Prueba a hacer sólo BltFast y mira cual es la velocidad que te da. Esa será tu velocidad máxima. Entonces si sube mucho las FPS sabes que el problema está en la construcción del BackBuffer, pero...¡yo creo que no subirá mucho!
De todas formas, estaría bien que pusieras aquí la rutina de copiar un bloque con ColorKey, para que la veamos y te podamos dar ideas de optimización.
Esta bien Dracula, la rutina es la siguiente:
//pitch source
sPitch = m_lPitch;
//pitch destino
dPitch = lpDest->GetPitch();
//Puntero origen
sPtr = GetSurfacePtr();
//Puntero destino
dPtr = lpDest->GetSurfacePtr();
sPtr += (rSrc.top * sPitch);
dPtr += (lDestY * dPitch);
__asm
{
pushad
mov eax, rSrc.left
shl eax,1
add [sPtr], eax //sPtr= sPtr + (rSrc.top * sPitch)+(rSrc.left * bytesPerPixel)
mov eax, lDestX
shl eax,1
add [dPtr], eax //dPtr= dPtr + (lDestY * dPitch)+(lDestX * bytesPerPixel)
mov ebx, rSrc.bottom //Alto = bottom - top
sub ebx, rSrc.top //ebx = Alto
mov edx, rSrc.right
sub edx, rSrc.left
shl edx,1
sub [sPitch], edx //sPitch = sPitch - (ancho*bytesPerPixel)
sub [dPitch], edx //dPitch = dPitch - (ancho*bytesPerPixel)
//edx ancho
mov edi,dPtr
mov esi,sPtr
linea:
mov ecx, edx //ecx = edx = ancho en bytes
clearloop:
cmp ecx, 4
jb menor4
mov eax,ds:[esi]
or eax, eax
jz next
or ax,ax
jnz axsi
shr eax,16
mov ds:[edi+2],ax
jmp next
axsi:
push ax
shr eax, 16
jnz losdos
pop ax
mov ds:[edi],ax
jmp next
losdos:
shl eax,16
pop ax
mov ds:[edi],eax
next:
add esi,4
add edi,4
sub ecx,4
jnz clearloop
jmp finbucle
menor4:
mov ax, ds:[esi]
or ax,ax
jz next2
mov ds:[edi], ax
next2:
add esi,2
add edi,2
finbucle:
add edi, dPitch
add esi, sPitch
dec ebx
jnz linea
popad
}
-----------------------------------------
rSrc es el RECT origen una vez hecho el clip necesario
lDestX, lDestY son las coordenadas de destino
Esta es la rutina para 16 BPP, procesa 2 pixel al mismo tiempo. Tengo otra para 8 BPP que procesa 4 pixels, pero saca un rendimiento parecido (unos 900 bloques).
Creo que al implementar alpha blend en 16BPP el rendimiento caera bestialmente. En 8BPP tmb caera, pero en menor medida, ya que utilizando una LUT imagino que la rutina no se ralentizara mucho (eso espero).
He estado observando el Diablo y Diablo2 y estoy seguro de que ambos trabajan en 8BPP, pero no imagino como hacen para colocar tantisimos bloques graficos, con transparencia, translucencia e iluminacion dinamica, espero que podais orientarme un poco.
Hola DoVerMan_.
Hace tiempo que no trasteo con ASM, asi que perdonadme si digo una burrada, pero no creo que las cosas hayan cambiado mucho con el tiempo.
Creo que esa subrutina tiene que ser lenta porque haces muchas comprobaciones y tiene una gran cantidad de saltos y accesos a memoria. Algo obvio: piensa en la cantidad de ciclos que tarda en volcar un único pixel y multiplicalos por todos los pixels para entender lo que tarda en total.
¿Has probado el típico bucle para dibujar un sprite (16bpp):
...
LODSW
OR AX, AX ;Si es 0 no se imprime (colorkey)
JZ next
STOSW
next:
...?
¿No debería ser esto más rápido?
Saludos
[ Este Mensaje fue editado por: Juan Mellado el 2002-05-07 11:53 ]
Si, como dice Juan Mellado, me parece que para hacer la comprobación de los pixels negros no merece la pena hacerlo de 2 en 2, demasiadas comprobaciones...
prueba sin nada a ver:
| |
__asm
{
mov eax, rSrc.left
shl eax,1
add [sPtr], eax //sPtr= sPtr + (rSrc.top * sPitch)+(rSrc.left * bytesPerPixel)
mov eax, lDestX
shl eax,1
add [dPtr], eax //dPtr= dPtr + (lDestY * dPitch)+(lDestX * bytesPerPixel)
mov ebx, rSrc.bottom //Alto = bottom - top
sub ebx, rSrc.top //ebx = Alto
mov eax, rSrc.right
sub eax, rSrc.left
mov edx, eax
shl eax,1
sub [sPitch], eax //sPitch = sPitch - (ancho*bytesPerPixel)
sub [dPitch], eax //dPitch = dPitch - (ancho*bytesPerPixel)
//edx ancho
mov edi,dPtr
mov esi,sPtr
mov ecx, edx
linea:
mov ax,word ptr[esi]
or ax,ax
jz next
mov word ptr[edi],ax
next:
add esi,2
add edi,2
dec ecx
jnz linea
add edi,dPitch
add esi,sPitch
mov ecx, edx //ecx = edx = ancho en pixels
dec ebx
jnz linea
}
|
... y haciendo que siempre salte al mismo sitio, a "linea", puede que corra mas...
un saludo
[ Este Mensaje fue editado por: fiero el 2002-05-07 12:18 ]
Coño, como has hecho para que el codigo aparezca como en los foros de FlipCode??
Un secreto asi vale MILLONES :sonriendo:
P.D. por que no haces en lugar de 'jmp xx' un 'jmp short xx'. Tal y como veo el codigo, los bloques de instruccion apenas se distancian unos bytes en codigo, con lo que al realizar un salto con rango corto no se emplean tantos ciclos en el calculo de ramificacion, no? al menos antes se hacian esas optimizaciones, ahora no se...
[ Este Mensaje fue editado por: Emotion el 2002-05-07 12:22 ]
[Fiero]
Una duda, como este post va de optimización: ¿es más rápido el mov ax,[]/mov[],ax/add edi, 2/add esi, 2 que el lodsw/stosw?
[Emotion]
Para lo del código como en flipcode busca un post "Pasteo de Código" en el tablón General.
Lo de los saltos short/far ¿nos los resuelve (o debiera) el ensamblador a menos que se especifique de forma explícita?
Saludos
Por eso dije que no sabia, aunque mas que no saber, no estaba seguro... pero claro, estamos hablando de asm inline, no asm puro... al menos yo ahora mismo no se si VC++ te hace las optimizaciones el solo (me gustaria pensar que es asi) o has de decirle tu como hacer los saltos... :sonriendo:
[Juan Mellado]
en un 386 (las tablas de pentium no las tengo a mano):
lodsw --- 5 ciclos
mov ax,word ptr[esi] --- 2 ciclos
add esi,2 --- 2 ciclos
stosw --- 4 ciclos
mov word ptr[esi],ax --- 2 ciclos
add edi,2 --- 2 ciclos
A mi me parece que tanto monta, monta tanto. Incluso leí en un manual de Intel que con un pentium y posterior es más rápido hacer "dec ecx", "jnz etiqueta" que un "loop etiqueta" como antiguamente, o sea, que estan optimizando las instrucciones sueltas y las que hacen varias cosas a la vez internamente ejecutan las instrucciones sencillas.
[Emotion]
Coño, no te pierdes una!! :riendo:
un saludo
Doverman, no me has dado el ejemplo de los FPS que tienes al hacer un simple BltFast. Pruébalo y postealo.
[Juan Mellado][Emotion]:
He probado lo que me indicabais: colocar los pixels 1 a 1, pero es bastante mas lento que mi rutina 2 a 2 y creo q se porq:
1.- Al leer lees 2 pixels en vez de 1
2.- Si un pixel es 0, hay muchas probabilidades de que el siguiente tmb, por lo que comprobar dos pixels de golpe, en la mayoria d los casos es más rapido. Sin olvidar el formato de un tile isometrico, en los que prácticamente el 50% es transparente.
3.- Si despues de realizar los test, son validos los dos pixels, se colocan de una vez, con lo que puede aumentar el rendimiento.
Además, en casi toda la documentación que puedes encontrar sobre alpha blend en 16BPP, se menciona que una de las mejoras q se obtiene al utilizar mmx (entre otras muchas, por supuesto) son los registros de 64 bits, que te permiten leer y escribir en bloques de 4 pixels.
De todas formas sigo sin saber xq el rendimiento es tan pobre. Estoy realizando multiples pruebas, y obtengo mejoras sobre el rendimiento anterior, pero mejoras de 20 25 bloques +, lo cual no me soluciona nada.
Lo peor de todo es q estoy seguro de q se pude hacer mejor d otra forma.
Gracias por vuestra ayuda, y no dejeis de colocar cualquier otra idea o sugerencia q tengais.
[ Este Mensaje fue editado por: DoVerMan_ el 2002-05-07 14:04 ]
Dracula, ¿cuando dices lo de un BltFast simple, te refieres a q haga simplemente BltFast de la superficie de trabajo al BackBuffer y obtenga el rendimiento?
Pues lo siento. Tenía buena pinta. Pero si no va más rápido, no va más rápido y punto.
Otra posibilidad sería optimizar más el bucle usando código in-line para disminuir el número de saltos. Repites 2 veces seguidas el bucle más interno y ejecutas el bucle la mitad de veces. Se ahorra la mitad de dec/jnz. (Este esquema lo puedes repetir para más de 2 veces).
Otra posibilidad (por aquello del 50% vacio) es utilizar sprites RLE (creo que los llamaban así). En vez de tratar los sprites como bloques los tratas línea a línea y span a span guardando donde empieza cada span y la longitud de cada uno de ellos. Lees donde empiezan, la longitud y vuelcas todos los pixels de golpe (o los procesas o lo que quieras). Pero ten en cuenta en que el recorte ahora es distinto, puedes hacer el backbuffer más grande para evitarlo.
Lo del MMX: ¿no decías que no lo querías para mantener compatibilidad con máquinas antiguas?
Saludos
P.D. En todo caso espero no estar haciendote perder el tiempo con estas sugerencias.
Para Juan Mellado,
Bueno, lo de desenrollar los bucles es buena idea, siempre y cuando no tengas que pasar por el bucle inicial mas de 10000 veces :sonriendo:
En cuanto a lo del RLE, debes tener cuidado, ya que en si mismo no es un sistema de codificacion, sino de compresion (RLE: Run-Length Encoded), y si lo que buscas es velocidad, no te la dara, de hecho la unica ventaja que tiene el RLE es que es un algoritmo de compresion lossless, aunque no comprime mucho, la verdad, aunque no se a que modelo de RLE te refieres, al menos yo conozco 2: el RLE4 y el RLE8 (que es el que se usa o, mejor dicho, usaba con los archivos graficos .PCX, al menos aquellos que iban comprimidos, si bien creo que el .BMP tambien lo podia usar)
Para Doverman_:
En cuanto a lo del MMX, a que tipo de maquinas te quieres acercar con el motor? si no utilizas MMX la 'mejor' maquina a la que te podrias acercar, creo que era un pentium 166 no? es decir, tu lo quieres compatibilizar con procesadores pentium de gama baja? bueno, evidentemente no es una mala manera de hacer las cosas, tendras una buena razon para ello, aunque creo que hoy dia el que tiene la maquina mas lenta o de mas baja gama tiene un pentium MMX, asi que creo que deberias pensarlo, ya que eso incluso haria que el codigo se ejecutara igual en un Intel que en un AMD, lo que si que no vale (o al menos eso tengo entendido) es utilizar instrucciones SIMD de 128bits (o sea, ni SSE ni SSE2), ya que tengo entendido que AMD tiene su propio juego de instrucciones.
De cualquier manera, creo que lo del MMX es una buena opcion... estas seguro de que quieres eliminarlo?
Un Saludo
[Emotion]:
No es que descarte directamente utilizar mmx, es q conforme hago mas pruebas, mas creo q hay algo q no rula bien.
Voy a realizar una prueba básica, q creia funcionaba perfectamente, pero ahora no estoy nada seguro:
Voy a eliminar todo lo no necesario y a poner el motor grafico a hacer flip's sin mas, y calculare los fps q saca.
¿Cuantos deberia sacar, para saber q la cosa está bien, teniendo en cuenta la maquina q tengo?
Por favor orientarme un poquillo.
Vamos a ver... que maquina tienes exactamente?
[Emotion]
Todo esquema de compresión es en si mismo un esquema de codificación.
Y sí, el RLE que tú dices lo utilizan los BMP.
A ver si me explico mejor: Almacenar dos valores: 1) donde empieza el span (primer pixel no invisible) y 2) la logitud del span (número de pixels consecutivos no invisibles). Eso es una forma de codificación RLE.
Está comprimiendo, sí, pero lo interesante no es que sólo reduce el tamaño, sino que te evita procesar pixels invisibles centrándote en los visibles.
Saludos
Mi maquina es un k6-2 450, con 192MB de ram una ati rage2c de 8MB.
Bien he realizado la prueba q antes decia, he puesto el motor gráfico a hacer flip's
y me saca 86 FPS, ¿Es poco verdad?
Pues Doverman, ese es tu máximo. Ahora piensa que esto es haciendo sólo BlitFast y Flip!! Si además tienes que construir tu el fondo...En fin, creo que deberías pasar a DX, es la única forma. Para darte una idea, yo tengo un Pentium 200 con una Savage 32 MB. Pues bien, en el ejemplo que tengo de mi motor hago lo siguiente:
En una pantalla de 800x600
Borro el fondo con un color.
Dibujo una imagen de TODA la pantalla rotándola.
Las FPS son(creo recordar) de 115 FPS
Si además le añado sprites, ¡apenas baja!
Si quieres probarlo, bájate el motor de mi página:
http://webs.ono.com/dracular
y te quejas de 86 FPS? Pero si eso significa que va de muerte... de hecho con ese tipo de refresco en cualquier pantalla se vera muy bien y los ojos de mas de uno te lo agradeceran (incluyendo los mios :sonriendo:)
[Dracula]:
No entiendo cuando dices q he d pasarme a DX, el motor gráfico lo estoy haciendo con DirectDraw7.
Por cierto los 86 FPS son solo flip's, es decir:
* Inicio DirectDraw
* Creo triple buffer
* realizo flip's
Tu motor Dracula no me rula, asi como la mayoria de las aplicaciones q utilizan D3d, no se porque, aunq los juegos si q me funcionan.
[Emotion]:
Si q me quejo de bajo rendimiento, ten en cuenta que este resultado de FPS es solamente realizando flip's, a esto hay que añadirle absolutamente todo: gráficos, transparencias, translucencias, iluminación, sonido, IA, scripts, etc, es decir, 86 fps es posible q sean una kk, d todas formas es mi primera apli utilizando directdraw, y por eso no se si es mucho, poco o suficiente. El problema es q no quiero avanzar hasta estar seguro de q la base del motor rula con sufiente soltura como para comenzar a añadir cosas.
Que version del SDK de DirectX estas usando?
Estoy utilizando el sdk 8.0 para todo, excepto para DirectDraw, q no se xq venia defectuoso (DDraw.lib) y como no variaba respecto al sdk 7, pille este archivo y lo añadi.
Supongo que por esa razon no te funciona bien, porque seguramente habra alguna diferencia de DDraw7 a DDraw8, pero no lo se, yo tengo el SDK de DirectX8.0 tambien, aunque no observe problemas en la ejecucion de los ejemplos...
Has intentado que alguien te deje el SDK para que lo vuelvas a instalar? a lo mejor con eso puedes hacer pruebas de un modo mas objetivo, porque si te funciona mal puede que no te este dando los resultados correctos, pero no lo puedo asegurar :sonriendo:
Un Saludo
Otra opción, si tu ancho de banda te lo permite: bájatelo de
http://download.microsoft.com/download/win...N-US/Dx8sdk.exe
[Emotion]:
No creo q sea fallo del sdk ni de las librerias, DirecDraw no ha sido modificado desde DirectX 7, en DirectX 8 se añade DirectGraphics, y se abandona (deja de actualizarse) DirectDraw. Al instalar el sdk 8, a mi tambien me funcionan los ejemplos q utilizan DirectDraw, pero al compilarlos me da un error de link, diciendome q no se puede colocar en una dirección del fichero DDraw.lib. Miré el archivo, y mientras el que viene con el sdk 8 ocupa 4'5kb, el q viene con el sdk 7 ocupa 28'5kb, asi q lo reemplazas y listo, los ejemplos y todo lo q utilize DirectDraw rula y se compila bien.
En ese caso no se porque te falla...
Siento no poder serte de mucha mas ayuda. Lo siento... :triste:
[Emotion]:
Si no es q falle, las DX no me fallan, de hecho utilizando Visual Studio 5.0, no tengo problemas para compilar mi codigo.
El problema, está en q no se si el rendimiento es adecuado o no, es decir ¿Necesitare mas fps, para conseguir montar una escena isometrica, similar a las de diablo, o mejor aun, diablo2?
A mi la verdad lo q me mosquea es que estos dos juegos puedan mover todo lo q explique mas arriba (luz dinamica, transparencias, translucencias, etc) y a un frame-rate decente. No es q quiera hacer o pueda hacer yo lo mismo, pero una aproximación bastante mas baja imagino q si, (eliminando cientos de opciones que tienen).
Doverman, debes usar DX8.1 para utilizar mi motor y ver los ejemplos.
Si tu utilizas DX7..¿has probado ejecutar tu código en algún ordenador que tenga DX8.1 instalado? A lo mejor no funciona. Te lo digo porque hay cosas que a mi no me funcionan que con versiones anteriores sí me funcionaban.
Respecto a lo de usar DX, tu usas DX sólo para bloquear los buffers. Yo me refiero a que uses TODO el tiempo DX y no accedas a buffers salvo para lo más imprescindible.
Y si sólo tienes 80 FPS haciendo Flip...¡yo creía que era haciendo bltFast!! Pruébalo con un BltFast y un Flip, a ver cuanto te da y ese sí es tu máximo!
Y respecto a cómo lo hará el Diablo, con mi motor, por ejemplo, puedes tener esa velocidad con todos esos efectos. El secreto:Simplemente que yo uso D3D y tu no.
[Dracula]:
Esta claro, q utilizando d3d, se puede hacer todo eso y mas (como bien dices)a un frame-rate decente, pero tanto diablo, como diablo2 (el cual t puedo aseguro, se puede poner para q rule utilizando directdraw) utilizan 2d, y tmb realizan todo eso, asi como otro monton de juegos en 2d q tmb lo hacen.
No quiero decir con esto q las 3d no sean lo mejor (de hecho si q creo q es lo mejor) para hacer un motor isometrico, lo q pasa es que soy muy novato en esto de las DX y no quiero adentrarme en el tenebroso mundo de D3D hasta no tener un manejo adecuado d un simple engine 2d :ojo:
Supongo que no lo sabes, pero existe un modo de vértice que es 2D. Eso quiere decir que no necesitas PARA nada saber 3D. Se programa igual, igual que si fuera 2D, pero con todas las ventajas:
-Máxima velocidad
-Transparencias y efectos.
-Clipping automático.
-Rotaciones y escalados.
¡Y todo esto sin necesidad de entender el mundo 3D!
Si todo eso q dices es cierto dime donde me puedo apuntar a ese maravilloso mundo :ojo:
¿Podrias darme alguna direccion?
[Dracula]:
¿Todo lo q me has dicho, sin utilizar D3D?
Nunca habia oido nada d lo q mencionas, t agradeceria mucho q me dijeras donde puedo conseguir info sobre ese tema, ya sea en castellano o ingles, no atranco a la hora de aprender.
En la SDK de DX.Bájate la última versión, la 8.1, y mira el apartado de FVF. Hay un modo que es el FVF_XYZRHW donde los vértices funcionan como si fuera una pantalla en 2D.
Empieza con los tutoriales y cuando llegues al ejemplo de pintar un triángulo, lo que debes hacer es crear los vértices con este formato y asignar la x,y a sus valores, dejando la w=1
Muchas gracias Dracula por la info, pero estoy intentando realizar otras pruebas con 8 BPP a ver si obtengo rendimientos decentes, y la cosa parece q va bien.
Me he currao una nueva rutina para colocar bloques con colorkey en 8 BPP, y la he comparado con un BltFast con colorkey, y obtengo los siguientes resultados
*K6-2 450 Ati Rage2C 8Mb 192MbRam Win98
- Media de bloques utilizando BltFastColorKEY = 947 bloques por frame (30 fps)
- Media de bloques utilizando XBltColorKEY = 1917 bloques por frame (30 fps)
*PII-2 450 Riva TNT 32Mb 128MbRam Win2k
- Media de bloques utilizando BltFastColorKEY = 1109 bloques por frame (30 fps)
- Media de bloques utilizando XBltColorKEY = 2675 bloques por frame (30 fps)
¿Que os parecen estos resultados?
¿Creeis q son buenos teniendo en cuenta q la resolucion es 640x480x8?
Doverman, creo que vas por muy mal camino. Hoy en día, que la gente renderiza a 32bpps y a 1024x768, tu desarrollas un engine basado en 256 colores y 640x480, que además tiene un FrameRate bajo. ¿no piensas que quizás esta pelea tuya por conseguir más fps a costa de perder capacidad está mal encaminada? Sólo tienes que aprender un poco de DX y podrás hacer lo que quieras!
Te explico Dracula:
Como ya te dije antes, el problema no es aprender a base de documentos, codigo, o cualquier otra cosa, el problema es q la tarjeta esta de la kk (Ati Rage2c 8Mb) no me deja comprobar absolutamente ninguno de los codigos que me bajo de la red o de los q vienen con el sdk 8.1, por ejemplo me remito a lo q me dijiste d los tutoriales de D3d q trae el sdk: cualquiera de ellos los puedo compilar, pero no los puedo ejecutar, es decir si q los puedo ejecutar, pero no me sale absolutamente nada, lo cual es desquiciante.
Yo empece a aprender DX hace aprox 1 mes, y ya he tocado tanto directdraw, como directinput. Y t puedo asegurar q el motivo por el cual me puse a programar en 2d en vez de 3d, es el q t he comentado mas arriba, ya q para mi habria sido mas sencillo (a pesar dq son infinitamente mas complicadas) ir directamente a aprender D3D.
Por favor, si se t ocurre alguna idea sobre el problema q tengo para ejecutar D3D, no dejes de comentarmelo.
[DoVerMan_]
Justo ayer estaba probando a dibujar 1200 bloques de 16x16 (y luego una imagen con alpha blend que ocupaba toda la pantalla encima) usando el metodo que te comenta Dracula (osea, usar trianglulos tranformados).
En mi modesto p233MMX + VooDoo Banshee me iba a unos 55 fps (640x480x16 y 800x600x16)
Vale la pena que averigues pq no te va Direct3D...
Citar
El 2002-05-06 19:59, DoVerMan_ escribió:
Bien, el problema quiza no sea un problema, la cosa es q estoy intentando hacer un engine isometrico utilizando directdraw, y como tengo la intencion de implementar translucencia utilizando alpha blend, decidi hacerme mis propios blt, utilizando asm en linea bajo c++.
Me he currado un blt que me coloca unos 700 bloques de 64x32 a 30 fps utilizando colorkey y con una res 640x480x16. Pero la verdad me parece un rendimiento bastante pobre, ya que imagino un mapeado, con transparencia e iluminación, y creo que necesitare bastante mar rendimiento. He buscado información, pero casi todo me lleva a utilizar mmx, y eso lo haria incompatible con maquinas antiguas.
Utilizo el siguiente planteamiento:
- Triple buffer en vram
- Surface de trabajo en memoria principal
- Surface de graficos en memoria principal
* utilizando mi blt coloco los bloques del surface de graficos al de trabajo
* una vez concluido el frame, copio el surface de trabajo al backbufer con bltfast
* hago un flip.
¿Podria sacar mas rendimiento utilizando alguna otra tecnica, q no pase por colocar todos los surfaces en vram?
gracias de antemano.
He estado mirando tu rutina y bueno quizas te venga bien conocer el par de manera que usabamos en los viejos tiempos para hacer esto rapido, por software.
Claro.
1º Tecnica. Pre-Analisis de segmentos
Vamos a ver, antiguamene cogiamos los graficos y los "preanalizabamos", buscando los segmentos que habia de gracio, por ejemplo
para el grafico :
OOO121OOO210
OO443212OO12
OO1111111111
Siendo O un pixel negro y los demas de color.
De ese graico sacabamos 5 tiras
tira 0 del pixel (3,0) longitud 3
tira 0 del pixel (9,0) longitud 2
tira 2 del pixel (2,1) longitud 6
tira 3 del pixel (2,1) longitud 2
tira 4 del pixel (10,10) longitud 2
Luego las poniamos en una estructura del tipo..
offsetx:offsexty
longitud
[datos]
Asi la podiamos recorrer y con un puntero y unas bonita sumas hacer memcpy de los datos para pintar simple y otras operaciones para
transparencias y demas.
Habia una mejor que era guardar las tiras "de color variados" por un lado y las de color uniforme por oro (rle) y entonces hacer memcpy y memset
El resultado pintas todas las tiras sin hacer ninguna comparacion menos la del propio bucle en si
2º Metodo. Precompilar
Una vez realizado el primer metodo se podia ir aun mas alla...
Cogias las tiras y generabas codigo ASM que al ejecutarse hacia las operaciones, ya desparecia incluso el bucle era un trozo de codigo que al ejecutarse pintaba
Bueno espero que te sirva de algo
Saludos
PD: Revisando el correo quizas hay algo que no quede claro.
La precompilacion consitia en generar una subrutina, opcodes y datos, y cargarla en memoria con sus stowb, reps, o lo que fueran.
[ Este Mensaje fue editado por: mICrO el 2002-05-10 15:54 ]