CharPad, editor de chars, tiles y mapas

[josepzin]

- CharPad C64 (Free Edition): https://subchristsoftware.itch.io/charpad-c64-free
- CharPad C64 Pro: https://subchristsoftware.itch.io/charpad-c64-pro

Estoy probando este programa, que según parece es el mas completo para esto de definir caracteres, crear tiles y mapas de pantallas.

En principio lo voy entendiendo bastante bien, pero hay cosas que no consigo hacer.

Por ejemplo cambiar el color de cada caracter, sé que en el 64 eso se puede hacer pero desde CharPad me cambia el color a todo el juego.

Veo que @jicas lo consigue!

[jicas]

Coincido que Charpad es lo más apropiado para diseñar juego de caracteres, tiles y mapas.

Lo planteado, depende del modo grafico que este configurado Charpad.

Repasando un poco, cuando encendemos el Commodore 64, lo hace en “Modo Carácter Standard”.
En este modo tenemos 1 color de fondo que es común para todo el juego de caracteres, y 1 color principal para cada caracter. Para ambos casos se puede utilizar cualquiera de los 16 colores.

En este ejemplo, vemos color de fondo en Azul, y color principal en Celeste.


Ocurre que si queremos que la letra A tenga color rojo, y la B color amarillo, debemos cambiar el color principal.
Y como se puede observar, se cambió el color a todo el juego completo:

 
Para evitar esto y lograr el que cada carácter tenga su propio color principal, se debe configurar el “Método de coloración matricial”. Por defecto, al abrir un proyecto en Charpad lo hace en modo “Per Project”, es decir que el color Principal se aplica a todo el proyecto.
Pero al cambiar el método a modo “Per Char” se puede lograr el objetivo. En este ejemplo era que la A sea color rojo y B color amarillo.

 
En el juego Vampire Vengeance, decidí usar un modo grafico llamado “Modo Extendido de Color de Fondo”. Este modo rompe con el límite de 1 solo color para el fondo, pudiendo escoger 4 colores distintos. Pero penaliza con la cantidad de caracteres del juego, que debe ser de 64 (es decir 256 / 4). Los primeros 64 caracteres del juego se repiten 3 veces más pero con distinto color de fondo. Además mantiene el modo de Alta resolución, caracteres de 8x8 píxeles.

 
Puedo tener un color de fondo negro para el interior, azul para el exterior y cyan para el hielo.

 
Esto también me permitía poder ubicar el cofre en el interior (negro) o exterior (azul)

   

[josepzin]

¡¡Espectacular!! una explicación impecable, se agradece!

No me había dado cuenta que se podía cambiar los modos de color... me pasaba eso de cambiar el color y que me cambie todo.

Me gusta ese "Modo Extendido de Color de Fondo", ahora que lo decis, me acuerdo como era, que te quita caracteres porque usa parte del byte de cada caracter para almacenar el color.

Estoy haciendo pruebas y me encanta

Otra pregunta...

Me da la sensación que este programa está pensado para juegos con scroll, obviamente se puede usar para pantallas individuales (vos lo usaste), me imagino que después necesitas una tabla que identifique la posición de memoria (desplazamiento) de cada pantalla en ese mapa grande.

Ahora lo veo todo como una montañas pero bueno, de a poco me iré metiendo.

Ya abriré también un hilo de SpritePad.

[jicas]

El Charpad te da todas las herramientas para que puedas generar los mapas, con o sin tiles, horizontales, verticales o ambos. Pero el método a usar lo deja totalmente del lado del desarrollador. Por ejemplo como mencionas, una tabla de desplazamiento, entre otros.

El juego The Giana Sisters siempre avanza hacia la derecha, nunca se podía volver hacia atrás. Eso tal vez responda al metodo que uso el desarrollador para el scroll horizontal. A medida que avanza carga en pantalla la columna de la derecha, y el resto lo mueve hacia la izquierda.


De momento no tengo mucha experiencia en el scroll horizontal/vertical. Pero tengo muchas ganas de hacer algo y profundizar en la técnica.

[josepzin]

