Color transparente

[Mars Attacks]

Mestre"]Frustrum Culling!!!

¡¡¡Expeliarmus!!!

[seryu]

MA]Mestre queda expulsado de la casa  :D

[MA]Mestre]

MA]Mestre queda expulsado de la casa  :D

Ok, me las piro. Uno menos.

[nostromo]

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

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

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

Otra vez mezclando churros con merinas, se habla de dibujar imagenes sin compresion RLE.

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

[nostromo]

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.

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

Otra vez mezclando churros con merinas, se habla de dibujar imagenes sin compresion RLE.

alineando 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

Código [Seleccionar] Expand


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.

[zupervaca]

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

[senior wapo]

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

[marcode]

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.

[senior wapo]

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

Código [Seleccionar] Expand


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.