Commodore manía
Commodore 64 => Desarrollo => Mensaje iniciado por: josepzin en Febrero 28, 2024, 20:46:02
-
- CharPad C64 (Free Edition): https://subchristsoftware.itch.io/charpad-c64-free (https://subchristsoftware.itch.io/charpad-c64-free)
- CharPad C64 Pro: https://subchristsoftware.itch.io/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!
(http://imgfz.com/i/6sOA7dy.png)
-
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.
(http://imgfz.com/i/EfBVvNo.png)
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:
(http://imgfz.com/i/KnfTq8C.png)
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.
(http://imgfz.com/i/JsjwfT2.png)
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.
(http://imgfz.com/i/D8Gheau.png)
Puedo tener un color de fondo negro para el interior, azul para el exterior y cyan para el hielo.
(http://imgfz.com/i/dRqUKa1.png)
Esto también me permitía poder ubicar el cofre en el interior (negro) o exterior (azul)
(http://imgfz.com/i/ntdSxDm.png)
-
¡¡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 :D pero bueno, de a poco me iré metiendo.
Ya abriré también un hilo de SpritePad.
-
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.
(http://imgfz.com/i/FfQTdWP.png)
De momento no tengo mucha experiencia en el scroll horizontal/vertical. Pero tengo muchas ganas de hacer algo y profundizar en la técnica.
-
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!! :D
-
Y otra pregunta mas... ¿qué opción usas para exportar los datos?
Yo supongo que lo mejor sería .BIN
-
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
-
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.
-
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
-
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.
-
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.
-
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! :D
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 :D
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.
-
@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!! :D
-
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 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.
-
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
Con el tema del Scroll y tiles la verdad no he trabajado, supongo que del problemas que hablas es para hacer un flip Screen. No acabo de entender muy bien tu problema....
¿Por qué dices que no sabes el ancho? De normal (o por lo menos lo que yo hago) al diseñar pantallas formadas por tiles, es tener unos tiles que encajen con el tamaño de la pantalla. Por ejemplo tiles de 5x5.
Con esto tendrías 8 Tiles horizontales (8x5=40) y 5 verticales (5x5=25) Entonces ya sabes que tienes que poner esos 8 tiles y luego bajar 5 caracteres en la pantalla para poner los siguientes 8.
Los Tiles almacenarán una secuencia consecutiva de 25 caracteres (un vector de caracteres) ej:
Tile1[25]={1,5,6,8,34,12,12,21,34,2,5,45,35,23,53,50,21,12,4,65,45,5,67,4,89}
Tile2[25]={2,8,9,12,26,16,1,1,34,23,5,12,32,25,58,67,2,16,88,99,32,12,6,14,8}
Escribes el Tile1 así: 5 caracteres seguidos en la memoria 0 de pantalla.
5 caracteres seguidos en la memoria 0+40 de pantalla.(Osea una fila mas abajo)
5 caracteres seguidos en la memoria 0+80 de pantalla.(Osea 2 filas mas abajo)
5 caracteres seguidos en la memoria 0+120 de pantalla.(Osea 3 filas mas abajo)
5 caracteres seguidos en la memoria 0+160 de pantalla.(Osea 4 filas mas abajo)
Escribes el Tile2 así: 5 caracteres seguidos en la memoria 0+5 de pantalla.
5 caracteres seguidos en la memoria 0+45 de pantalla.(Osea una fila mas abajo)
5 caracteres seguidos en la memoria 0+85 de pantalla.(Osea 2 filas mas abajo)
5 caracteres seguidos en la memoria 0+125 de pantalla.(Osea 3 filas mas abajo)
5 caracteres seguidos en la memoria 0+165 de pantalla.(Osea 4 filas mas abajo)
Al terminar el octavo Tile bajas 5 filas de pantalla para escribir el noveno. (Osea en la posición 200. 40*5)
Y así hasta completar todo el mapeado..
El mapa de pantalla que exportas en "bin" con charpad, contiene un set de 40 tiles almacenados consecutivamente en un vector y los guarda de izda a dcha y de arriba a abajo (OPQA de toda la vida).
No sé si te aclaro algo o te lío mas :-P
-
Pues a ver si te lo resumo rápido. Al final es todo una evolución...
Cierto, por eso intento ir despacio pero quizas voy demasiado rapido :D
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....
Ya le voy a dar un nuevo vistazo a ese juego, a ver si puedo preguntarte cómo resolviste cosas concretas.
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...
Ahh bien, vi eso de los "materiales" y sospechaba que sería para cosas como esta, asi que me lo has confirmado!!
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...
Nos vamos acercando a parte de mi pregunta,
¿cómo hiciste para crear esa tabla?
Me imagino que fue a mano en plan, poniendo los valores por código. Pero sé que se puede hacer usando editores, no creo que estén entre las opciones de CharPad.
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..
Ahí has creado vida!! :D
Por ejemplo para la colisiones con el escenario, ¿usaste la misma función que para el protagonista?
-
Con el tema del Scroll y tiles la verdad no he trabajado, supongo que del problemas que hablas es para hacer un flip Screen. No acabo de entender muy bien tu problema....
¿Por qué dices que no sabes el ancho? De normal (o por lo menos lo que yo hago) al diseñar pantallas formadas por tiles, es tener unos tiles que encajen con el tamaño de la pantalla. Por ejemplo tiles de 5x5.
Con esto tendrías 8 Tiles horizontales (8x5=40) y 5 verticales (5x5=25) Entonces ya sabes que tienes que poner esos 8 tiles y luego bajar 5 caracteres en la pantalla para poner los siguientes 8.
Los Tiles almacenarán una secuencia consecutiva de 25 caracteres (un vector de caracteres) ej:
Tile1[25]={1,5,6,8,34,12,12,21,34,2,5,45,35,23,53,50,21,12,4,65,45,5,67,4,89}
Tile2[25]={2,8,9,12,26,16,1,1,34,23,5,12,32,25,58,67,2,16,88,99,32,12,6,14,8}
Escribes el Tile1 así: 5 caracteres seguidos en la memoria 0 de pantalla.
5 caracteres seguidos en la memoria 0+40 de pantalla.(Osea una fila mas abajo)
5 caracteres seguidos en la memoria 0+80 de pantalla.(Osea 2 filas mas abajo)
5 caracteres seguidos en la memoria 0+120 de pantalla.(Osea 3 filas mas abajo)
5 caracteres seguidos en la memoria 0+160 de pantalla.(Osea 4 filas mas abajo)
Escribes el Tile2 así: 5 caracteres seguidos en la memoria 0+5 de pantalla.
5 caracteres seguidos en la memoria 0+45 de pantalla.(Osea una fila mas abajo)
5 caracteres seguidos en la memoria 0+85 de pantalla.(Osea 2 filas mas abajo)
5 caracteres seguidos en la memoria 0+125 de pantalla.(Osea 3 filas mas abajo)
5 caracteres seguidos en la memoria 0+165 de pantalla.(Osea 4 filas mas abajo)
Al terminar el octavo Tile bajas 5 filas de pantalla para escribir el noveno. (Osea en la posición 200. 40*5)
Y así hasta completar todo el mapeado..
El mapa de pantalla que exportas en "bin" con charpad, contiene un set de 40 tiles almacenados consecutivamente en un vector y los guarda de izda a dcha y de arriba a abajo (OPQA de toda la vida).
No sé si te aclaro algo o te lío mas :-P
Bien, es lógico que el tema se complique porque no es tampoco fácil de explicar.
Entiendo lo que me dices y es lo que estoy haciendo (al final me salió mientras voy aprendiendo). El caso es que con una pantalla está super claro.
Pero desde CharPad tengo generadas 4 o 5 pantallas de forma consecutivas, asi que luego de la primer linea de datos no tengo la segunda linea de la primer pantalla sino la primer linea de la segunda pantalla ¿se entiende? es como si fuera un mapa para scroll.
Asi que para saltar a la segunda linea debería saber el ancho total del mapa para poder saltear todos esos datos.
Esto ahora lo puedo solucionar generando cada pantalla de forma independiente, sería lo mas simple.
Pero me queda la duda como se hace con las pantallas con scroll.
-
¿cómo hiciste para crear esa tabla?
Me imagino que fue a mano en plan, poniendo los valores por código. Pero sé que se puede hacer usando editores, no creo que estén entre las opciones de CharPad.
[/b]
Si, todo por código, por eso digo que es un dolor. Ahí creo que el charpad no ayuda gran cosa. Una manera quizás sencilla, que simplificaría esta tabla podría ser por ejemplo, establecer un caracter invisible con material 5. En cuyo caso situas ese caracter 2 veces en una plataforma (en el extremo derecho y el izquierdo). Al sinver solo le estableces la posición X/Y y la velocidad. Cuando el sinver alcance el Char invisible con material 5 le inviertes la velocidad (multiplicarla por -1) con lo cual giraría al sentido contrario. Cuando alcance el otro extremo hará lo mismo. Evidentemente para hacer esto, la velocidad debe ser una variable entera con signo.
-
Por ejemplo para la colisiones con el escenario, ¿usaste la misma función que para el protagonista?
Podría usarse, pero hay que tener en cuenta que los enemigos de randoom solo tienen dirección izquierda/derecha y caída por gravedad. El Protagonista además tiene salto con lo cual hay que tener en cuenta mas cosas...mas puntos de colisión pej.cuando chocas con el techo al saltar. Lo que hice fue crear una segunda función partiendo del código de la primera pero simplificada. Eso aunque es algo más de código, mejora el rendimiento. La rutina de colisión y movimiento se ejecuta en cada ciclo del gameloop y por cada elemento en movimiento. En caso de Randoom 8 veces.... bueno, en Randoom hice una cosa rara. En cada ciclo movía el player y un enemigo... osea Player/enemigo1, Player/Enemigo2 etc...pero no te lo recomiendo, es mejor hacer las cosas lo mas ortodoxamente posible :-P
-
Bien, es lógico que el tema se complique porque no es tampoco fácil de explicar.
Entiendo lo que me dices y es lo que estoy haciendo (al final me salió mientras voy aprendiendo). El caso es que con una pantalla está super claro.
Pero desde CharPad tengo generadas 4 o 5 pantallas de forma consecutivas, asi que luego de la primer linea de datos no tengo la segunda linea de la primer pantalla sino la primer linea de la segunda pantalla ¿se entiende? es como si fuera un mapa para scroll.
Asi que para saltar a la segunda linea debería saber el ancho total del mapa para poder saltear todos esos datos.
Esto ahora lo puedo solucionar generando cada pantalla de forma independiente, sería lo mas simple.
Pero me queda la duda como se hace con las pantallas con scroll.
Bueno, es que yo lo hacía así también. Es decir, no exportaba todo el mapeado, sino pantallas independientes. En el tema del Scroll ya no tengo claro como se hará... En todo caso para hacerlo como tu dices, en el momento que compilas para probar, ya sabes las pantallas que tienes metidas. Antes de compilar modificas el valor correspondiente al número de pantallas que tienes y si añades más, modificas el valor. O estableces un valor máximo, por ejemplo de 40 pantallas y lo mantienes salvo que crezca...no le veo más problema salvo que me pierda algo, que también puede ser (soy un programador sinver)
-
Si, todo por código, por eso digo que es un dolor. Ahí creo que el charpad no ayuda gran cosa. Una manera quizás sencilla, que simplificaría esta tabla podría ser por ejemplo, establecer un caracter invisible con material 5.
Sería una opción fácil para poner límites, la única pega que le veo es que en ese lugar no se podría poner ningún elemento del escenario. Y otro problema es que si se usan tiles (2x2, 4x3) la cosa se complica más todavía.
Entre los programas que vengo acumulando desde hace añares para estas cosas tengo uno que se llama Tiled, que quizás podría servir para esto. Seguro hay otros editores mucho mejores. Ya investigaré un poco mas el tema. Por ahora puedo usar el sistema vía código.
-
Bueno, es que yo lo hacía así también. Es decir, no exportaba todo el mapeado, sino pantallas independientes.
Probaré la opción esa de Submaps, a ver si separa cada pantalla.
En todo caso para hacerlo como tu dices, en el momento que compilas para probar, ya sabes las pantallas que tienes metidas. Antes de compilar modificas el valor correspondiente al número de pantallas que tienes y si añades más, modificas el valor. O estableces un valor máximo, por ejemplo de 40 pantallas y lo mantienes salvo que crezca...no le veo más problema salvo que me pierda algo, que también puede ser (soy un programador sinver)
Si, creo que es la respuesta, tener esos valores pero se me va la cabeza en como se haría un scroll multidireccional!
@Zub !!
-
Bien, me voy auto-respondiendo...
He probado en CharPad lo de Flexigrid y está genial, es justo lo que necesitaba para solucionar este tema de las pantallas.
Basicamente lo que permite es exportar cada pantalla por separado. Hay que decirle qué tamaño tiene cada bloque, y este dato es importante porque si el tamaño de la pantalla es mas grande que una pantalla entonces no exporta. Y digo que es importante porque en la versión que estaba usando yo no mostraba ningún mensaje de error ni indicación, simplemente no hacía nada.
Como veo que las diferencias entre la versión gratis y la Pro son muchas (incluyendo esta Flexigrid) me decidí a comprar la última versión (la que tenía antes era de un amigo). Bien vale el precio.
Así que ya pude exportar y ahora tengo un archivo por cada pantalla, mas fácil de procesar.
Por ahora con esto ya me siento mas que conforme y puedo seguir avanzando.
Lo de hacer un scroll multidireccional debe ser un lío de calculos interesante!!
-
Hola !!!
En tu caso, en el Vampire ¿cuál usaste?
Utilicé una tabla de desplazamiento. El Vampire Vengeance cuenta con 4 actos de 7 pantallas c/u. Las pantallas de cada acto las tengo comprimidas, y utilizo una zona buffer en memoria para descomprimir 7 pantallas del acto que corresponda.
Y la tabla de desplazamiento la utilizo para indicar el comienzo de cada pantalla:
Por ej:
Level1 = comienzoZonaBuffer
Level2 = Level1 +1000
Level3 = Level2 +1000
Level4 = Level3 +1000
Level5 = Level4 +1000
Level6 = Level5 +1000
Level7 = Level6 +1000
Esta misma tabla de desplazamiento me sirve para los 4 actos. Ya que las pantallas siempre van a caer en la misma zona.
(los números y grafico es solo a modo ilustrativo)
(http://imgfz.com/i/O082P7U.png)
¿cómo hiciste el mapeado de los enemigos?
Para el mapeado de enemigos, efectivamente Charpad/Spritepad no traen esa funcionalidad, que por cierto seria super interesante que lo agreguen en futuras versiones para no tener que caer usando otro software.
En mi caso utilicé C64 Debugger 8) No solo me ayudó a posicionar enemigos, sino también encontrar errores de codigo, manejando el raster a mano, utilizando el paso a paso para ver como iban cambinando las variables en memoria... me saco el sombrero ! ;D
(http://imgfz.com/i/x1jbA7n.png)
Para definir trayectorias de enemigos, balas, etc utilicé una herramienta que trael el CBM PRG Studio que se llama "Data Generator". Se puede generar una tabla de datos a partir de una funcion matemática. Por ejemplo, utilizando la funcion cos(x) para generar una onda que sube y baja, que puede servir para la trayectoria de una nave espacial...
(http://imgfz.com/i/jaFH56J.png)
Y otra pregunta mas... ¿qué opción usas para exportar los datos?
Yo supongo que lo mejor sería .BIN
Bueno, exactamente, formato .bin, aunque no es el la única manera ya que también podes exportarlo en formato text donde se puede visualizar los datos. Este modo puede servir para saber que hay dentro del .bin y en consecuencia poder realizar la rutina que mejor se adapte a los datos. Finalmente en los proyectos se utiliza .bin porque te ahorra mucho espacio visual en el código.
Nunca me he metido con él porque los 64 caracteres de tope me parecía un poco limitante.
Es MUY limitante... pero es lo que mejor se ajustaba al modo "Spectrum". Sino tenía que usar el modo "ladrillo" de C64 pero perdía el espíritu del juego original.
Es tan limitante los 64 caracteres, que en varias pantallas tuve que redefinirlos varías veces. Estos caracteres extras estaban en una zona buffer de memoria para tal fin.
(http://imgfz.com/i/XwfR1yC.png)
-
Para la detección de colisiones, utilizo una rutina para calcular en que char de la pantalla está ubicado el sprite. Luego con otra rutina se evalúa si el char es transparente/colisión/muerte.
Para esta técnica es importante tener el juego de caracteres agrupados por tipo, por ej:
Transparentes: de 0 a 30 (chars que pertenecen al escenario)
Colisión: de 31 a 50 (pared, piso, techo, antorchas, etc)
Muerte: de 51 a 63 (fuego, picos, lava, etc)
Entonces, si la rutina de colisión me devuelve un char 43 entonces pertenece al grupo de Colisión. Y otra rutina se encargará de detener el sprite para que no avance, generando la sensación de colisión.
El metodo que propone Charpad, es aprovechar el medio byte (nibble) que no utiliza el C64 del mapa de colores. De esta manera uno puede definir lo que se llama "Materiales" teniendo 15 posibles valores.
No lo usé en Vampire.. pero no lo descarto... :o
(http://imgfz.com/i/r42KpWv.png)