El Charpad te da todas las herramientas para que puedas generar los mapas, con o sin tiles, horizontales, verticales o ambos. Pero el método a usar lo deja totalmente del lado del desarrollador. Por ejemplo como mencionas, una tabla de desplazamiento, entre otros.

@jicas En tu caso, en el Vampire ¿cuál usaste?

Y otra cosa importante... ¿cómo hiciste el mapeado de los enemigos?
He visto que hay programas de mapeo que permiten poner los enemigos y objetos, especificar el comportamiento o trayectoria, etc. No creo que CharPad esté pensado para eso, pero en todo caso ¿cómo lo resolviste?

De momento no tengo mucha experiencia en el scroll horizontal/vertical. Pero tengo muchas ganas de hacer algo y profundizar en la técnica.

La lógica del scroll en principio es fácil, otra cosa es hacerlo y que funcione bien!!

[josepzin]

Y otra pregunta mas... ¿qué opción usas para exportar los datos?

Yo supongo que lo mejor sería .BIN

[Dozznar]

Joe, pues no pensaba que habías usado ese modo Jicas. Nunca me he metido con él porque los 64 caracteres de tope me parecía un poco limitante. Lo cierto es que al margen de este problema es un modo que emula muy bien las prestaciones de color del Spectrum

[Dozznar]

Y otra pregunta mas... ¿qué opción usas para exportar los datos?

Yo supongo que lo mejor sería .BIN

Si, siempre se exportan en Bin. Se exporta el set  "Chars", "Map" y "Attrib map. Después en el programa hay que hacer una rutina para cargar los caracteres en la memoria de caracteres. Y luego otra que cargue el Map y lo "colorice".

Es una buena idea usar alguna rutina de compresión, ya que cada pantalla ocupa 1kB. Tengo bastante código en "C" por si quieres echarle un ojo, igual te resulta más accesible que el ASM, aunque en concreto estas rutinas son bastante sencillas de implementar. Básicamente copiar datos de una zona de memoria a otra.

[Dozznar]

Al Scroll del C64 (Hardware) me gustaría un día dedicarle un directito. Hacer un Scroll Software (al caracter) de una linea de texto es muy sencillo. Cualquier programador experto como usted deducirá el procedimiento. ;-P

El tema es cuando te metes en un Scroll al pixel (Hardware). Aquí el VICII no nos ayuda tanto como nos hubiera gustado. Básicamente (resumiendo), lo único que ofrece es un registro al que le metes un valor del 0 al 7. Este valor simplemente desplaza la pantalla (Toda la pantalla) a la derecha/izquierda o arriba/abajo  el número de pixels que indiquemos en el registro. En un juego, salvo que el área de juego sea toda la pantalla no acaba de ser muy práctico ya que necesitamos meter marcadores seguramente. Tenemos dos opciones:

1.- Poner los marcadores como Sprites (no se ven afectados por el scroll) Es una técnica que queda bastante chula en algunos juegos ya que el "Score" por ejemplo, queda en un overlay sobre el área de juego. El problema es que tenemos el límite de 8 sprites para el juego y los marcadores. Obviamente los juegos que usan esta técnica, multiplexan para saltarse ese límite, lo que implica técnicas de manejo del Raster. Que bueno, tampoco son complicadas, es meterse un poquito más.

2.- Hacer que parte de la pantalla no se vea afectada por el Scroll. Esto también se maneja por medio del raster, interrumpiendo el trazado de la imagen cuando lleguemos a una línea concreta de pantalla.

En ambos casos hay un problemilla añadido. El volcado de los datos de la imagen a la pantalla debe hacerse rápido o si no queda un efecto de "LAG" muy feo. Para solucionarlo se suele usar técnicas de doble buffer de pantalla.
 
De todo esto hay bastante documentacion por aquí https://codebase64.org/doku.php?id=start. (En perfecto Inglés y para ASM)

En el Oscar 64 (ya para "C") hay en la carpeta "samples" código aplicado a ambas técnicas, entre otras cosas..

https://github.com/drmortalwombat/oscar64

Por último en mi "afamado" "Fart Scape" uso la segunda técnica de una manera chapucera pero me funciona. Y creo que también tengo algún ejemplo con código sencillo que estaría dispuesto a compartir si me prometes no reirte al verlo ;-P

