Re: Y el CPC...?
Publicado: Dom, 03 Nov 2013, 08:47
Pues lo primero que hay que hacer es enterarse un poco de como funciona CPCRSLIB... Si yo tuviese que ponerme ahora a portar un güego tendría que hacerlo, para refrescar, porque la verdad es que lo tengo super oxidado.
Luego hay que hacer de nuevo los gráficos. Las tres resoluciones del CPC son directamente compatibles, sobre todo trabajando con CPCRSLIB, que alinea (al menos alineaba, no sé si ahora) horizontalmente a nivel de bytes. Eso significa que el modo 0 la precisión es de dos pixels, en modo 1 de 4 y en modo 2 de 8, que son los pixels que entran en un byte en cada modo.
Elegimos un modo y pasamos los gráficos. En modo 0, los tiles y sprites deben ser de 8x16 en 16 colores, en modo 1 de 16x16 en 4 colores, y en modo 2 de 32x16 en 2 colores. Como he dicho, son intercambiables. Toma por ejemplo Sir Ababol, que está en modo 1. Cambiarlo a modo 0 implicaría sólamente cambiar los gráficos y una linea en el código, porque, como digo, los modos son 100% equivalentes. De hecho, podría hacerse el experimento rápido de buscar una paleta y directamente cambiar el modo en el código, que se verá medio decente. Dos píxels 00 01 se convertirían en el pixel 0001 del tirón.
Una vez terminados los gráficos se convierten usando diversos conversores. Tiles y Sprites, si mal no recuerdo, se pasaban por una utilidad de conversión de Augusto Ruiz. Las pantallas compeltas se pasaban por una utilidad francesa que creo que se llamana ConvImgCPC o algo así, y se comprimían con exomizer (porque viene integrado en CPCRSLIB).
Luego se pilla el código de la churrera y se pasa. En aquella época era relativamente sencillo porque, como digo, la Churrera 1.0 hacía muy pocas cosas y tenía pocos #defines de compilación selectiva. Ahora puede ser una pequeña pesadilla.
Pasar la Churrera consiste en:
1.- Cambiar la inicialización. Como dije, la CPCRSLIB de entonces tenía ciertos manejes que había que hacer a mano, como configurar un archivo en asm con el buffer de tiles adecuado al tamaño y posición de tu pantalla de juego. Esto creo que lo podéis aprovechar directamente de los juegos que hay pasados, porque la pantalla es la misma en todos los churreras.
2.- Cambiar las llamadas a splib2 por llamadas a CPCRSLIB: pintar tiles, mover sprites...
3.- Hacer el ajuste de coordenadas: como digo, CPCRSLIB funciona horizontalmente a nivel de bytes, por lo que hay que ajustar las coordenadas reales internas por coordenadas alineadas a byte antes de llamar a las funciones que mueven los sprites. Los güegos siguen funcionando internamente a 1/64 de pixel de precisión, pero externamente se alinea horizontalmente a byte y verticalmente a pixel.
Tiene su aquel, pero hecho el primero los demás se hacen rápido.
Al final el 99% del código es exactamente el mismo entre versiones, sólo cambia la parte de "interfaz".
El problema es que cuando empezamos el 4º juego de Churrera para Spectrum ya nos pusimos a engordar el motor más y más y... bueno.
UWOL2 tuvo más trabajo, no fue un port. Para ese decidimos hacerlo solo para CPC y aprovechar bien el ancho extra de la pantalla. Usamos las rutinas de la churrera como base, pero el motor es prácticamente específico para ese güego.
Luego hay que hacer de nuevo los gráficos. Las tres resoluciones del CPC son directamente compatibles, sobre todo trabajando con CPCRSLIB, que alinea (al menos alineaba, no sé si ahora) horizontalmente a nivel de bytes. Eso significa que el modo 0 la precisión es de dos pixels, en modo 1 de 4 y en modo 2 de 8, que son los pixels que entran en un byte en cada modo.
Elegimos un modo y pasamos los gráficos. En modo 0, los tiles y sprites deben ser de 8x16 en 16 colores, en modo 1 de 16x16 en 4 colores, y en modo 2 de 32x16 en 2 colores. Como he dicho, son intercambiables. Toma por ejemplo Sir Ababol, que está en modo 1. Cambiarlo a modo 0 implicaría sólamente cambiar los gráficos y una linea en el código, porque, como digo, los modos son 100% equivalentes. De hecho, podría hacerse el experimento rápido de buscar una paleta y directamente cambiar el modo en el código, que se verá medio decente. Dos píxels 00 01 se convertirían en el pixel 0001 del tirón.
Una vez terminados los gráficos se convierten usando diversos conversores. Tiles y Sprites, si mal no recuerdo, se pasaban por una utilidad de conversión de Augusto Ruiz. Las pantallas compeltas se pasaban por una utilidad francesa que creo que se llamana ConvImgCPC o algo así, y se comprimían con exomizer (porque viene integrado en CPCRSLIB).
Luego se pilla el código de la churrera y se pasa. En aquella época era relativamente sencillo porque, como digo, la Churrera 1.0 hacía muy pocas cosas y tenía pocos #defines de compilación selectiva. Ahora puede ser una pequeña pesadilla.
Pasar la Churrera consiste en:
1.- Cambiar la inicialización. Como dije, la CPCRSLIB de entonces tenía ciertos manejes que había que hacer a mano, como configurar un archivo en asm con el buffer de tiles adecuado al tamaño y posición de tu pantalla de juego. Esto creo que lo podéis aprovechar directamente de los juegos que hay pasados, porque la pantalla es la misma en todos los churreras.
2.- Cambiar las llamadas a splib2 por llamadas a CPCRSLIB: pintar tiles, mover sprites...
3.- Hacer el ajuste de coordenadas: como digo, CPCRSLIB funciona horizontalmente a nivel de bytes, por lo que hay que ajustar las coordenadas reales internas por coordenadas alineadas a byte antes de llamar a las funciones que mueven los sprites. Los güegos siguen funcionando internamente a 1/64 de pixel de precisión, pero externamente se alinea horizontalmente a byte y verticalmente a pixel.
Tiene su aquel, pero hecho el primero los demás se hacen rápido.
Al final el 99% del código es exactamente el mismo entre versiones, sólo cambia la parte de "interfaz".
El problema es que cuando empezamos el 4º juego de Churrera para Spectrum ya nos pusimos a engordar el motor más y más y... bueno.
UWOL2 tuvo más trabajo, no fue un port. Para ese decidimos hacerlo solo para CPC y aprovechar bien el ancho extra de la pantalla. Usamos las rutinas de la churrera como base, pero el motor es prácticamente específico para ese güego.