Mojonia 3.0

$this->bbcode_second_pass_quote('antoniovillena', 'A') ver, la librería tal y como la estoy haciendo es para fondos estáticos, no valdría para scroll.

Al final se me está complicando la cosa. El problema es que la implementación 48k y 128k son tan distintas que tengo que agregar también el motor de tiles y el compresor de mapas a la librería. El funcionamiento de estos tres componentes (sprites, tiles y compresor) son similares, lo que se hace es escribir en ciertas zonas de memoria y el motor se encarga automáticamente de actualizar los elementos gráficos.

Ya tengo muy avanzado el engine. Lo que hago es detectar la máquina y en función de esta genero las rutinas de pintado. Hay 3 posibilidades:

• Si existe paginación 128k utilizo el método del shadow screen, puesto que es el que da mejores resultados (se pueden borrar/pintar unos 20 sprites cada frame)
• Luego compruebo si existe el puerto flotante ($FF), con el cual puedo hacer una sincronización muy precisa y pintar unos 8 sprites por pantalla sin parpadeo. Esto sería para Spectrum 48K originales, el 128K también tiene puerto flotante pero utilizaría el método de la shadow screen (tiene más prioridad).
• Por último si no existe nada de eso se sincroniza por interrupciones con lo que habrá parpadeo a partir de 5 o 6 sprites. Esto pasaría en el Inves 48K y cualquier otro clon de 48K que no implemente el puerto flotante.

Os dejo la demo para que la disfrutéis

Está de PM, como sugerencia si yo quisiera hacer un juego exclusivo 128K, poner un define para que no haya detección y ahorrar bytes

La detección y hacerlo ultra compatible, me parece ¡Fantástico!

Puede hacerse pero no tiene sentido. Primero porque los bytes que se ahorran son muy pocos y sólo nos ahorramos un poco de tiempo de carga en cinta. La rutina de detección y las otras 2 rutinas se desechan, o mejor dicho, la machaca el código del juego en cuestión.

Más adelante si la cosa prospera me gustaría meter niveles de forma transparente, de tal forma que un nivel suelto nunca supere los 48K y todos los niveles juntos se puedan empaquetar en 128K. Aunque aquí no se aprecie porque sólo he puesto el TAP, el engine ha evolucionado de tal forma que se encarga practicamente de todo el apartado gráfico. Por ejemplo hay un motor de tiles que permite hasta 256 tiles y estos pueden indexarse. La indexación funciona de la siguiente forma, si tenemos muchos tiles idénticos pero con distintos colores (por ejemplo las rocas en Phantomas 2), estos se codifican más eficientemente indexando los bitmaps. Si por el contrario tenemos muchos tiles distintos pero con los mismos atributos sería mejor aplicar un indexado de atributos. Finalmente existe un indexado mixto. Todo esto ya te digo de forma totalmente transparente, el GfxBu detecta los duplicados en los tiles y te los codifica de la forma que quieras (de entre las 4 maneras posibles).

Luego está el compresor de mapas que es el mismo que le he metido a la Churrera. Al contrario que SpLib la comunicación del juego con el engine no es a través de llamadas a subrutinas, sino a través de estructuras en la memoria. Por ejemplo hay una estructura entre $FE00 y $FE40 que maneja los sprites, indicando su posición X, Y, si está activado o no y el número de sprite a pintar. Los tiles se manejan con las posiciones $5b00, $5b01..$5b96 y $5bfe..$5bff. En la primera posición le decimos al engine que queremos posicionarnos en la pantalla X, una escritura en dicho byte provoca que se pinte toda la pantalla y se carguen en el array $5b01..$5b96 los índices de los tiles. Ahora bien, si quieres modificar los tiles de la pantalla actual, ya sea para animarlos o para abrir un cerrojo, esto se hace escribiendo directamente en $5b01..$5b96 y especificando el rectángulo de tiles a actualizar en $5bfe..$5bff

No te entretengo más. Si quieres puedes encargarte de la parte de alto nivel del engine. En principio he pensado en C pero puede ser cualquier lenguaje. El único requisito es que empiece en $8000 y acabe en una posición determinada por el tamaño de los elementos gráficos pero normalmente tendrás entre 24 y 30K para lo que es el juego en sí (descontando engine en ensamblador y elementos gráficos: sprites, tiles, mapa). Como no hay API no tendrías que enlazar ninguna librería, ah y otra cosa, el descompresor va incluido en el engine ensamblador, es una modificación del ZX7 que va hacia atrás y lleva el filtro RCS incorporado.

Me parece alucinante

De hecho había cosas que había pensado yo, como eso que dices de tiles iguales pero con atributos diferentes, me parece perfecto

Dime lo que tengo que hacer para hacer el api en C