REDPILL Game Creator v0.9.37 y 0.9.38
Mostrar Mensajes
76
Desarrollo / Re:Mapas en c64 con scroll
« en: Mayo 04, 2017, 16:21:37 »Um, pero esa fila inicial a pintar, sólo hay que calcularla 1 vez por cada refresco, no es que quite demasiado trabajo...Lo que no me queda tan claro es si en fila[mapx], lo que hay es un índice al tile (1 byte), o un puntero al tile (2 bytes)Ten en cuenta que tienes que acceder a 40 filas en cada frame. Puedes calcular la dirección de la primera y luego ir sumando 40 bytes e ir actualizando los 2 bytes del puntero. Es muy fácil, pero son calculillos que se hacen 40 veces por frame. Si precalculas, gastas 256 bytes de buffer para los punteros (128 filas) pero te ahorras rastertime en cada frame. Es simplemente una optimización para ensamblador.
No estoy fijando el tamaño del tile.El tamaño podría ser cualquiera.(8x8,4x4,5x5).Uso 5x5 como referencia porque cubre toda la pantalla.A nivel conceptual no lo hay. Yo lo decía por la implementación en ensamblador, el ser un numero potencia de 2 te facilita la vida. Pero igual hay una forma elegante de hacerlo con 5 tambien.
Yo no veo, por ahora, ventaja en que el tamaño del tile sea múltiplo de 2.Igual lo veo después.
Sobre la COLORRAM, la ventaja que da tener 1 color por tile, es muy muy poca, incluso con el método de cadaver.Me explico:
Con un scroll de 2 pixeles, hay que repintar 1 de cada 4 frames.En el frame que hay que repintar, y usando el metodo de cadaver, lo que hay que recalcular es sólo la nueva fila o columna, o ambas, que entran en pantalla.Del resto, se hace shift, por lo que da lo mismo si se hace shift de colores individuales, o bloques de color.
Es decir, que la limitación de 1 color por tile, permite que un proceso que afecta a , como máximo, (40+24)/40*25 = 0.06 (6%) de los caracteres, en 1 de cada 4 frames, sea más rápido..
El usar 1 color por tile, hace más rápido el primer pintado completo de pantalla.A partir de ahi,si haces shifting, no estás ganando demasiado.
No te acabo de seguir. Si tengo un color único por tile, efectivamente me ahorro escribir en los extremos 1 de cada 4 frames. Pero es que además al hacer el shifting solo hace tocar una columna de cada cuatro...
Quiero decir si tengo 3 tiles de diferentes colores (12 chars) y hago shift a la derecha:
RRRRGGGGBBBB
RRRGGGGBBBBY
Solo tengo que tocar 3 chars, no?
Si, por otro lado, el cálculo de colores se almacena en un doble buffer, del cual luego copias a memoria de color (que es lo que quisiera probar), da lo mismo: lo que ralentiza es el cálculo del doble buffer,y ni siquiera eso, porque los offsets a la memoria de color de tiles, son los mismos que los offsets a los caracteres de tiles, asi que no se hacen más cálculos.Esto también es así en el método de cadaver: a la vez que se calcula qué caracteres nuevos hay en pantalla, con los mismos offsets (dividido entre 2), tienes el color de esos caracteres.Yo esa parte la hice diferente... precalculo la fila o columna nueva de color en un array, y luego cuando estoy off-screen copio del array a la zona correspondiente de COLORRAM.
Sobre si usa mucha memoria...Puede usar la mitad de memoria que los tiles (2 colores por byte), más 1K de doble buffer.En el mismo metodo de cadaver, donde hay 192 tiles de 4x4, usaria 3072 bytes de memoria de caracteres, y la mitad (1536 bytes) para memoria de color...No me parece tanto para lo que se gana..Tienes razón. Yo creo que es más una cuestión de rastertime, como te decía si consigues que te calcule todo bien a 25 hz (double buffer) te puede quedar una chulada. Por supuesto hay juegos que tienen tiles de 2x2, y queda super colorista. Si no tienes cálculos complejos (multiplexer, etc) y te cabe en el raster, genial.