[josepzin]

Joe, pues no pensaba que habías usado ese modo Jicas. Nunca me he metido con él porque los 64 caracteres de tope me parecía un poco limitante. Lo cierto es que al margen de este problema es un modo que emula muy bien las prestaciones de color del Spectrum

Cierto, parecen pocos pero también depende del tipo de juego. Es un modo que me gusta mucho, la verdad.

[josepzin]

Si, siempre se exportan en Bin. Se exporta el set  "Chars", "Map" y "Attrib map. Después en el programa hay que hacer una rutina para cargar los caracteres en la memoria de caracteres. Y luego otra que cargue el Map y lo "colorice".

Ya le di a "exportar todo", asi que tengo chars, atributos, tiles y mapas. Ahora me queda intentar ir pegoteando todo eso...

Es una buena idea usar alguna rutina de compresión, ya que cada pantalla ocupa 1kB.

Estuve mirando algo de código de este Rascal, tiene muchos ejemplos, empezando desde cosas muy básicas. Pero es demasiada información y eso facilmente puede saturar mi cerebro y agobiarme por verlo todo como una montaña muy grande.
Así que estoy empezando muuuy de a poco, poniendo caracteres en pantalla, familiarizandome con esto.

Tengo bastante código en "C" por si quieres echarle un ojo, igual te resulta más accesible que el ASM, aunque en concreto estas rutinas son bastante sencillas de implementar. Básicamente copiar datos de una zona de memoria a otra.

Y si, llegado el momento tocará lo de comprimir cosas, pero por ahora eso lo veo como algo muy lejano.

He abierto un hilo sobre el TRSE para ir comentando como me va.

[josepzin]

Al Scroll del C64 (Hardware) me gustaría un día dedicarle un directito. Hacer un Scroll Software (al caracter) de una linea de texto es muy sencillo. Cualquier programador experto como usted deducirá el procedimiento. ;-P

Entre los ejemplos que estaba viendo ayer había uno muy simple de estos. Tan simplificado el código que me costaba entenderlo!

El tema es cuando te metes en un Scroll al pixel (Hardware). Aquí el VICII no nos ayuda tanto como nos hubiera gustado. Básicamente (resumiendo), lo único que ofrece es un registro al que le metes un valor del 0 al 7. Este valor simplemente desplaza la pantalla (Toda la pantalla) a la derecha/izquierda o arriba/abajo  el número de pixels que indiquemos en el registro. En un juego, salvo que el área de juego sea toda la pantalla no acaba de ser muy práctico ya que necesitamos meter marcadores seguramente. Tenemos dos opciones:

1.- Poner los marcadores como Sprites (no se ven afectados por el scroll) Es una técnica que queda bastante chula en algunos juegos ya que el "Score" por ejemplo, queda en un overlay sobre el área de juego. El problema es que tenemos el límite de 8 sprites para el juego y los marcadores. Obviamente los juegos que usan esta técnica, multiplexan para saltarse ese límite, lo que implica técnicas de manejo del Raster. Que bueno, tampoco son complicadas, es meterse un poquito más.

2.- Hacer que parte de la pantalla no se vea afectada por el Scroll. Esto también se maneja por medio del raster, interrumpiendo el trazado de la imagen cuando lleguemos a una línea concreta de pantalla.

En ambos casos hay un problemilla añadido. El volcado de los datos de la imagen a la pantalla debe hacerse rápido o si no queda un efecto de "LAG" muy feo. Para solucionarlo se suele usar técnicas de doble buffer de pantalla.

La lógica del tema la entiendo, pero luego a la hora de ponerse seguro que se complica bastante... Todo lo del raster implica unas optimizaciones que por ahora no están a mi alcance todavía.

De todo esto hay bastante documentacion por aquí https://codebase64.org/doku.php?id=start. (En perfecto Inglés y para ASM)

Has citado a la Madre de todos los ensambladores con esa web...

En el Oscar 64 (ya para "C") hay en la carpeta "samples" código aplicado a ambas técnicas, entre otras cosas..
https://github.com/drmortalwombat/oscar64

