No sé si hay un nombre, pero esto parece ser algo que harías para conservar la memoria.
Primero, un mosaico básico tiene una resolución muy baja, solo unos pocos píxeles de ancho. Pero cuando se procesan, se amplían 2x, 3x, 4x, etc. y son mucho más "bloqueados" en la pantalla.
A continuación, los juegos más antiguos tendrán un bloque de memoria dedicado a la visualización de la pantalla; lo que hay en esa memoria es lo que se muestra en la pantalla. Tenga en cuenta que la memoria es MUY escasa en las plataformas más antiguas, por lo que, como desarrollador, desea ahorrar todo lo que pueda.
Entonces, en lugar de colocar sus mosaicos en un espacio de memoria separado, simplemente haga que formen parte de la memoria de su pantalla, ahorrando así un poco. Y el artefacto de esto, por supuesto, es que aparecen en la pantalla.
Desde la perspectiva del acceso a la memoria, al código no le importa si la memoria a la que se accede se usa para la memoria de pantalla o el almacenamiento variable. Básicamente, la administración de memoria en juegos antiguos era muy simple y solo había un bloque de memoria disponible. No había GPU, por lo que no tenía idea de procesadores y memoria separados para la programación frente a la pantalla.
Para tener una idea de cuán apretada podría estar la memoria programando juegos anteriores, aquí hay una cita de un artículo de 1983 sobre la programación de las computadoras Atari y VIC, "La pantalla de súper alta resolución de Atari (y los modos GTIA de 16 colores) usa casi 8K de RAM." Parece muy poco, pero tenga en cuenta que la computadora tal vez solo tenía 48K de memoria, muchas de las cuales fueron ocupadas por otras cosas además del juego.