Karoshi MSX Community
05 de Julio de 2021, 07:33:04 pm *
Bienvenido(a), Visitante. Por favor, ingresa o regístrate.

Ingresar con nombre de usuario, contraseña y duración de la sesión
Noticias:
 
   Inicio   Ayuda Buscar Ingresar Registrarse  
Páginas: 1 [2]
  Imprimir  
Autor Tema: ¿Es posible que sea mas rápido escribir RLE que RAW en VRAM?  (Leído 9366 veces)
0 Usuarios y 1 Visitante están viendo este tema.
aorante
Karoshi Maniac
****
Mensajes: 451


nuTella Power!


WWW Email
« Respuesta #15 : 21 de Enero de 2012, 10:13:19 pm »

Si, la última optimización mejora bastante los tiempos y permite un mayor rango de archivos candidatos a RLE.

supongo que no digo nada nuevo para los que ya lleváis tiempo peleando en estas cosas, pero quizás pueda servir los que no conocen mucho el tema.
En el caso de una pantalla de screen2/4, si se usa para volcar un tileset (patrones+colores), o un gráfico, si te curras el orden de los tiles por colores y que estos estén arreglados (el fondo y la tinta seguidos), una compresión RLE solo en los datos de los colores se puede ganar mucho, mientras que utilizarlo en los patrones puede que incluso ocupe más. Los conversores no suelen darte los datos ordenados, y hay que pasar unas horas arreglandolo con la tecnica "handmade"  Grin

ahí queda eso!  Cheesy
En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
Dioniso
Visitante
« Respuesta #16 : 21 de Enero de 2012, 11:05:36 pm »

Sí, efectivamente. O cosas como tener el cero y el uno como color negro, sin necesitar transparencias de ningún tipo. Algo como:

$06,$06,$16,$06,$06,$16,$06,$06,$16,$06,$06,$16,$06,$06,$16,$06,$06,$16,$06,$06,$16

serían 28 bytes en RLE y 21 en RAW. Mientras que las TILES se podrían optimizar a:

$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16,$16

y serían 2 bytes en RLE  laugh

Pero quizá no merezca la pena meterse en tanta "optimización" si hablamos de cargar los tres bancos de patrones. La diferencia de velocidad sería despreciable.
En línea
aorante
Karoshi Maniac
****
Mensajes: 451


nuTella Power!


WWW Email
« Respuesta #17 : 24 de Enero de 2012, 08:56:38 pm »

una duda...

como funciona el RLE?

es correcto lo siguiente?

1er byte - número repeticiones (de 1 a 255). Si es 0 es fin.
2do byte - valor

En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
Mortimer
Karoshi Lover
***
Mensajes: 216


WWW
« Respuesta #18 : 24 de Enero de 2012, 10:12:36 pm »

Sí, sería correcto, no hay forma 'oficial' de hacerlo, así que verás varias implementaciones con la misma idea básica, y quizás algunos posibles refinamientos como por ejemplo para intentar optimizar el tamaño de los casos sin repetición.
En línea
j4mk3
Karoshi Maniac
****
Mensajes: 376


MSx Powa!


WWW Email
« Respuesta #19 : 24 de Enero de 2012, 11:44:14 pm »

...se puede ganar mucho, mientras que utilizarlo en los patrones puede que incluso ocupe más. Los conversores no suelen darte los datos ordenados, y hay que pasar unas horas arreglandolo con la tecnica "handmade"  Grin

Y lo que costó en el Hans...la de dios y horas con el nMSXTiles. verdad Aorante? Smiley ...moviendo, girando..cambiando colores. La experiencia fue muy util para que Pentacour refinara la aplicación y pusiera nuevas opciones destinadas a este tipo de faenitas.
En Hans Adventure, el volcado a VRAM es directo desde RLE, pero creo q no optimizado. En el gráfico de portada tube que poner 3 parones para entrar en la interrupción y que no parara la música. Así que a groso modo...tardo 3 frames en hacerlo entero. Pero ya digo que no está nada optimizado ni con buffer en Ram ni nada.

Interesante Hilo y aquí mi experiencia. Wink
En línea

---  G Fan  ---  Galious & Gradius  & G Boys   ---
--- Play HANS' ADVENTURE, STAN, THE DREAMER & BITLOGIC ---
theNestruo
Karoshi Lover
***
Mensajes: 236


Email
« Respuesta #20 : 25 de Enero de 2012, 12:25:19 am »

