Estoy aprendiendo directX 9, y quería saber si sabeis como puedo decirle que cuando pinte un surface no pinte un color (es decir como el color transparente de un gif). Lo máximo que he conseguido hasta ahora es que cuando cargo una imagen de un fichero, un color elegido pasa a ser negro, pero nada más.
Saludos
Antes de renderizar la primitiva debes de activar el blend e indicar sus valores, algo asi:
device->SetRenderState( D3DRS_ALPHABLENDENABLE, TRUE );
device->SetRenderState( D3DRS_SRCBLEND, D3DBLEND_SRCALPHA );
device->SetRenderState( D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA );
Editado: Buscando algun link para pasarte he encontrado esta web: http://www.eggheadcafe.com/forumarchives/win32programmerdirectxgraphics/
Vaya por delante que no formo parte del lado oscuro... ...pico en Ogl... pero vamos flipo en colores si para hacer un AlphaTest, q pase un pixel o no.. Dx necesita usar BLENDING... lol lol lol ( icono-borracho )
Se puede hacer mediante un test alfa, pero segun la documentacion puede que no este soportado por todo el hardware con lo que creo que es mejor asegurarse de que funcione, ademas este es el sistema de toda la vida para crear transparencias teniendo un canal alfa.
HRESULT D3DXLoadSurfaceFromResource(
LPDIRECT3DSURFACE9 pDestSurface,
CONST PALETTEENTRY * pDestPalette,
CONST RECT * pDestRect,
HMODULE hSrcModule,
LPCTSTR pSrcResource,
CONST RECT * pSrcRect,
DWORD Filter,
D3DCOLOR ColorKey,
D3DXIMAGE_INFO * pSrcInfo
);
ColorKey
[in] D3DCOLOR value to replace with transparent black, or 0 to disable the colorkey. This is always a 32-bit ARGB color, independent of the source image format. Alpha is significant and should usually be set to FF for opaque color keys Thus, for opaque black, the value would be equal to 0xFF000000.
Quieres decir que no es esto ?
Me tratas de explicar que un hardware que no soporta Alpha Test soportará Alpha Blending ? lol lol lol ( icono - borracho )
el sistema de toda la vida ? :shock:
Informate mejor antes de comenzar a criticar: http://msdn.microsoft.com/library/default.asp?url=/archive/en-us/directx9_c_summer_03/directx/graphics/programmingguide/GettingStarted/Direct3DDevices/States/renderstates/alphatestingstate.asp
En concreto este trozo es el que yo digo
CitarNot all hardware supports all alpha-testing features
La funcion que indicas sirve para leer una textura y modificar el canal alfa segun el color que le indiques, esa funcion es la que usa McBain para leer las texturas, pero lo que el no sabia era como hacer que efectivamente funcionara el color de transparencia, para ello con usar el codigo que le he puesto estaria.
CitarMe tratas de explicar que un hardware que no soporta Alpha Test soportará Alpha Blending ?
Que parte de la pregunta no entiendes ?
Te criticaré con el mismo morro que tu dices estupideces con tanta soberbia. Si encuentras algún hardware que SI soporte Alpha Blending y NO soporte Alpha Test, dejaré de escribir en estos foros para siempre... que estas dispuesto a jugarte tu ?
Dejaré de programar, y me dedicaré a criar pollos, conejos y cerdos, si demuestras que el BLENDING es el sistema de toda la vida para que no se pinte un color de pixel.
Por otro lado, el Alpha Test.
...
pd3dDevice->SetRenderState( D3DRS_ALPHATESTENABLE, true );
pd3dDevice->SetRenderState( D3DRS_ALPHAREF, 0x01 );
pd3dDevice->SetRenderState( D3DRS_ALPHAFUNC, D3DCMP_GREATEREQUAL );
...
http://www.computersciencelab.com/Direct3DTut1.htm
CitarTe criticaré con el mismo morro que tu dices estupideces con tanta soberbia. Si encuentras algún hardware que SI soporte Alpha Blending y NO soporte Alpha Test, dejaré de escribir en estos foros para siempre... que estas dispuesto a jugarte tu ?
Creo que te estas alterando y no atiendes a razones, no es que diga yo estupideces, es que sencillamente lo dice la documentacion, no hay mas.
CitarNot all hardware supports all alpha-testing features. You can check the device capabilities by calling the IDirect3D9::GetDeviceCaps method. After retrieving the device capabilities, check the associated D3DCAPS9 structure's AlphaCmpCaps member for the desired comparison function. If the AlphaCmpCaps member contains only the D3DPCMPCAPS_ALWAYS capability or only the D3DPCMPCAPS_NEVER capability, the driver does not support alpha tests
Y respecto a tu pregunta sencillamente no se responderte ya que yo nunca he dicho que pueda existir uno sin el otro, pero si miras la documentacion veras que sobre el alpha blending no se indica nada de que no pueda ser soportado por todo el hardware (o por lo menos no lo he visto), yo solo me remito a la documentacion, asi que soberbia no tengo, el problema lo tienes tu.
pero ma]mestre, acaso en OGL no hay que activar blending para que haga alphatest al pintar un quad? es que es igual que en DX
A.- Alpha Test
B.- Blending
B no puede existir, si no exite previamente A.
Conclusión:
Si A no es soportado por el harware, B tampoco lo será.
---
Es una estupidez recomendar el uso de BLENDING cuando el ALPHA TEST resuelve el problema infitamente más rápido.
---
Es una estupidez más grande decir que el BLENDING es el sistema de toda la vida para que no se pinte un color de pixel, simplemente pq es mentira. Aunque supongo q esto ya lo asumes, pq no dices nada en tu último post.
Cita de: "MAMestre"]Es una estupidez más grande decir que el BLENDING es el sistema de toda la vida para que no se pinte un color de pixel, simplemente pq es mentira. Aunque supongo q esto ya lo asumes, pq no dices nada en tu último post.
Que quieres que te diga, no se como seria antes, y cuando digo antes digo hace 10 años a lo poco, por que los 6 que llevo empollandome Direct3D (desde DirectX7) todos los ejemplo tiran de Blending para hacer alphablending y asignacion de color transparente o Colorkey en la textura, el AlphaTest los pocos ejemplos que lo implementan (que da la casualidad que son 2 del SDK) lo traen como opcional y con previa comprobacion de si es o no soportado por la tarjeta, cosa que con el Blending jamas he visto hacer.
Salu2...
Cita de: "tamat"pero ma]mestre, acaso en OGL no hay que activar blending para que haga alphatest al pintar un quad?
No tamat.
//www.m3str3.org/AlphaTest.rar
#include <windows.h>
#include <stdio.h>
#include <gl\gl.h>
#include <gl\glu.h>
#pragma comment (lib,"opengl32.lib")
#pragma comment (lib,"glu32.lib")
int BeginOpenGL (HWND hWnd);
void Render (void);
void SetDCPixelFormat (HDC hdc);
void LoadSprite (const char *ruta,short ancho,short alto,GLubyte **sprite);
LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM );
HINSTANCE hInst;
GLuint ntexture;
int iLessGreater=GL_LESS;
int WINAPI WinMain (HINSTANCE hInstance,HINSTANCE hPrevInstance, LPSTR lpCmdLine, int iCmdShow)
{
char nombre []="OpenGL";
HWND hWnd;
MSG msg;
WNDCLASSEX wndclass;
hInst=hInstance;
wndclass.cbSize=sizeof (wndclass);
wndclass.style=CS_HREDRAW|CS_VREDRAW;
wndclass.lpfnWndProc=WndProc;
wndclass.cbClsExtra=0;
wndclass.cbWndExtra=0;
wndclass.hInstance=hInstance;
wndclass.hIcon=LoadIcon (NULL, IDI_APPLICATION);
wndclass.hIconSm=LoadIcon (NULL, IDI_APPLICATION);
wndclass.hCursor=LoadCursor (NULL, IDI_APPLICATION);
wndclass.hbrBackground= (HBRUSH ) GetStockObject ( WHITE_BRUSH);
wndclass.lpszMenuName=NULL;
wndclass.lpszClassName=nombre;
RegisterClassEx (&wndclass);
hWnd=CreateWindowEx ( NULL,
nombre,
"OpenGL",
WS_CLIPCHILDREN | WS_CLIPSIBLINGS | WS_VISIBLE | WS_BORDER | WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
600,
600,
NULL,
NULL,
hInstance,
NULL);
while (GetMessage (&msg, NULL, 0, 0))
{
TranslateMessage (&msg);
DispatchMessage (&msg);
}
return msg.wParam;
}
LRESULT CALLBACK WndProc (HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
{
static HGLRC hrc;
static HDC hdc;
static HANDLE hilo=NULL;
static float AnguloRotacion=0.0f;
DWORD w9x;
switch (iMsg)
{
case WM_CREATE:
hdc=GetDC(hWnd);
SetDCPixelFormat(hdc);
hrc=wglCreateContext (hdc);
wglMakeCurrent (hdc,hrc);
BeginOpenGL(hWnd);
return 0;
case WM_PAINT:
Render();
SwapBuffers (hdc);
return 0;
case WM_KEYDOWN:
if (iLessGreater==GL_LESS) iLessGreater=GL_GREATER;
else iLessGreater=GL_LESS;
return 0;
case WM_DESTROY:
wglMakeCurrent (hdc,NULL);
wglDeleteContext (hrc);
PostQuitMessage (0);
return 0;
}
return DefWindowProc ( hWnd, iMsg, wParam, lParam);
}
int BeginOpenGL (HWND hWnd)
{
static GLubyte *Unicornio,*Pwar;
glEnable (GL_DEPTH_TEST);
glEnable(GL_TEXTURE_2D);
glEnable ( GL_ALPHA_TEST );
glViewport (0,0,600,600);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(60.0f,1.0f, 1.0f, 800.0);
glClearColor(0.0f,0.0f,1.0f,0.0f);
LoadSprite ("pwar.bmp",128,128,&Unicornio);
glGenTextures(1, &ntexture);
glBindTexture(GL_TEXTURE_2D, ntexture);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, 4, 128, 128, 0, GL_BGRA_EXT, GL_UNSIGNED_BYTE,Unicornio);
free (Unicornio);
return 0;
}
void SetDCPixelFormat (HDC hdc)
{
int n;
PIXELFORMATDESCRIPTOR pfd;
memset (&pfd,0,sizeof(pfd));
pfd.nSize=sizeof (PIXELFORMATDESCRIPTOR);
pfd.nVersion=1;
pfd.dwFlags=PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER;
pfd.iPixelType=PFD_TYPE_RGBA;
pfd.cColorBits=8;
pfd.cDepthBits=32;
n=ChoosePixelFormat (hdc,&pfd);
SetPixelFormat (hdc,n,&pfd);
}
void LoadSprite (const char *ruta,short ancho,short alto,GLubyte **sprite)
{
int tam=ancho*alto*3;
GLubyte *aux;
HANDLE fp;
DWORD b;
GLint i,j;
fp=CreateFile (ruta,GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
*sprite=(GLubyte *)malloc(tam);
aux=(GLubyte *)malloc(ancho*alto*4);
SetFilePointer(fp,54,NULL,FILE_BEGIN);
ReadFile (fp,*sprite,tam,&b,NULL);
for (i=0,j=0;i<(ancho*alto*3);j++,i++)
{
if ( i % 3 == 0 && i!=0)
{
if (* (aux+j-1)<120 && *(aux+j-2)<120 && *(aux+j-3)<120 )
*(aux+j)=255;
else
*(aux+j)=0;
j++;
}
*(aux+j)=*((*sprite)+i);
}
free(*sprite);
*sprite=aux;
CloseHandle (fp);
}
void Render (void)
{
glMatrixMode(GL_MODELVIEW );
glLoadIdentity();
glTranslatef (0.0f,0.0f,-50.0f);
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glAlphaFunc (iLessGreater, 0.5f);
glBindTexture(GL_TEXTURE_2D,ntexture);
glBegin (GL_TRIANGLE_STRIP );
glTexCoord2f(0.0f, 0.0f); glVertex3f (-10.0f,-10.0f,0.0f);
glTexCoord2f(0.0f, 1.0f); glVertex3f (-10.0f,10.0f,0.0f);
glTexCoord2f(1.0f, 0.0f); glVertex3f (10.0f,-10.0f,0.0f);
glTexCoord2f(1.0f, 1.0f); glVertex3f (10.0f,10.0f,0.0f);
glEnd ();
}
Zupervaca, gracias por contestar. ¿Me permites hacer unas preguntas más?
El código no me funciona (algo habre hecho mal). Estoy trabajando en 2D y con surfaces, para que funcione, he usar textures? O bien, es por el método en que dibujo las surfaces en pantalla, las dibujo usando StretchRect sobre el backSurface?
Saludos,
y gracias por la atención
¿Podrias poner el codigo o el proyecto para descargar? Asi seria mas facil encontrar una solucion al problema.
Me parece que la funcion StretchRect no hace caso de los cambios de estados, pero no se decirtelo seguro ya que nunca la he usado, normalmente se usa la clase sprite de direct3dx o se implementa una renderizando con dos triangulos u otro tipo de primitivas que formen un cuadrado.
CitarAunque supongo q esto ya lo asumes, pq no dices nada en tu último post
Yo no asumo nada, ¿has hecho rutinas graficas en asm en la epoca de ms-dos o en otras plataformas? una comprobacion era mucho mas lenta que usar operaciones para pintar una imagen con mascara de color.
Cita de: "McBain"Estoy trabajando en 2D y con surfaces, para que funcione, he usar textures? O bien, es por el método en que dibujo las surfaces en pantalla, las dibujo usando StretchRect sobre el backSurface?
Que yo tenga entendido no se aplican efectos como transparencias ni rotaciones ni nada en concreto sobre surfaces, solo sobre texturas, a no ser que esto haya cambiado en DirectX9, claro.
Si estas tratando de hacer un motor 2D con D3D tendras que jugar con poligonos a los que aplicas la posicion, tamaño y angulo del sprite y aplicar sobre ello una textura sobre la que aplicas tintado, iluminacion, transparencias, espejados o lo que quieras. De esto suele haber muchos ejemplos en la red, tutoriales muy basicos.
Salu2...
Cita de: "zupervaca"
Yo no asumo nada, ¿has hecho rutinas graficas en asm en la epoca de ms-dos o en otras plataformas? una comprobacion era mucho mas lenta que usar operaciones para pintar una imagen con mascara de color.
En esa época del MS-DOS... ¿exactamente qué operación era más rápida que un TEST AL,AL?
Cita de: "MA"Si encuentras algún hardware que SI soporte Alpha Blending y NO soporte Alpha Test, dejaré de escribir en estos foros para siempre...
¿Quieres uno? La S3 Virge. Aaaaadiooosss! ;)
De hecho, los drivers D3D de la S3 Virge *emulaban* Alpha Testing activando en su lugar Alpha Blending, lo que nos dio no pocos quebraderos de cabeza, porque los pixels transparentes por Alpha Testing no escriben en el ZBuffer, pero los transparentes por Blending si. Hablamos de 1997... en el 98 ya era infrecuente que juegos comerciales se molestasen en soportar la Virge. O sea que no es lo que se dice muy relevante.
A día de hoy se asume que el Alpha Testing existe y funciona realmente como debe, porque es muy útil y se usa en practicamente todos los motores gráficos.
CitarEn esa época del MS-DOS... ¿exactamente qué operación era más rápida que un TEST AL,AL?
Lo mas rapido en ms-dos para pintar imagenes con mascara es no comprobar nada, solo pintar lo necesario :P
No obstante pasate por esta web por ejemplo, hay muchas mas solo es cuestion de buscar en google: http://andercheran.upv.es/~amstrad/docs/sprites.html
Cita de: "zupervaca"CitarEn esa época del MS-DOS... ¿exactamente qué operación era más rápida que un TEST AL,AL?
Lo mas rapido en ms-dos para pintar imagenes con mascara es no comprobar nada, solo pintar lo necesario :P
Ya sé que se pueden utilizar sprites comprimidos para evitar esas comprobaciones, pero aquí se está hablando de usar un "color transparente".
Cita de: "zupervaca"una comprobacion era mucho mas lenta que usar operaciones para pintar una imagen con mascara de color
Ya que hablamos de usar un "color transparente" y de "máscaras de color" (nada de sprites comprimidos, precompilados, etc.), repito mi pregunta: ¿Qué operación utilizabas que fuese más rápida que un TEST?
Si, cómo tú mismo dices, usas "mascara de color", ¿cómo comprobabas esa máscara?
Cita de: "zupervaca"Yo no asumo nada, ¿has hecho rutinas graficas en asm en la epoca de ms-dos o en otras plataformas? una comprobacion era mucho mas lenta que usar operaciones para pintar una imagen con mascara de color.
Pos va a ser que he hecho unas cuantas rutinas en la época de ms-dos... ...pero el haber hecho o estar haciendo, no da más fuerza ni más rigor ni más prestigio a mis palabras... por lo demás, espero la respuesta a la pregunta de sés.
Cita de: "[EX3"] todos los ejemplo tiran de Blending para hacer alphablending y asignacion de color transparente o Colorkey en la textura"
Para hacer alphablending es lógico tirar de blending. Nunca he dicho lo contratio. Ahora que para hacer un color transparente usen Blending, es una estupidez. Y me la pela que salga en los SDK de Microsoft, yo, como creo que deberiais tener todos, tengo mi criterio propio y critico todo lo que me parece una estupidez... por mucho MS que sea...
...por ejemplo, los ejemplos del SDK de DirectxShow de MS hacen servir la instrucción "goto"... ...que debo pensar sobre ello ? que es una estupidez ? o me sumo al carro ?
cual es la finalidad del Alpha Test ? cual es su proceso interno ? en que posicion de la cadena del pipeline esta situado ?
Ahora haceros las mismas preguntas para el Alpha Blending... ...y después con VUESTRO CRITERIO... responder si para hacer un pixel trasparente o no... se deberia usar una técnica o la otra...
Para el yogourth la cuchara, para las patatas el tenedor.
Cita de: "Jare"¿Quieres uno? La S3 Virge. Aaaaadiooosss! ;)
De hecho, los drivers D3D de la S3 Virge *emulaban* Alpha Testing activando en su lugar Alpha Blending, lo que nos dio no pocos quebraderos de cabeza, porque los pixels transparentes por Alpha Testing no escriben en el ZBuffer, pero los transparentes por Blending si. Hablamos de 1997... en el 98 ya era infrecuente que juegos comerciales se molestasen en soportar la Virge. O sea que no es lo que se dice muy relevante.
A día de hoy se asume que el Alpha Testing existe y funciona realmente como debe, porque es muy útil y se usa en practicamente todos los motores gráficos.
Qua adios más entusiasta. :lol:
He estado buscando las Specs Técnicas de la S3 Virge, no las he econtrado... pero sin ellas y sin dudar de tu palabra, dire que:
a) OpenGL desde su primera version 1992-1997 soporta Alpha Test y Alpha Blending ( no con todas las combinaciones de ahora ).
b) OpenGL, nunca ha especificado que estas opciones son dependientes del hardware. Que raro, no ? Pq DirectX en su documentación del SDK del summer 2003 si lo pone ? lo pone en el SDK actual ? :wink:
c) La S3 Virge no soportaba OpenGL entonces ? aun que varias personas de S3 por entonces tomaban parte y voto en las reuniones de la ARB ? :roll:
d) Que es más complicado desde el punto de vista técnico ? implementar un Alpha Test o un Alpha Blending ? Cual de las dos técnicas es más rápido de computar ?
estooo.... todas las funciones de OpenGL estarán implementadas siempre en un driver bien hecho, el problema es que lo que no esté soportado por hardware lo estará por software y será probablemente inutilizable en tiempo real a efectos prácticos.
sobre tus preguntas:
b) Opengl fuerza todo a estar presente mediante fallback software si no fuese posible por hard. DirectX no obliga a nada ya que entiende que una implementación software podría ser poco util. Lo suyo es que la aplicación consulte y utilice solo las funciones implementadas por hard si requiere velocidad. (familia GetCaps en DX y GetInteger()+bases de datos basadas en vendor string en OpenGL).
c) Soportase OpenGL o no, era la época negra de la programación OpenGL en windows (y si me apuras de DX también, pero de OpenGL mejor ni hablar). Dejémoslo correr :D
d) Por software, alpha test es potencialmente más rápido al ser simplemente una comparación. Blending implica hacer una mezcla de color (por ejemplo una media ponderada mediante alpha de la textura).
alpha test: if (framebuffer[x,y].alpha > texel.alpha) then framebuffer[x,y] = texel
blending: framebuffer[x,y].pixel = framebuffer[x,y].pixel * (1-texel.alpha) + texel.pixel * texel.alpha
Es pseudocódigo y asume que tu alpha test es MAYORQUE y blending es el INVSRCALPHA para destino y SRCALPHA para origen. Es sólo un ejemplo de complejidad no una comparativa del mismo resultado con diferente método.
Veamos ¿por que tengo que defender lo que dice la documentacion de direct3d? El que contradiga a la documentacion que busque el informacion y la ponga aqui y pierda su tiempo, ya estoy cansado de que como lo digo yo esta mal o es mentira, asi que buscar vosotros la informacion para decir que lo que yo digo y la pone la documentacion de direct3d sobre alpha testing es mentira, yo paso de perder tiempo en demostrar algo que esta mas que claro, pero como siempre lo que decis vosotros tiene que ir a misa.
Editado: No habia leido todos los posts, para ses con el rollu del test que creo que no sabe muy bien lo que esta diciendo, veamos, el test se puede ejecutar muy rapido pero lo que es el jnz, jz, etc NO, mas rapido que este sistema es tener un bitmap de color y otro bitmap de mascara, despues con un AND y un OR se hace todo lo necesario para pintar una imagen transparente, eso si es mas rapido que el TEST y su SALTO, ademas es como se ha hecho toda la vida, espero que te haya quedado claro y si no busca en google como hacer mascara de color con estas dos instrucciones en google.
no lo pude resistir... POST MADE IN STRATOS! lo hice...
La que podéis montar por una cuestión de colorkey....
No puedo evitar sumarme a la bronca, en la era MSDOS, si color del pixel del sprite a "dibujar" == a colorkey, pues no se pinta!!! que porras mascaras!! modernos mas que modernos!! :mrgreen:
Desde aquel post de MA]Mestre, en que decía que respondíamos como si lo supiéramos todo... me esperaba algo así... :?
Pasando al tema del post: McBain no pones mucha información... pero supongo que estarás dibujando a base de polígonos, usando Direct3D... mas que nada por que ya no existe DirectDraw :mrgreen: ,a estas alturas muchos usan blending... mas que nada por todos hemos ido a las 3D antes que ninguna otra cosa, por que molan mas hay que reconocerlo, los que saben algo mas y bucean por la documentación descubren al alphatest, pero como sigue haciendo falta un valor de alfa, pues siguen tirando de blending... mas que nada para aprovechar y usar ese valor para transparencias de todo tipo....
Y después de esto están los que saben mas aun, y usan colorKey por que AUN funciona. Con la desaparición de DirectDraw, y la necesidad de hacer gráficas 2D a trabes de Direct3D se a ido perdiendo, pero esta ahí, la respuesta de MA]Mestre es correcta, y ni siquiera yo pensaba en la posibilidad de usar colorKey a estas alturas con Direct3D :oops:
Por otro lado con el segundo msg de McBain es evidente que no usa polígonos para dibujar sus sprites.... que me lol, aun esta leyendo alguien!?¿!?!? MacBain si ves la documentación veras que StretchRect no es lo que necesitas, de hecho la solución de zupervaca no te funciona por que entiende que usas poligonos para dibujar tus sprites!!!!
PD.: Si, el tamaño es a propósito :mrgreen:
[offtopic]
te voy a pasar la factura del oftalmologo...
[/offtopic]
Citarla respuesta de MA]Mestre es correcta, y ni siquiera yo pensaba en la posibilidad de usar colorKey a estas alturas con Direct3D
Ni tu ni nadie por la sencilla razon de que el alpha testing descarta pixels con el problema de que no suaviza los bordes como hace el alpha blending, es decir, veras que donde comienza la zona transparente de la imagen habra un corte en seco, en cambio con alpha blending esto no sucede ya que hace un suavizado ya que todos los pixels se tienen en cuenta, no se si me explico bien, pero a estas alturas tener imagenes con bordes cuadriculados no pega mucho con modernidad.
Cita de: "MAMestre"]Para hacer alphablending es lógico tirar de blending. Nunca he dicho lo contratio. Ahora que para hacer un color transparente usen Blending, es una estupidez. Y me la pela que salga en los SDK de Microsoft, yo, como creo que deberiais tener todos, tengo mi criterio propio y critico todo lo que me parece una estupidez... por mucho MS que sea...
Yo no estoy hablando especificamente de alphablending aunque lo haya mencionado, estoy hablando que los tutoriales basicos que encuentras en internet fuera del SDK o webs de M$ que te enseñan a usar el colorkey de una textura lo hacen por medio de Blending y no de AlphaTest y tiene su 'logica y razon'. Sobre criterio, estoy totalmente deacuerdo contigo, solo que mi criterio en estos casos actua mas sobre compatibilidad que sobre 'el metodo correcto y mas eficiente', prefiero que mis programas garanticen que van a funcionar en cualquier equipo a encontrarme luego que por usar 'el metodo correcto y mas eficiente' no lleguen a funcionar en otros equipos por que el hardware no soporta esa feature ;) Esto me recuerda a las incontables features que tenia DirectDraw (no Direct3D7) como uso de canal alpha o el zbuffer cuando no existia tarjeta alguna que soportase features como esa en algo que no fuera 3D :lol: Vale que el AlphaTest a dia de hoy es dificil encontrar una tarjeta que no lo soporte pero sigue teniendo su 'logica y razon' de por que no se usa tanto como el Blending.
Cita de: "MAMestre"]...por ejemplo, los ejemplos del SDK de DirectxShow de MS hacen servir la instrucción "goto"... ...que debo pensar sobre ello ? que es una estupidez ? o me sumo al carro ?
Perdon!?? :lol: Reconozco que no he mirado todos los tutoriales del SDK sobre DirectShow pero los pocos que he visto jamas he visto un Goto :P No osbtante dime que tutorial es que le eche un ojo, que no me extrañaria encontrame algo asi xD
Cita de: "MAMestre"]Ahora haceros las mismas preguntas para el Alpha Blending... ...y después con VUESTRO CRITERIO... responder si para hacer un pixel trasparente o no... se deberia usar una técnica o la otra...
Y digo yo, no es un poco estupida toda esta cuestion que estas formando con el AlphaTest? No has pensado que luego
McBain querra aplicar AlphaBlending? Para que vas a implementar AlphaTest y Blending cuando con Blending cubres las dos necesidades? Ahi tienes la 'logica y razon' de por que se usa y recomienda Blending y no AlphaTest en la mayoria de tutoriales de toda la red.
Salu2...
Cita de: "MAMestre"]b) OpenGL, nunca ha especificado que estas opciones son dependientes del hardware
[...]
d) Que es más complicado desde el punto de vista técnico ? implementar un Alpha Test o un Alpha Blending ? Cual de las dos técnicas es más rápido de computar ?
Puedes creerme, yo sí he tenido en mis manos las especificaciones de la Virge bit a bit y registro a registro. Y sobre todo, he trabajado con ella.
Ya han explicado que la especificación de OpenGL exige un fallback software que, aunque funcional, probablemente no de el rendimiento exigido. Alpha Test en general es más rápido de ejecutar que un blend, pero alpha test en software será más lento que blend por hardware. :P Como dice zuper, el test genera bordes "duros" que pueden quedar muy feos, pero el blending tiene su propio conjunto de problemas: ordenación y multipass son los más clásicos. El tercer problema clásico (y el que más quebraderos de cabeza me dio en su momento) es el hecho de que con blending, los texel transparentes también escriben en el ZBuffer.
Hoy en día lo del ZBuffer se suele resolver activando blending Y testing a la vez, aunque suelen quedar unas babas un poco feas alrededor del gráfico. Lo de la ordenación se puede abordar o bien exigiendo una PowerVR (juas), o usando algún truco sucio como el de Tom Forsyth de hacer una pasada con alpha y otra con blending sin escribir la Z. Esto último no funciona bien en todos los casos, pero cuando lo hace parece de verdad.
Antes nada, decir que gracias por todos que os habeis interesado en contestarme. Siento no haber contestado antes, pero es que ayer estaba de examenes. No me imaginaba que el tema del color keying diera tanto que hablar.
He hecho una serie de cambios en el código, antes trabajaba con Offscreen Plain Surfaces, y segun he leído en los mensajes he de trabajar con Textures, también segun lo que he leído, he de trabajar con el D3DXSPRITE.
Respecto a mi código, quizás es un poco raro (y se podrían mejorar muchas cosas supongo, tengo la manía de hacer la implementación de algunos métodos dentro del fichero *.h para que sean inline). Se tratan de dos clases una llamada Graphic y otra llamada Sprite. La primera se encarga de inicializar D3D, el Device, y D3DXSPRITE (en un método llamado Init). Esta es friend de Sprite, y cuando termina el método Init pone el valor del miembro engine (static) de Sprite a this (he hecho para no tener que pasar el device siempre como parametro). En cuanto a la clase sprite, esta se encargaría de cargar una imagen del disco duro y ponerla en pantalla, siendo el color transparente por ejemplo el rosa chillón (algo que tal vez se cambia a un color por parametro).
Aqui esta el código:
Graphic.h
#pragma once
#define GFULL D3DFMT_X8R8G8B8
#define GWINDOW D3DFMT_UNKNOWN
class Graphic
{
friend class Sprite;
public:
Graphic(void);
bool Init(HWND hWnd,bool Windowed,int sizeX,int sizeY,D3DFORMAT Format=D3DFMT_UNKNOWN);
void Release(void);
void Clear(D3DCOLOR Color)
{
pd3dDevice->Clear(0, NULL, D3DCLEAR_TARGET,Color, 1.0f, 0 );
}
void Render(void)
{
HRESULT hr;
pd3dSprite->End();
pd3dDevice->EndScene();
//if(backbuffer)
//{
// backbuffer->Release();
// backbuffer=NULL;
//}
hr=pd3dDevice->Present(NULL,NULL,NULL,NULL);
if(FAILED(hr)) ::OutputDebugString("ERROR: Present");
}
D3DFORMAT Format(void) const
{
return format;
}
void Prepare(void)
{
HRESULT hr;
//hr=pd3dDevice->GetBackBuffer(0,0,D3DBACKBUFFER_TYPE_MONO,&backbuffer);
hr = pd3dDevice->BeginScene();
if(FAILED(hr)) ::OutputDebugString("ERROR: Begin Scene");
pd3dSprite->Begin(D3DXSPRITE_ALPHABLEND);
}
~Graphic(void);
private:
LPDIRECT3D9 pD3D;
LPDIRECT3DDEVICE9 pd3dDevice;
LPDIRECT3DSURFACE9 backbuffer;
LPD3DXSPRITE pd3dSprite;
D3DFORMAT format;
int SizeX,SizeY;
};
Graphic.cpp
#include "Engine.h"
Graphic::Graphic(void)
{
pD3D=NULL;
pd3dDevice=NULL;
backbuffer=NULL;
pd3dSprite=NULL;
SizeX=SizeY=0;
ZeroMemory(&format,sizeof(D3DFORMAT));
}
Graphic::~Graphic(void)
{
Release();
}
void Graphic::Release(void)
{
if(pD3D)
{
if(pd3dDevice)
{
if(pd3dSprite)
{
pd3dSprite->Release();
pd3dSprite=NULL;
}
pd3dDevice->Release();
pd3dDevice=NULL;
}
pD3D->Release();
pD3D=NULL;
}
}
bool Graphic::Init(HWND hWnd,bool Windowed,int sizeX,int sizeY,D3DFORMAT Format)
{
HRESULT hr;
D3DPRESENT_PARAMETERS d3dpp;
pD3D=Direct3DCreate9(D3D_SDK_VERSION);
if(!pD3D) return false;
ZeroMemory(&d3dpp, sizeof(d3dpp));
d3dpp.Windowed = Windowed;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
format=((Windowed)?(D3DFMT_UNKNOWN):(Format));
d3dpp.BackBufferFormat = Format;
d3dpp.BackBufferCount = 1;
d3dpp.BackBufferHeight = sizeY;
d3dpp.BackBufferWidth = sizeX;
d3dpp.hDeviceWindow = hWnd;
SizeX=sizeX;
SizeY=sizeY;
hr = pD3D->CreateDevice(D3DADAPTER_DEFAULT,D3DDEVTYPE_REF,hWnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING,&d3dpp,&pd3dDevice);
if(FAILED(hr))
{
Release();
return false;
}
hr = D3DXCreateSprite(pd3dDevice, &pd3dSprite);
if(FAILED(hr))
{
Release();
return false;
}
Sprite::engine=this;
Sprite::SizeX=sizeX;
Sprite::SizeY=sizeY;
return true;
}
Sprite.h
#pragma once
class Sprite
{
friend class Graphic;
public:
Sprite(void);
bool Load(const char * File);
void Release(void);
~Sprite(void);
void X(int nx)
{
x=nx;
};
int X(void) {return x;};
void Y(int ny)
{
y=ny;
};
int Y(void) {return y;};
int Height(void) {return height;};
int Width (void) {return width;};
void Draw(void)
{
//if(engine->backbuffer)
//{
engine->pd3dSprite->Draw(texture,&rect,&D3DXVECTOR3(width/2,height/2,0),&D3DXVECTOR3(x,y,0.0f),0xFFFFFFFF);
//}
}
static int SizeX,SizeY;
protected:
RECT rect;
int x,y;
int width;
int height;
LPDIRECT3DTEXTURE9 texture;
static Graphic *engine;
};
Sprite.cpp
#include "Engine.h"
int Sprite::SizeX=0;
int Sprite::SizeY=0;
Graphic * Sprite::engine =NULL;
Sprite::Sprite(void)
{
texture=NULL;
rect.bottom=0;
rect.left=0;
rect.right=0;
rect.top=0;
x=y=0;
width=height=0;
}
Sprite::~Sprite(void)
{
Release();
}
bool Sprite::Load(const char *File)
{
HRESULT hr;
D3DXIMAGE_INFO imageInfo;
hr = D3DXCreateTextureFromFileEx(Sprite::engine->pd3dDevice,File,D3DX_DEFAULT,
D3DX_DEFAULT,D3DX_DEFAULT,D3DUSAGE_RENDERTARGET ,D3DFMT_UNKNOWN,
D3DPOOL_DEFAULT,D3DX_DEFAULT,D3DX_DEFAULT,D3DCOLOR_XRGB(255,0,0),
&imageInfo,NULL,&texture);
if(FAILED(hr))
return false;
rect.top=0;
rect.left=0;
rect.right=imageInfo.Width;
rect.bottom=imageInfo.Height;
width=imageInfo.Width;
height=imageInfo.Height;
return true;
}
void Sprite::Release()
{
if(texture)
{
texture->Release();
texture=NULL;
}
}
Engine.h
#include <d3d9.h>
#include <d3dx9.h>
class Sprite;
class Graphic;
#include "Graphic.h"
#include "Sprite.h"
¿Te funciona? Es que a simple vista no se ven problemas, lo unico que en el "D3DXCreateTextureFromFileEx" en vez de poner "D3DUSAGE_RENDERTARGET" pon el valor "0".
Buscando algun ejemplo sobre la lectura de texturas he encontrado una pequeña joya que fijo que te ayuda: http://www.codigoverde.com/Space%20Invaders%206.htm, ademas me parece que esta web es de un usuario de stratos o por lo menos algunos de sus juegos estan en ella.
Ya me funciona, gracias a todos.
Cita de: "senior wapo"
b) Opengl fuerza todo a estar presente mediante fallback software si no fuese posible por hard. DirectX no obliga a nada ya que entiende que una implementación software podría ser poco util. Lo suyo es que la aplicación consulte y utilice solo las funciones implementadas por hard si requiere velocidad. (familia GetCaps en DX y GetInteger()+bases de datos basadas en vendor string en OpenGL).
No tenía noticias de que OpenGL de soporte a todo ( todo ? ) por fallback software. Tienes algun link de esto ? ( icono - curiosidad )
Cita de: "senior wapo"
c) Soportase OpenGL o no, era la época negra de la programación OpenGL en windows (y si me apuras de DX también, pero de OpenGL mejor ni hablar). Dejémoslo correr :D
No voy a entrar en los problemas que pudiera haber con Win o drivers. Pero vamos... que un GRUPO de PROFESIONALES que desarrollan hardware, ofrezcan soporte para alpha blending que es más complicado de desarrollar y no para alpha test que es más simple...
es como si alguien te dice que sabe hacer carros pero no ruedas... ...i si le sumas lo poco sobrados q por la época ivan de hard para hacer blend... pffff
Cita de: "senior wapo"
d) Por software, alpha test es potencialmente más rápido al ser simplemente una comparación. Blending implica hacer una mezcla de color (por ejemplo una media ponderada mediante alpha de la textura).
alpha test: if (framebuffer[x,y].alpha > texel.alpha) then framebuffer[x,y] = texel
blending: framebuffer[x,y].pixel = framebuffer[x,y].pixel * (1-texel.alpha) + texel.pixel * texel.alpha
ohhhh :wink: permiteme hacer un par de matices y un añadido.
Matices
Por software y por hardware, alpha test es realmente más rapido.
El alphablending dispone de numerosas combinaciones de mezcla y algunas un tanto complejas. O lo que es lo mismo, muchisimo más tiempo de proceso.
Añadido
Te ha faltado agregar el pipeline donde se encuentran los dos procesos.
... alpha test --> stencil test --> depth buffer test --> blending ...
alguien se ha preguntado alguna vez pq con un blending no aditivo debe realizar una ordenación de los elementos de back to top ?
Podemos estar deacuerdo en definir el que alpha test realiza un test para eliminar un pixel ? ( lo que pedia MacBain )
Podemos estar deacuerto en definir al Blending ( no blending test xD ) como mezclar pixeles ?
Como vendemos a alguien quiere hacer un universo con 300 rectanglos huecos, que use blending, .( tengo problemas raros !!! ) ...que trace la distancia de cada rectangulo para después ordenarlo... y que encima se compre una tarjeta de 140€... pq cuando unos pocos de rectangulos cubren toda la ventana los frames se le tiran abajo... ...pero claro, saldrá alguien y le dirá... Frustrum Culling!!! o culquier otra técnica del estilo... ...lo implementará y seguirá exactamente igual... ... pq usando esa o otra técnica a el trozo de pipeline que he puesto le llegarán exactamente la misma cantidad de putos pixeles...
Cita de: "zupervaca"Veamos ¿por que tengo que defender lo que dice la documentacion de direct3d?
No hombre no, no debes defender la documentación del direct3D. Debes defender tus palabras. Por lo pronto, recomendar el alphablending para hacer un colorkey.
Algunas citas.
"...ademas este es el sistema de toda la vida para crear transparencias teniendo un canal alfa. " ( refiriendote al alpha blending )"
"...ademas es como se ha hecho toda la vida, espero que te haya quedado claro y si no busca en google como hacer mascara de color con estas dos instrucciones en google." ( refiriendote a usar máscaras )
"Ni tu ni nadie por la sencilla razon de que el alpha testing descarta pixels con el problema de que no suaviza los bordes como hace el alpha blending"
Este de que el blending suaviza bordes es brutal !!! más caracteristicas para el blending !!!! ole ole !!! a tomaaaaaar pol cuuuuulo el Full-Screen Antialiasiingggg (entonación cálico )
Ponte una imagen cuadrada blanca (255,255,255), pon un rombo negro(0,0,0) dentro. Los pixeles blancos pon el alpha a 0, y los negros a 1. y ahora quiero q desaparezcan los blacos o negros con blending... y que se suavicen el brodes !!!!
La comunidad del alpha test te agradece que reconozcas que sirve para descartar pixels ( por alpha ).
[quote="[EX3]"Y digo yo, no es un poco estupida toda esta cuestion que
estas formando con el AlphaTest?[/quote]
Si en algo que conozco veo que sueltan una de estas, que debo pensar de lo que pone la gente sobre temas que desconozco ? por eso para mi es importante.
[quote="[EX3]No has pensado que luego McBain querra aplicar AlphaBlending? Para que vas a implementar AlphaTest y Blending cuando con Blending cubres las dos necesidades?[/quote]
Que cada uno emplee lo que quiera, pero que sepa que esta haciendo exactamente en cada momento. Para lo demás, me remito a el universo de los 300 rectangulos huecos.
[quote="[EX3]Ahi tienes la 'logica y razon' de por que se usa y recomienda Blending y no AlphaTest en la mayoria de tutoriales de toda la red.[/quote]
Aquí entramos en lo del criterio propio, donde la mayoria, no es sinónimo de nada. ( Sin ser comparable a lo que estamos hablando, Hitler llego al poder através de las elecciones. )
P.D: Por cierto, googleando un poco me encotre con esto...
http://www.stratos-ad.com/forums2/viewtopic.php?p=18410&sid=605c73a582a25e25cdaf0b6d508846b0
curioso no ?
Jare
CitarPuedes creerme, yo sí he tenido en mis manos las especificaciones de la Virge bit a bit y registro a registro. Y sobre todo, he trabajado con ella.
Te repito que sin dudar de tu palabra, me cuesta creerlo, primero se anda después se corre, primero fue el alphatest, después el alphablend. Lástima que no tengamos las Specs. No estaría soportado por hard y tubieran el problema X con ella ?
Jare
CitarAlpha Test en general es más rápido de ejecutar que un blend, pero alpha test en software será más lento que blend por hardware. :P
Claro, pero los dos en las mismas condiciones (soft/hard) no hay color.
Jare
CitarComo dice zuper, el test genera bordes "duros" que pueden quedar muy feos
Claro coño, pero con el blending se puede llegar al mismo punto, no es esa la solucion, no crees ?
Citar
pero el blending tiene su propio conjunto de problemas: ordenación y multipass son los más clásicos.
Y alguno más... entonces mejor evitarlo cuando no sea necesario ? :P
Citar
El tercer problema clásico (y el que más quebraderos de cabeza me dio en su momento) es el hecho de que con blending, los texel transparentes también escriben en el ZBuffer.
Por arriba he puesto el pipeline. Los texels trasparentes se escribian pq no eran transparentes.
Citar
Hoy en día lo del ZBuffer se suele resolver activando blending Y testing a la vez, aunque suelen quedar unas babas un poco feas alrededor del gráfico.
Y que hacemos para suavizar las babas... otro blending ? :P o la tecnica q corresponda ?
P.D: Sorry por el flood de msgs
CitarEste de que el blending suaviza bordes es brutal !!! más caracteristicas para el blending !!!! ole ole !!! a tomaaaaaar pol cuuuuulo el Full-Screen Antialiasiingggg (entonación cálico )
Esto demuestra que no sabes de lo que hablas.
Dejadlo, por vuestro bien.
No la lieis.
Con texels alpha soportas bordes suavizados (antialias) porque la transparencia tiene 256 grados en lugar de 2 (si/no) como pasaría con colorkey puro o alpha test. Con bordes nos referimos al contenido de la imagen de textura, no al borde del poligono, que es donde si que necesitas antialias de escena. Un valor alpha se puede considerar como el % del area del pixel que se ve afectada por la parte RGB, y por tanto el otro % de superficie hasta sumar 100% estaría mostrando el color RGB del fondo. Como el aspecto dentado se produce cuando pintamos un pixel que matematicamente no cubririamos realmente por entero, podemos usar alpha para simular un pintado parcial (subpixel). Mismamento, usando como valor alpha el error acumulado (o su inverso) de ese pixel en el algoritmo bresenham que pinta el borde. En el fondo no es más que una cuestión semántica.
<inciso>
Aun asi, y poniendonos pedantes por aquello de rizar el rizo, teóricamente puedes suavizar bordes poligonales aprovechando detección de bordes de silueta (como los usados para shadow volumes) y superponiendo a cada borde de poligono que contribuye a silueta un quad difuminado de ancho 2-3 pixeles paralelo a la pantalla y a modo de línea trazando el borde. Vamos, usar poligonos con degradados alpha para pintar wireframes sobre la silueta del modelo como si fuese un modelo de Geometry Wars.
Ejemplo OpenGL (formato MacOSX creo) de lineas con antialias (usando una textura de degradado alpha para los quads que trazan las lineas):
http://homepage.mac.com/arekkusu/SW/shootthings.html y pulsad el link glAARG</fin de inciso>
La especificación OpenGL viene en el libro rojo en la web de www.opengl.org. Eso si, en inglés.
...
Cita de: "MAMestre"]Cita de: "[EX3"]No has pensado que luego McBain querra aplicar AlphaBlending? Para que vas a implementar AlphaTest y Blending cuando con Blending cubres las dos necesidades?
Que cada uno emplee lo que quiera, pero que sepa que esta haciendo exactamente en cada momento. Para lo demás, me remito a el universo de los 300 rectangulos huecos.
Sigo viendo una soberana estupidez usar dos metodos cuando uno te cubre ambas necesidades: colorkey y alphablending.
Cita de: "MAMestre"]Aquí entramos en lo del criterio propio, donde la mayoria, no es sinónimo de nada. ( Sin ser comparable a lo que estamos hablando, Hitler llego al poder através de las elecciones. )
Chico, esto y nada es lo mismo. Hacer comparaciones como esa que acabas de hacer son simples signos de falta de recursos para seguir una discursion.
Cita de: "MAMestre"]P.D: Por cierto, googleando un poco me encotre con esto...
http://www.stratos-ad.com/forums2/viewtopic.php?p=18410&sid=605c73a582a25e25cdaf0b6d508846b0
curioso no ?
Que quieres que te diga, ahi solo veo dos cosas: lo mal que escribia en los foros antaño en comparacion de ahora :lol: y mis escasos conocimientos de
Direct3D8 hace 3 años, camino de 4 ya, cuando aun estaba programando integramente sobre
DirectDraw7 donde la filosofia de programacion era totalmente distinta a
Direct3D8 radicalmente (y hablo de DDraw7 y no sobre lo poco que toque D3D7 que aun asi variaba ligeramente) por que por lo demas seguimos en lo mismo, acabe usando el metodo de
blending en la
dx_lib32 y no el
alphatest:
D3DDevice.SetRenderState D3DRS_SRCBLEND, D3DBLEND_SRCALPHA
D3DDevice.SetRenderState D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA
D3DDevice.SetTextureStageState 0, D3DTSS_ALPHAOP, D3DTOP_MODULATETe vuelvo a deicr, es tonteria usar dos metodos cuando uno te sirve para todo y aunque tu no lo compartas el resto del mundo si ;)
Salu2...
P.D.: El
AlphaTest lo tuve una temporada usando en algunas de las primeras versiones de la
dx_lib32, pero visto que usarla o no, no afectaba en nada al resultado final, lo acabe retirando del codigo dejando al
Blending a secas.
Cita de: "MAMestre"]Te repito que sin dudar de tu palabra, me cuesta creerlo, primero se anda después se corre, primero fue el alphatest, después el alphablend. Lástima que no tengamos las Specs.
La memoria me falla respecto a algunas de las lindezas de la S3 Virge. En cualquier caso, solo la mencioné como ejemplo de que las cosas a veces no son tan sencillas y ortogonales como nos gustaría o nos parecería lógico. La Virge a día de hoy es irrelevante.
Respecto a la discusión, lo mejor es conocer ambas técnicas, saber cuándo usar una u otra, los problemas que puede dar cada una en diferentes situaciones, y las posibles soluciones o hacks disponibles. Sería más util para todos si cada uno dedica esfuerzos a aportar información en lugar de desacreditar la que aportan los demás. En esa línea, otro dato interesante: en la mayoría de las tarjetas anteriores a las ATI 1x00 y NVidia 7x00, el alphatesting no recibe los beneficios del Full Screen Antialiasing. Si quereis ver lo que sucede, probad el King Kong de Ubisoft, que usa alphatesting para las grandes masas de vegetación, y comparad los resultados con FSAA en una 6600 y una 7800... no hay color. En la 6600 el baile de pixeles es un horror. :P
Es como decir sobre los gametos gemetiles... (ya os pasaré el video por Off-Topic)
Cita de: "JtR666"Es como decir sobre los gametos gemetiles... (ya os pasaré el video por Off-Topic)
Leyendo tus comentarios he intentado ignorarlos porque nunca me aportan nada positivo, pero desde hace algun tiempo me viene rondando una pregunta cada vez que finalizo de leer una de tus perlas: ¿de que cueva has salido? ¿no estabas mas agusto en ella?
Cita de: "Ruben"¿de que cueva has salido? ¿no estabas mas agusto en ella?
Ruben, lo pone bien claro bajo su avatar: "En el rincón más profundo de Donosti"
PD: Perdón por sumarme al offtopic, pero visto que el hilo ya hace días que está perdido.. :D
Cita de: "MAMestre"]Frustrum Culling!!!
¡¡¡Expeliarmus!!!
MA]Mestre queda expulsado de la casa :D
Cita de: "seryu"MA]Mestre queda expulsado de la casa :D
Ok, me las piro. Uno menos.
Cita de: "zupervaca"
Editado: No habia leido todos los posts, para ses con el rollu del test que creo que no sabe muy bien lo que esta diciendo, veamos, el test se puede ejecutar muy rapido pero lo que es el jnz, jz, etc NO, mas rapido que este sistema es tener un bitmap de color y otro bitmap de mascara, despues con un AND y un OR se hace todo lo necesario para pintar una imagen transparente, eso si es mas rapido que el TEST y su SALTO, ademas es como se ha hecho toda la vida, espero que te haya quedado claro y si no busca en google como hacer mascara de color con estas dos instrucciones en google.
No es cierto. Estas asumiendo que la memoria de video es igual de rapida que la memoria del sistema.
En el caso de sprite[] AND mascara[] OR videoram[] ; la lectura de videoram[] es más lenta y hace que ese metodo no sea más rapido.
En la epoca MSDOS era una locura leer de la memoria de video.
En el caso de "test y salto" la penalización del salto se puede minimizar rediseñando el bucle que "pinta", alineando el codigo más probable donde se salta a 16bytes, minimizando los saltos. O como ya han apuntado por ahi: codificando los sprites de tal forma que el dato de transparencia(el supuesto 0) lo ampliemos para que nos indique cuantos pixeles saltar...
Saludos
Y dale, buscate como funciona el metodo de AND y OR por que con estas dos instrucciones haces lo mismo que con el TEST, su SALTO y el MOV a la memoria de video.
Me parece que lo que no entendeis es que con el AND y el OR se realiza todo.
CitarO como ya han apuntado por ahi: codificando los sprites de tal forma que el dato de transparencia(el supuesto 0) lo ampliemos para que nos indique cuantos pixeles saltar
Otra vez mezclando churros con merinas, se habla de dibujar imagenes sin compresion RLE.
Citaralineando el codigo más probable donde se salta a 16bytes, minimizando los saltos
¿Y que te piensas que el AND y el OR solo trabajan con un 1bit?
Cita de: "zupervaca"Y dale, buscate como funciona el metodo de AND y OR por que con estas dos instrucciones haces lo mismo que con el TEST, su SALTO y el MOV a la memoria de video.
Me parece que lo que no entendeis es que con el AND y el OR se realiza todo.
CitarO como ya han apuntado por ahi: codificando los sprites de tal forma que el dato de transparencia(el supuesto 0) lo ampliemos para que nos indique cuantos pixeles saltar
Otra vez mezclando churros con merinas, se habla de dibujar imagenes sin compresion RLE.
Citaralineando el codigo más probable donde se salta a 16bytes, minimizando los saltos
¿Y que te piensas que el AND y el OR solo trabajan con un 1bit?
Me parece que no me has interpretado bien.
1. El metodo AND y OR es muy viejo no hace falta que lo busque . Lo que digo es que ese metodo necesita leer de la memoria de video y eso es LENTO.
2. Lo que te he puesto no es RLE http://en.wikipedia.org/wiki/Run-length_encoding. Me refiero a guardar lo que le SUMAS al puntero destino cuando aparece algo transparente; ya que la mayoria de sprites son asi: pixeles - x pixeles transparences(normalmente hasta la siguiente linea) - pixels - idem - idem - etc.
Y no tengo ganas de dibujar algo más explicativo. Como dices, la compresión no viene a cuento.
3. Con lo de alinear el codigo me refiero a esto
ALIGN 16
saltamos:
;codigo alineado a 16 bytes :)
....
je saltamos
esa alineación minimiza muchisimo el gasto de un salto.
En fin, todo esto asumiendo el maravilloso mundo del msdos y las vga de antes; Como nota historica.
- Precisamente RLE es eso. (Run-Length econding=RLE).
- El alinear a 16 bytes acelera los saltos y todas las demas instrucciones, hace tiempo puse un post de una rutina hecha en c igual que la memcpy que da el c estandar en la cual alineaba los bytes, copiaba el mayor rango posible con el mayor tipo de dato y luego copiaba los bytes sueltos sin alinear.
Lo que está diciendo nostromo es que con TEST lo que compruebas es memoria de origen (sprite) solamente pero con mascaras y operaciones AND y OR necesitas leer obligatoriamente memoria destino para realizar la operación (que si resulta ser VRAM puede ser lentisima forzando a la CPU a quedarse parada esperando y desperdiciando ciclos).
Si tanto la superficie origen (sprite) como el buffer destino son superficies de sistema pues evidentemente no hay stalls y si que te puede rentar no usar comparaciones+saltos (el rle esta prohibido no?).
Y digo yo a cuento de que viene hablar de esto hoy en dia. Tema para mañana: generar el scroll en el amstrad cpc reprogramando el CRTC :P
No he leído muy detenidamente todas las respuestas pero mi voto va a favor del uso de blend en lugar de test, entre otras razones porque el blend se calcula después del filtrado con lo que quedan unos bordes suavizados, y Direct3D no se creó para hacer juegos de spectrum.
Como dice la ayuda del directx, "The most common use for alpha testing is to improve performance when rasterizing objects that are nearly transparent". Por lo que lo ideal tal vez sea usar las dos formas a la vez, usando el test de forma añadida para aumentar rendimiento sin ser imprescindible que la tarjeta lo soporte.
Me parece que la Riva TNT tampoco soportaba alpha test y sí blending. De todos modos yo creo que hoy día todas las tarjetas sí lo soportarán.
En lo del AND y el OR ya me he perdido.
Cita de: "marcode"En lo del AND y el OR ya me he perdido.
No me extraña, yo no lo he visto en uso desde la época de los 8bits :)
Basicamente consiste en que por cada sprite tienes otro equivalente con cada pixel transparente del sprite original a 1 en todos sus bits y con cada pixel solido a 0 todos sus bits de color. Una especie de negativo.
Si tu combinas esa mascara con el fondo de la pantalla usando la operacion AND, te quedará el fondo que habia en los pixeles con mascara solida =todos los bits a 1 (lo transparente) y te quedarán pixeles negros (0) en donde la mascara estaba con los bits a 0 (solido). Habrás pintado el sprite original con todos sus pixeles solidos a 0 en lugar de coloreados.
A continuación pintas encima el sprite normal usando la operacion OR o XOR, y no se te distorsionará el color porque tienes garantizado que las partes sólidas estan a 0 en el destino (por la operación AND con la máscara).
for y=0 to alto
for x=1 to ancho
destino[x,y] = ( destino[x,y] AND mascara[x,y] ) OR sprite[x,y]
endfor
endfor
La ventaja era poder usar todos los colores y no perder el que usas para colorkey. Ahora te da igual pero cuando el ordenador representaba solo 4 o 16 colores distintos simultaneos pues venia bien.
En arquitecturas donde la CPU usa memoria de sistema para el video y la vuelca a pedal a la salida de video (mediante interrupciones + pokes a puertos) pues es rentable en velocidad tambien. Quien dice que lo vuelca la CPU dice un controlador especial, el caso es que usas memoria de sistema.