Mensajepor na_th_an » Mar, 10 Dic 2013, 09:09
$this->bbcode_second_pass_quote('radastan', 'E')s que realmente un sprite y un tile no tienen distinción. La diferencia de un sprite es que se mueve, pero la rutina de impresión es la misma, lo único que cambia es que se añaden dos rutinas más para recoger y reponer el fondo (en caso de haber uno y que se quiera mantener).
Pero si, tomo nota del de 16x24 y también uno de 24x32.
A ver si animo a la gente a poner personajes grandes y a color en pantalla.
EDITADO: Ala, ya están metidas las dos.
Genial
En nuestro viejo motor, sí había distinción entre tiles y sprites. En los sprites había dos cosas que podían o no tomarse en cuenta: una era que los caracteres a "0" no se imprimían, viéndose el fondo en vez del caracter correspondiente. Así, si el sprite tenía caracteres completamente vacíos, se disimulaba un poco el marco negro. Otra era que el paper del fondo podía prevalecer sobre el paper del sprite, o que el sprite sólo definiese "INK" y simplemente tomase el "PAPER" que hubiese en el fondo, lo que a veces también ayudaba a enmascarar la falta de máscara, por decirlo de algún modo. Esto lo usamos en fourspriter, por ejemplo.
Aparte de eso, el sprite necesita un método para restaurar el fondo. Con un sencillo buffer donde almacenarlo basta.
Por eso cuando hemos hecho cosas así (la subacolib, por ejemplo) hemos automatizado todo el manejo de sprites. El usuario sólo se tiene que encargar de poner sus valores en una estructura de sprites (como en las máquinas con sprites HW) y es el motor quien se encarga de todo (restaurar fondo, tomar nuevo fondo, pintar sprite) en el momento justo para que no haya parpadeos (en el caso de Subaco, los juegos se fijan a 25fps, se espera hasta el borde inferior, y se trabaja en el tiempo en el que la ULA está pintando ambos bordes).