es correcto lo siguiente?
1er byte - número repeticiones (de 1 a 255). Si es 0 es fin.
2do byte - valor
Una variante típica es que algún bit del primer byte te permita alternar entre "vienen n repeticiones" o "vienen n bytes sin repetición" para los fragmentos en los que viene una buena mezcolaina de bytes.
Ejemplo chorra (considero el primer bit 0 y 1 significando repeticiones y fragmento exacto):
Código:
84 10   04 14 6F 3D 41   82 9F   00
se traduciría a:
Código:
10 10 10 10  14 6F 3D 41  9F 9F

Luego tienes variantes de todo tipo, según las necesidades específicas que tengas...
Por ejemplo, puedes hacer repeticiones de bloques ("repetir 7 veces la siguiente secuencia de 4 bytes").
Otro ejemplo: en mi época de GP32, para pintar sprites por software, lo que hice fue un pseudo-RLE en el que si el primer bit era 0 indicaba hueco a saltar y 1 indicaba número de bytes a copiar (es decir, comprimía las repeticiones de bytes transparentes). Ahorraba ir haciendo un if por cada byte y los fragmentos a copiar se volcaban con un memcpy().

Implementar RLE es como cocinar una tortilla: lo básico es el huevo batido; luego cada uno le añade lo que más le guste Grin
En línea

theNestruo."Old BASIC programmers never die; they GOSUB but never RETURN."
aorante
Karoshi Maniac
****
Mensajes: 451


nuTella Power!


WWW Email
« Respuesta #21 : 25 de Enero de 2012, 10:13:55 am »

Gracias theNestruo!

estoy incluyendo en la tool que estoy programando la compresión de los datos con RLE y la opción primera me parece interesante. Estoy pensando en poner las dos formas: la sencilla que preguntaba (qe va muy bien para los colores) y la que tu dices.

Saludos!
En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
aorante
Karoshi Maniac
****
Mensajes: 451


nuTella Power!


WWW Email
« Respuesta #22 : 25 de Enero de 2012, 08:51:48 pm »

he programado esta rutina para descomprimir RLE a VRAM (1ºB:1-255=repeticion,0=fin ; 2ºB:valor)
Funciona, pero tengo la duda con lo de la escritura a VRAM en los TMS99xx. He puesto 2 "nops", pero no se si sobran o faltan.
¿podéis echarme una mano en este tema?
y
¿se puede optimizar?


Código:
; descompresor RLE a VRAM
unRLE2VR:
  ; direccion de VRAM (DE)
  in A,($99)
  di
  ld A,E   
  out ($99),A
  ld A,D       
  add A,$40
  out ($99),A
  ei
 
getCMD: ;mira byte de codigo, 1-255 repeticion   
  ld A,[HL]
  cp 0  ;si es 0 es fin
  ret Z ;sale de la funcion
 
  inc HL 
  ld B,A ;numero de repeticiones
   
  ld A,[HL] ;recoge el valor
 
RLE_bucle:
  out ($98),A
  nop
  nop
  djnz RLE_bucle
 
  inc HL
  jr getCMD
En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
Mortimer
Karoshi Lover
***
Mensajes: 216


WWW
« Respuesta #23 : 25 de Enero de 2012, 09:18:58 pm »

Pues si consideramos que 28 son los mínimos ciclos seguros, te sobraría un NOP en el bucle, porque ya quedaría

Código:
RLE_bucle:
  out ($98),A    ; 12 ciclos
  nop         ; 5
  djnz RLE_bucle ; 14 si se repite

Total 31

Y apurando un pelín más
Código:
RLE_bucle:
  OUT ($98),A    ; 12 ciclos
  DEC B        ; 5
  JP NZ,RLE_bucle  ; 11

Total 28!

Y en cuanto al resto, cambia CP 0 por AND A y ahorrarás 3 ciclos, y también el JR final, puedes cambiarlo por un JP y ahorras 2 ciclos más por iteración.
« Última modificación: 26 de Enero de 2012, 08:39:47 am por Mortimer » En línea
aorante
Karoshi Maniac
****
Mensajes: 451


nuTella Power!


WWW Email
« Respuesta #24 : 27 de Enero de 2012, 12:55:27 pm »

gracias por la ayuda Mortimer!
En línea

--------------------------------- ------ ----- --- -- -
aorante/303bcn
http://aorante.blogspot.com
http://twitter.com/#!/aorante
http://303bcn.wordpress.com/
--------------------------------- ------ ----- --- -- -
Páginas: 1 [2]
  Imprimir  
 
Ir a:  

Impulsado por MySQL Impulsado por PHP Powered by SMF 1.1.21 | SMF © 2013, Simple Machines XHTML 1.0 válido! CSS válido!