He dudado muchísimo entre Oscar64 y TurboRascal, al final me ha ganado la nostalgia y mi pasada afinidad con Pascal, pero sino lo tenía claro: C con Oscar64 o CC65.

Por último en mi "afamado" "Fart Scape" uso la segunda técnica de una manera chapucera pero me funciona. Y creo que también tengo algún ejemplo con código sencillo que estaría dispuesto a compartir si me prometes no reirte al verlo ;-P

Afamado y denostado

Yo poco puedo reirme del código de nadie!!

Llegado el momento ya pediré consejos a indeseables de la programación como usted. Ya te cito en el otro hilo, asi lo tienes presente también.

[josepzin]

@Dozznar también me interesa saber cómo hiciste en tus juegos para cada pantalla, enemigos o información especial de la pantalla.

@jicas En tu caso, en el Vampire ¿cuál usaste?

Y otra cosa importante... ¿cómo hiciste el mapeado de los enemigos?
He visto que hay programas de mapeo que permiten poner los enemigos y objetos, especificar el comportamiento o trayectoria, etc. No creo que CharPad esté pensado para eso, pero en todo caso ¿cómo lo resolviste?
La lógica del scroll en principio es fácil, otra cosa es hacerlo y que funcione bien!!

[josepzin]

Me encuentro con un problema en esto del mapeado.

Al hacer las pantallas como si fuera un scroll, una detras de la otra, luego para leerlas es un lio porque ¿cómo se cuanto sumar para llegar a la fila siguiente, si no sé el ancho total del mapa?

No sé si se entiende...

Cada pantalla tiene 10 tiles, pero el mapa que tengo con CharPad tiene (supongamos) 6 pantallas.

Si quiero mostrar la primer pantalla empiezo leyendo desde cero pero al llegar a 10 tendría que pasar a la linea de abajo y eso significa sumar el total de todo el mapa para llegar a la primer columna de la segunda linea.

No me parece una buena idea... igual me pregunto cómo lo hacen cuando tienen un mapa con scroll, que tienen que ir metiendo a la pantalla una columna, ¿hay que saber de antemano ese ancho? ¿y si cada nivel tiene un ancho distinto?. Se me ocurren soluciones pero me pregunto si no hay otras opciones.

@Dozznar @jicas

[Dozznar]

@Dozznar también me interesa saber cómo hiciste en tus juegos para cada pantalla, enemigos o información especial de la pantalla.

Pues a ver si te lo resumo rápido. Al final es todo una evolución...

Tanto el Bomb run como el fart Escape (los inicios) el sistema de colisión era muy sencillo, usando las prestaciones del VIC. (Colisión sprite/Background en Bomb run y Sprite/Sprite en Fart Escape) Para editar las pantallas en Bomb run que era modo bitmap no usé Charpad. Creo que fue Multipaint. Para el Fart Escape si usé el charpad a un nivel muy básico....

En el Juanje Juega, Seguía con la colisión Sprite/Sprite hardware pero ya fue necesario implementar colisión software con las plataformas. Aquí, tiré del Charpad para establecer los caracteres "colisionables". Lo hice gestionado el tema de los "materiales" que no sé si lo has visto. Chars con material 0 eran aire, material 1 suelo, material 2 escalera etc etc... Luego había que implementar el algoritmo correspondiente para que el sprite detectara estas circunstancias.  La animación del los sinvers era bastante simple pero costosa de "setear", para cada pantalla había una tabla tipo:

Enemigo1--->Posx,Posy,Velocidad,DesplazamientoX,DesplazamientoY, Cambio de sentido aleatorio (si o no) etc...

En Randoom También uso el tema de los materiales. Para los sprites ya uso colisiones por Software y la mayor evolución viene de la animación de los sinvers... debido a lo costoso que era en JJ, quería hacer que tuvieran un movimiento autónomo ( Que detectaran los choques con las plataformas o que cayeran al llegar al borde de la misma) De esta mánera solo hay que situarlos en pantalla y cobran vida..

Y en Valkyr, uso software sprites, aquí el Charpad solo me sirvió para los márcadores, la portada y el diseño de los enemigos que eran Chars.