Con 300 bytes se puede agrandar la ventana de descompresión (el número máximo de bytes hacia atrás desde donde se puede copiar un patrón), pero creo que lo mejor es usa un stream comprimido por cada pantalla que al terminar se resetea la ventana. Es que si no el código descompresor se hace más complicado y más largo al tener que descomprimir desde el principio e implementar un buffer circular. Aunque no sumaré esos 150 bytes como hacía hasta ahora.
De lo que me he dado cuenta es que el histograma de tiles no es para nada plano. El tile 0 es con mucha diferencia el más abundante y hay otros que apenas se usan. Estoy pensando en hacer una especie de huffman o shannon fano sin usar tablas, en el propio código. También tengo que sacar otra utilidad que reordene los tiles de mayor a menor frecuencia de aparición (y aplique esa reordenación al mapa).
Compresor de mapas
Moderador: na_th_an
-
antoniovillena
- Mensajes: 494
- Registrado: Jue, 24 Oct 2013, 15:52
Re: Compresor de mapas
Ten en cuenta que cada juego es de su padre y de su madre. Tengo juegos de perspectiva cenital en los que le tile más repetido no es el 0, por ponerte un ejemplo. También hay que tener en cuenta que el cambio de pantalla tiene que ser lo más rápido posible o el juego perderá jugabilidad por un tubo. Hay que tener estas cosas MUY en cuenta, a fin de acabo la jugabilidad es lo más importante, y cualquier cosa que la perjudique estará perjudicando el juego. Prefiero perder unas cuantas pantallas de mapeado que tener que esperar más en el cambio de pantalla, sobre todo en juegos de plataformas en los que hay veces que el cambio vertical se puede dar varias veces de forma muy seguida.
De hecho, creo que el punto más flojo actualmente está en la velocidad de cambio de pantalla, que supone un parón en la experiencia "jueguil", y eso que está lo más rápido que puede estar.
De hecho, creo que el punto más flojo actualmente está en la velocidad de cambio de pantalla, que supone un parón en la experiencia "jueguil", y eso que está lo más rápido que puede estar.
Como diría Rorshach: "Urm..."
-
antoniovillena
- Mensajes: 494
- Registrado: Jue, 24 Oct 2013, 15:52
Re: Compresor de mapas
$this->bbcode_second_pass_quote('na_th_an', 'T')en en cuenta que cada juego es de su padre y de su madre. Tengo juegos de perspectiva cenital en los que le tile más repetido no es el 0, por ponerte un ejemplo.
Lo tengo en cuenta, de hecho el primer paso antes de la compresión es reordenar los tiles de mayor a menor frecuencia. Lo curioso del asunto es que la frecuencia a medir no es la que aparece a la entrada, sino la de los literales a codificar, así que en un primer paso se hace una "simulación de compresión" suponiendo que todos los símbolos tienen el mismo número de bits. Pues bien en el dogmole la frecuencia ganadora no es el tile 0, sino el tile 1, pese a que en la entrada el tile 0 gana por abrumadora mayoría. Lo que ocurre es que todos esos "ceros" que tenía de ventaja se codifican como patrones, no como literales.
$this->bbcode_second_pass_quote('na_th_an', 'T')ambién hay que tener en cuenta que el cambio de pantalla tiene que ser lo más rápido posible o el juego perderá jugabilidad por un tubo. Hay que tener estas cosas MUY en cuenta, a fin de acabo la jugabilidad es lo más importante, y cualquier cosa que la perjudique estará perjudicando el juego. Prefiero perder unas cuantas pantallas de mapeado que tener que esperar más en el cambio de pantalla, sobre todo en juegos de plataformas en los que hay veces que el cambio vertical se puede dar varias veces de forma muy seguida.
Esto no es problema porque la cantidad de bytes a descomprimir es ínfima, sólo 150. Un algoritmo lento puede emplear 200 ciclos/byte, que en 150 bytes estamos hablando de 30.000 ciclos, que no es ni medio frame.
$this->bbcode_second_pass_quote('na_th_an', '
')De hecho, creo que el punto más flojo actualmente está en la velocidad de cambio de pantalla, que supone un parón en la experiencia "jueguil", y eso que está lo más rápido que puede estar.
Pues he estado viendo el código fuente y creo que el cuello de botella está en el scripting. Un cambio de pantalla tiene 3 subtareas: pintar el mapa, inicializar los enemigos/hotspots y ejecutar el scripting. La segunda tarea es la más corta con diferencia, y la primera tarea (pintar el mapa) es un tiempo constante que se puede acotar. En mi esqueleto lo he hecho en ensamblador y tarda 2 frames en ejecutarse; en la churrera está en C pero basándose en las librerías splib2, por lo que no creo que la rutina de pintado de la churrera lleve más de 3 frames. No he hecho ningún cálculo exacto de tiempo pero suponiendo que el cambio de pantalla actual tarda 20 frames, por fuerza los 17 frames que sobran se tienen que perder en el scripting. Es más, si estoy equivocado y la mayor parte del tiempo se pierde pintando, se deberían ver cambios graduales en la pantalla, y no lo que pasa ahora (casi todo el rato la pantalla estática y cambio repentino).
