Commodore manía

Commodore 64 => Desarrollo => Mensaje iniciado por: SingletonJohn en Marzo 28, 2022, 12:56:34

Título: Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 28, 2022, 12:56:34
Hola a todos!
Soy nuevo por aquí y tras darme una buena chapada de libros +docu+cacharrear,voy a empezar un proyecto simple (no creo que acabe siendo un juego) para aprender el manejo de Sprites, colliders, animaciones, organización de proyecto,etc
Estoy trabajando en "nativo" con un TheC64,TMP+REU(512k),Super SnapShot Cartridge y J Fox Graphic Studio

 En cuanto vea cómo subir videos,fotos y archivos empiezo a compartir.....así como toda reflexión/idea que tenga durante el proceso.

Saludos de un nuevo loco!
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 28, 2022, 13:09:10
P.D.El ritmo de desarrollo será un poco irregular,ya que soy padre de dos niños pequeños y entre eso,el curro y la casa,me dejan poco tiempo operativo para esto...

Pero bueno,un esfuerzo nocturno por una afición que además puede sacar sonrisas en mis hijos (mis principales bet-testers  ;D) pues se lleva mejor!

Saludos de nuevo!
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 28, 2022, 13:52:50
Esta es la estructura principal del programa,que estará hecho de manera íntegra en ensamblador:

Vamos,que el desarrollo del juego va a ser en el Banco 1,ya que tengo espacio para almacenar los personajes y sus animaciones y usar un custom Charset para dibujar los fondos y las pantallas
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 28, 2022, 13:56:46
El banco 0 lo dejaré para menús y demás, ya que es un proyecto escuela y no tengo intención de crearme un Charset guay por ahora para ello....lo más seguro es que deje la VRam en el clásico $400-$800

Si a los menús les quisiera dar un toque gráfico,le metería algún sprite
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 28, 2022, 14:10:54
Por ahora solo tengo una pantalla muy simple dibujada directamente sobre la VRAM para hacer pruebas de colisiones contra el background
Tengo un único personaje asignado al Sprite 0(que es manejado por el joystick)y al Sprite 1 (con otro color, que persigue al Sprite 0).
El personaje es multicolor y tiene 5 animaciones:parado y moviéndose arriba,abajo,izquierda y derecha

Ahora estoy viendo cómo meter colisiones mediante una collision box y la cosa se empieza a poner interesante...no sé si tomar las coordenadas de cada Sprite y ver si hay algún carácter sobre la caja o usar arrays o técnica similar para comprimir l info de la pantallas y que la collision box busque ahí....

Lo que tengo claro es que tengo que agrupar cada tipo de carácter por su efecto sobre el personaje....es decir,del carácter 0 al 20 barreras,del 20 al 40 obstáculos mortales y del 40 al 60 powerups y así.....
Título: Re:Mini proyecto escuela
Publicado por: josepzin en Marzo 28, 2022, 14:20:36
Será un placer ir viendo tus avances y comentarios!

Si quieres publicar imágenes tienes varias opciones:
- Adjuntarlas al foro: esto tiene algunas limitaciones  de tamaño para no saturar el servidor, por ejemplo si son capturas de pantalla o desde emulacion (que no es tu caso o no sé si permite hacer el The64) ocupan moy poco, pero si son fotos vas a tener que reescalarlas.
- Subirlas a https://imgur.com/ y luego copiar el enlace de la imagen. Yo estoy usando mucho este método, lo malo es que estos servicios nunca se sabe cuanto duran :P
- También podrías subirlas a blogger.com y tambien copiar la URL de la imagen, dudo mucho que blogger caiga mientras siga Google con vida!

Para videos te queda Youtube, que es muy simple de usar ya que pegas el enlace y ya aparece el video directamente en el foro.
Título: Re:Mini proyecto escuela
Publicado por: Narcisound en Marzo 28, 2022, 14:30:15
Enhorabuena por la iniciativa amigo SingletonJohn. Seguro que a mucha gente le va a interesar. Si más adelante necesitas meterle una musiquilla a modo de ejemplo para que la peña vea como se inserta en el código y como se va llamando al player de la rutina,  no dudes en pedirla.

Saludos.
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 28, 2022, 14:35:00
Muchas gracias a los dos!

Gracias por tu ofrecimiento Narcisound! Pero en este primer proyecto simple tengo intención de currarme yo mismo hasta el sonido/musica para ver de cerca como es hablar con el SID (emulado :()
Título: Re:Mini proyecto escuela
Publicado por: Narcisound en Marzo 28, 2022, 14:36:35
Genial, siempre es bueno hacerse con una rutina musical propia. Suerte en el intento!
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 28, 2022, 14:40:14
Jejejeje....no se en que acabará...Sólo se que mientras estudiaba a fondo toda la docu tenía permanentemente músicas del SID y veía en mis ratos libres videos del osciloscopio de las que más me molaban para ir aprendiendo

 
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 28, 2022, 14:45:04
Siento debilidad especial por Jeroen Tel, Matt Gray y Wally Beben....ya sé que algunos me acusaran de hereje por no mencionar a Hubbard, que es enorrrrrme y que su temazo de InGame de Delta me parece fascinante
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 09:31:05
https://youtu.be/aVN4AaJV2WM?mute=1

Creando un personaje en J Fox Graphic Editor
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 09:32:13
https://youtu.be/gNfL9_NS1ds?mute=1

Controlando el personaje con el joystick
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 09:32:59
https://youtu.be/D7C9lunQzX4?mute=1

Añadiendo un enemigo perseguidor
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 09:33:39
https://youtu.be/gXZ5EYpOUc8?mute=1

Pintando una pantalla simple
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 09:34:27
Ahora programando las colisiones contra el fondo con collision boxes
Título: Re:Mini proyecto escuela
Publicado por: Bieno en Marzo 30, 2022, 10:02:43
Que rápido aprendes !!!!!!!!!!  :D
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 11:10:48
Que rápido aprendes !!!!!!!!!!  :D

 ;D....esto está hecho a ratos por las noches durante un mes o asi
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 11:21:46
Explico cómo he planteado el movimiento
1-Creo unas tablas de X,Y para 8 personajes. Se asignará 1 a cada sprite (luego intentaré modificar esto y
   hacerlo compatible con multiplexing).
2-En la tabla creo un campo RENDER que será 0 cuando no haya que renderizar y 1 cuando haya que
   renderizar
3-La modificación de la posición se lleva a cabo en la ejecución normal. El programa mira qué sprites están
   activados en el VIC y además mira que  RENDER = 0.
4-El sprite 0 es controlado por el joystick. El resto se moverán por una rutina de seguir al sprite 0 (la
   intención es poder asignar a cada personaje una rutina que pueda ser distinta y así tener varios
   comportamientos de enemigos).
5-Tras mover las coordenadas, el campo pasa a RENDER = 1....la posición NO se podrá modificar hasta
   que la nueva posición del sprite aparezca en pantalla
6-He aprovechado la interrupción estándar del C64 (60Hz) y he modificado la rutina. Es muy simple,
   toma de la lista los sprites activos con RENDER = 1 y pone las coordenadas X,Y de la tabla en la
   Posición X,Y del sprite. Tras ello, RENDER = 0 ......listo para siguiente movimiento
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 11:31:23
Además de los campos X,Y y RENDER, la tabla tiene 3 campos más:
-Dirección anterior de movimiento
-Retardo de movimiento
-Retardo de animación.

Cuando un sprite recibe una orden de movimiento, lo compara con el movimiento anterior. Así sé cuándo tengo que cambiar la animación. Si el movimiento es el mismo que el movimiento anterior, se suma 1 al campo de retardo de la animación. Cuando se supere el límite de retardo, se pasa al frame siguiente y se pone el retardo a cero.
Si el movimiento varía, se ponen los retardos a cero y se asigna al Pointer del sprite el frame inicial de ese movimiento.

De manera paralela, existe un retardo para el movimiento. El sprite no modificará su posición hasta que el retardo no rebase el límite.

El retardo de la animación depende de las características del personaje. Hay una tabla (de CONSTANTES) para ello. En ella está los campos: Parado, arriba, abajo, izquierda,derecha (que contienen el valor del Sprite pointer del primer frame de cada movimiento.....por lo tanto, el final del movimiento es el inicio del movimiento siguiente) y los retardos de animación de parado, arriba, abajo, izquierda, derecha

El retardo del movimiento dependerá de cada sprite y se puede asignar en cualquier momento

Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 11:33:34
Si estáis interesados en alguna rutina en especial, os la enseño...lo que me pidáis
Lo único que tengo todo el proyecto en archivos SEQ en una imagen de diskette....supongo que con el VICE se podrá importar. Meto tb el Turbo Macro Pro y listo.
Otra opción es pasaros los SEQ y que los podáis ver....pero es mucha info a cholón, aunque tengo todo relativamente bien documentado con comentarios
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 11:51:38
Lo más importante:
1-El orden de las animaciones. Son parado, izquierda, derecha, arriba, abajo (el mismo orden de los bits
  del Joystick)
2-Asigno un número a cada dirección. 0:parado, 1:izquierda, 2:derecha, 3:arriba, 4:abajo. De esta
   manera puedo usar el número como índice para las animaciones y para las rutinas de movimiento
3-Se crea una tabla de salto a las rutinas de movimiento, en la que aparecen en el mismo orden de las
   animaciones y de los bits del joystick. Para hacer el salto se usa el STACK y RTS:
       LDA MOVHI,X   (X es la dirección, MOVHI es el HIGH byte de la rutina de movimiento)
       PHA
       LDA MOVLO,X
       PHA
       RTS
   (OJO!->Si se usa esta técnica, el byte MOVLO tiene que contener el LOWByte de la rutina de
    movimiento - 1, ya que el RTS transfiere al Program counter lo que hay en el stack y le SUMA 1.
    CONSEJO->Si las subrutinas de movimiento están en la misma página de memoria, todas tienen el
    mismo HIGH byte y te ahorras meterlo en una tabla....será una CONSTANTE)
       
4-El movimiento tiene 1 byte, por lo que se pueden almacenar dos dígitos: en el LowNibble(bits 0 a 3)
   pongo el movimiento 1 y en el HighNibble (bits 4 a 7) pongo el movimiento dos. Esto me permite hacer
   diagonales. P.ej: un 2 es derecha, un 13 arriba-izquierda
5-Las animaciones sólo hacen caso al LowNibble del movimiento, ya que no he hecho animaciones para las
   diagonales ;)....por eso, el movimiento diagonal tiene como animación arriba o abajo
6-Con esta organización, los parámetros de entrada de cada subrutina pueden ser: registro X->Dirección
   de movimiento, Registro Y->nº de sprite... registro A->queda libre y puedo usarlo como parámetro tb.
Título: Re:Mini proyecto escuela
Publicado por: PacoBlog64 en Marzo 30, 2022, 12:44:26
Esta es la estructura principal del programa,que estará hecho de manera íntegra en ensamblador:

    Variables/Arrays:[$801-?)
    Charset gráfico: [$4000-$4800)
    Video RAM: [$4800-$4CC0)
    Personajes/animaciones:[$4CC0-?)
    Programa principal/Subrutinas:[$C000-?)


Me parece una gran iniciativa, a ver si se engancha más gente a programar en ensamblador. Sobre esto, un par de consejos que he aprendido en el tiempo que llevo dándole a esto:
- Entre $0000-$0801, quitando el espacio de la pila, hay cerca de 1,5KB de RAM que puedes usar para variables.
- Si usas el VBANK $C000-$FFFF que hay bajo el Kernal ROM te quedará más memoria para código, sprites, gráficos, etc. Tendrás que cambiar un poco las interrupciones para que no vayan por ROM (muy fácil), pero quitando eso, ganarás unos 8KB de memoria.

Imagino que ya conocerás esto, es el mapa de memoria del C64, lo uso habitualmente para saber dónde están algunas cosas en memoria y qué huecos puedo usar: http://sta.c64.org/cbm64mem.html (http://sta.c64.org/cbm64mem.html)
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 13:59:01
- Entre $0000-$0801, quitando el espacio de la pila, hay cerca de 1,5KB de RAM que puedes usar para variables.
Reconozco que la página cero y sucesivas no las tengo muy estudiadas para este proyecto porque tengo intención de que no sea muy largo....lo justo para llegar como mucho al multiplexing. Me metí en las $0800 porque tengo claro que el basic no lo voy a usar, con lo cual acabaré deshabilitando la ROM.
Esas 1,5KB de RAM están muy fragmentadas o hay bloques decentes?

- Si usas el VBANK $C000-$FFFF que hay bajo el Kernal ROM te quedará más memoria para código, sprites, gráficos, etc. Tendrás que cambiar un poco las interrupciones para que no vayan por ROM (muy fácil), pero quitando eso, ganarás unos 8KB de memoria.
Si, lo del overlapping, rom switching, etc....lo controlo. Y no es muy complicado hacerlo. En un proyecto más largo o con multiples pantallas/enemigos, tenía intención de usarlo como "almacén gráfico" sobre todo

Imagino que ya conocerás esto, es el mapa de memoria del C64, lo uso habitualmente para saber dónde están algunas cosas en memoria y qué huecos puedo usar: http://sta.c64.org/cbm64mem.html (http://sta.c64.org/cbm64mem.html)
Si tengo varios tipos de mapas (como todos imagino ;D). Desde el más detallado (Libro "Mapping the Commodore 64") hasta el clásico por bloques (libro "Commodore 64 Programmer's Reference Guide)
Título: Re:Mini proyecto escuela
Publicado por: josepzin en Marzo 30, 2022, 14:10:16
El resto se moverán por una rutina de seguir al sprite 0 (la
   intención es poder asignar a cada personaje una rutina que pueda ser distinta y así tener varios
   comportamientos de enemigos).

Por si te sirve, mira como hace en el Pacman para controlar los fantasmas, es ESPECTACULAR y muy inspirador lo que hicieron.

https://www.youtube.com/watch?v=0OUfyzcrCio (https://www.youtube.com/watch?v=0OUfyzcrCio)
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 14:27:01
Por si te sirve, mira como hace en el Pacman para controlar los fantasmas, es ESPECTACULAR y muy inspirador lo que hicieron.

Gracias josepzin! Al meterme en harina con esto de hacer un minijuego fue en el juego que pensé sobre el comportamiento (variable y cada enemigo con un comportamiento bastante definido)....esto es una información de mucho valor!
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 14:45:13
...
6-Con esta organización, los parámetros de entrada de cada subrutina pueden ser: registro X->Dirección
   de movimiento, Registro Y->nº de sprite... registro A->queda libre y puedo usarlo como parámetro tb.

7-Me queda por implementar lo que pasa al pulsar el botón de disparo del joystick....no sé si ponerme
   rácano con la memoria y usar el bit de signo de la variable movimiento (bit 7, que está libre), usar un
   byte en el que cada bit sea el sprite que ha dado al disparo (esto no valdría con multiplexing) o crear
   un nuevo campo en la tabla que sea FIRE....no sé qué pensáis.Creo que la del signo es la que más me
   gusta
Título: Re:Mini proyecto escuela
Publicado por: PacoBlog64 en Marzo 30, 2022, 17:24:15
Reconozco que la página cero y sucesivas no las tengo muy estudiadas para este proyecto porque tengo intención de que no sea muy largo....lo justo para llegar como mucho al multiplexing. Me metí en las $0800 porque tengo claro que el basic no lo voy a usar, con lo cual acabaré deshabilitando la ROM.
Esas 1,5KB de RAM están muy fragmentadas o hay bloques decentes?
Tienes un bloque bien majo de 1KB en $0400-$0800, que es la screen ram por defecto. Luego quitando la pila de $0100-$01FF, entre $0200 y $03FF hay otro bloque de 512KB que no debería darte problemas. Aparte de la Zeropage para hacer lda ($fb) y cosas de esas ;)

Si, lo del overlapping, rom switching, etc....lo controlo. Y no es muy complicado hacerlo. En un proyecto más largo o con multiples pantallas/enemigos, tenía intención de usarlo como "almacén gráfico" sobre todo
Para eso mismo uso yo el hueco bajo la ROM, como Video Bank para poner bitmaps y otros elementos gráficos. Así tienes casi todos esos 64KB de RAM disponibles para ti.

Los vídeos que has publicado pintan muy bien y vas muy rápido, qué envidia XDDDD
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 30, 2022, 18:29:49
Tienes un bloque bien majo de 1KB en $0400-$0800, que es la screen ram por defecto. Luego quitando la pila de $0100-$01FF, entre $0200 y $03FF hay otro bloque de 512KB que no debería darte problemas. Aparte de la Zeropage para hacer lda ($fb) y cosas de esas ;)

Gracias por la info!

Los vídeos que has publicado pintan muy bien y vas muy rápido, qué envidia XDDDD
:D ;D ;D....no voy muy rápido.He subido el curro de 1 mes/mes y medio y esto es lo más sencillo....ahora que empieza la fiesta con las collision boxes y Multiplexing el ritmo bajará considerablemente ;D ;D ;D

La idea es aprender y sacar una rutinas guapas y flexibles para reutilizar
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Marzo 31, 2022, 06:27:17
Por si te sirve, mira como hace en el Pacman para controlar los fantasmas, es ESPECTACULAR y muy inspirador lo que hicieron.

Increíble.....gracias por compartir el vídeo! ;)
Título: Re:Mini proyecto escuela
Publicado por: josepzin en Marzo 31, 2022, 13:51:59
Es increible todo lo que hay detras de la lógica de esos fantasmitas, que parece una tontería pero no por nada el juego es lo que es.
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 03, 2022, 13:40:31
Ayer por fin tuve algo de tiempo e hice pruebas de colisiones
Conseguí abrir la pantalla como fichero lógico con CHKIN y OPEN,y obtener un char de pantalla usando PLOT y CHRIN.
Como obtener las líneas/columnas ocupadas por el collider es una operación "barata",creo que voy a usar este sistema y dejar al Kernal que haga el trabajo sucio.Este es el esquema del proceso de detectar colisiones.

1-Abrir el fichero lógico de la pantalla al iniciarse un escen de "acción".Habrá que cerrarlo y abrir el del teclado cuando te maten
2-Al hacer un Spawn de jugador/enemigo se asignará la posición del collider.Esto nos evitará calcularla,aunque habrá que crear una nueva tabla con las posiciones de los colliders.
3-Dentro de las rutinas de movimiento,al inicio de todas,crearemos una subrutina de colisión que responda con Carry Set si hay colisión o Carry Clear si no hay.Si hay colisión,no se realizará el movimiento.
4-La subrutina de colisión hará lo siguiente:
 4.1-Se moverá el collider en la dirección del movimiento.Se guarda la posición antes del movimiento ya que si hay colisión,el collider volverá a su posicion
 4.2-Obtener la línea y columna en la VRAM de la esquina superior izquierda del collider.
 4.3-Segun el movimiento,se calculará la línea/columna final que tenemos que comprobar.Por ejemplo, si el movimiento es hhacia arriba,tenemos que rastrear la fila de la posición del collider entre la columna del vértice superior izquierdo hasta la del vértice superior derecho.Esto se obtiene sumando a la X del collider la anchura del collider (que es una CONSTANTE que depende de cada personaje,al igual que los offsets del vértice superior izquierdo del collider)
 4.4-Mediante un PLOT que parte de la línea y columna del vértice superior izquierdo y un CHRIN,haremos un bucle incrementando la línea/columna en 1 hasta llegar la límite fijado por la anchura/altura del collider.P.ej. si nos movemos hacia arriba,haremos el bucle desde la línea/columna del vértice superior izquierdo del collider hasta la columna del vértice superior derecho,barriendo todas las columnas intermedias.
 4.5-En caso de colisión contra un CHAR pared,se sale del bucle,se hace un SEC y se sale de la rutina de colisión.NO OLVIDAR asignar al collider su posición inicial....más adelante,haré que se rastreen todas las posiciones,ya que molaría poner "obstáculos mortales" y cosas así...
 4.6-Si no hay colisión,se deja el collider en la posición y se sale de la rutina con CLC.

Este proceso se lleva a cabo dentro de la ejecución normal del programa, ya que es caro para hacerlo en la interrupción.En la interrupción,la animación direccional funcionará pero el movimiento se restringirá por las paredes (es un efecto buscado....me gusta que el personaje resbale andando hacia la pared)
Además, lo que me gusta es que el collider(que es invisible) se mueve primero para chequear si la posición está libre,por lo que no se verían rebotes del Sprite. Lo "malo" es que los chars de  las paredes van a tener que ocupar como mínimo un espacio de 8*8 para evitar colisiones contra el aire....

Que os parece? Se admiten sugerencias!
Título: Re:Mini proyecto escuela
Publicado por: PacoBlog64 en Abril 03, 2022, 20:51:06
Ayer por fin tuve algo de tiempo e hice pruebas de colisiones
Conseguí abrir la pantalla como fichero lógico con CHKIN y OPEN,y obtener un char de pantalla usando PLOT y CHRIN.
Como obtener las líneas/columnas ocupadas por el collider es una operación "barata",creo que voy a usar este sistema y dejar al Kernal que haga el trabajo sucio.Este es el esquema del proceso de detectar colisiones.

1-Abrir el fichero lógico de la pantalla al iniciarse un escen de "acción".Habrá que cerrarlo y abrir el del teclado cuando te maten
2-Al hacer un Spawn de jugador/enemigo se asignará la posición del collider.Esto nos evitará calcularla,aunque habrá que crear una nueva tabla con las posiciones de los colliders.
...

Pues no te sé decir, la verdad, ya que hasta ahora siempre he usado la detección de colisión por hardware entre sprites (para sprites-chars aún no lo he necesitado). Cuando hablas de CHKIN, PLOT, CHRIN y OPEN ¿te refieres a funciones del kernal ROM?
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 03, 2022, 21:22:23
Pues no te sé decir, la verdad, ya que hasta ahora siempre he usado la detección de colisión por hardware entre sprites (para sprites-chars aún no lo he necesitado). Cuando hablas de CHKIN, PLOT, CHRIN y OPEN ¿te refieres a funciones del kernal ROM?

Si, son las funciones del Kernal.

No te hace falta ver colisiones contra fondo? Y como haces paredes,suelos,platformas,etc?
Título: Re:Mini proyecto escuela
Publicado por: PacoBlog64 en Abril 03, 2022, 22:59:09
Si, son las funciones del Kernal.

No te hace falta ver colisiones contra fondo? Y como haces paredes,suelos,platformas,etc?

Para lo que estoy haciendo ahora (https://www.pacoblog64.com/2020/05/desarrollo-de-street-fighter-2-champion.html (https://www.pacoblog64.com/2020/05/desarrollo-de-street-fighter-2-champion.html)) no lo necesito, los luchadores no interactúan con el escenario, sólo entre ellos. Actualmente leo el valor de $d01e y de ahí saco las colisiones entre los 4 sprites de un luchador y los 4 del otro.
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 00:25:15
Yeah! Vaya pintaza!Nada menos que el Street Fighter. 2....

Yo por ahora no aspiro a tanto.

Ya....entiendo que no necesitas interacción con fondo porque es de visión lateral y solo hay un suelo....te haría falta interacción con fondo si hubiera plataformas a las que subir y si no recuerdo mal el SF2 no las tenía.
Pero si las hubiera,entiendo que no te quedaría otra que comprobar el fondo....o hay otra manera y me estoy complicando la vida?

Saludos
Título: Re:Mini proyecto escuela
Publicado por: josepzin en Abril 04, 2022, 01:18:12
@darro99 seguro que puede responder.
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 02:33:47
https://youtu.be/UbsD0pWY6L8

Implementados los colliders y funcionan....a medias
Despues de volverme loco todo el día intentando leer los caracteres de la pantalla tratada como un fichero lógico me di cuenta de que si hago esto,tengo que poner la dirección de memoria $288 (high byte de la VRAM) en $48, ya que aunque cambies la ubicación en el VIC,esto no cambia y al abrir el fichero de la pantalla lo que estaba haciendo era leerme l pantalla en $0400

Por lo demás va bien,salvo que el muro de la derecha lo atraviesas....creo que es porque en vez de detectar el char de la pared,CHRIN me está devolviendo un retorno de carro ;D....algo así debe estar pasando porque miro la memoria en $4800 y está l pared con el CHAR correcto.No le veo otra explicación,aunque soy todavía un novato en esto y lo más seguro es que se me esté pasando algo más ...
Me refuerzo en esta teoría por otro detalle....si pongo al macaco en la esquina inferior derecha,la pantalla hace un scroll extraño.Creo que al tratar la pantalla como un fichero lógico,sigue avanzando aunque no hay nada más.
En fin,que parece que ni Dios me libra de hacer la rutina de conversión de filas/columnas  a direcciones de memoria de la VRAM
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 02:35:24
@darro99 seguro que puede responder.
Gracias josepzin! Le preguntaré a @darro99
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 12:53:12
Cita de: SingletonJohn
En fin,que parece que ni Dios me libra de hacer la rutina de conversión de filas/columnas  a direcciones de memoria de la VRAM

Bueno....puede ser despiste de la modificación tras copiar-pegar....a ver si tengo tiempo y lo reviso!

Diossss!Que vicio le estoy pillando al ensamblador! ;D ;)
Título: Re:Mini proyecto escuela
Publicado por: josepzin en Abril 04, 2022, 14:28:59
https://youtu.be/UbsD0pWY6L8

Va mejorando esto eh!

El otro que toca estos temas es @Dozznar pero ahora está subido al carro de la fama asi que no creo que responda.
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 15:16:41
Va mejorando esto eh!

El otro que toca estos temas es @Dozznar pero ahora está subido al carro de la fama asi que no creo que responda.

 ;D ;D ;D Gracias de nuevo @josepzin!
Título: Re:Mini proyecto escuela
Publicado por: Dozznar en Abril 04, 2022, 15:22:12
...Teniendo en cuenta que aquí se está hablando de ensamblador igual el que tengo que aprender  algo soy yo  :P

Para el sprite sprite por Software encontré algo aquí que me sirvió

https://codebase64.org/doku.php?id=base:simple_software_sprite_to_sprite_collision

Es sencilla pero efectiva siempre que los dos sprites sean de tamaño igual o similar.

Aquí tengo mi traducción a "C"
S0X,S0Y son las coordenadas del prota.
S1X,S1Y Las del sinver.

Asignando valores a CX1,CX2,CY1,CY2.  Como se ve en el ejemplo, ajustamos el tamaño del cuadrado imaginario dentro del sprite donde queramos que haya "HIT"
La sencilla comparación de la última línea hace el trabajo

void __fastcall__ CheckSprColl(void){

   CX1=S0X-8;
   CX2=S0X+8;
   CY1=S0Y-8;
   CY2=S0Y+8;
   if (S1X>CX1&&S1X<CX2&&S1Y>CY1&&S1Y<CY2) HIT();
}
Título: Re:Mini proyecto escuela
Publicado por: Dozznar en Abril 04, 2022, 15:31:14
Para el tema Sprite con el fondo, la cosilla la tengo más elaborada....

-Hay que hacer como se comenta por aquí una traducción entre las coordenadas de sprite y las de Caracteres.
-Como era una operación relativamente compleja y multiplicada por cuatro (cuatro puntos de colisión) por cada ciclo de gameloop tengo un par de truquillos.
   
      1-Precalculo y almaceno los valores de la conversión en dos vectores. Uno para X y otro para Y de manera que luego se pueda hacer una simple suma para la conversión
                       Sprite.CharPos=(P0Y[E0.Y])+P0X[E0.X];
     2.-Y en vez de hacer 4 cálculos con 8 tablas (4 para x y 4 para Y) Avanzo o retrocedo uno o dos caracteres (Dependiendo del tamaño del sprite) en la memoria de pantalla para calcular los 4 puntos de colisión
  Sprite.P0=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos);
  Sprite.P1=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos+1);
  Sprite.P2=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos-40);
  Sprite.P3=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos-39);

Esto tiene una pequeña pega y es que el diseño del sprite no puede ser de cualquier manera. Cuanto mas se ajuste el tamaño a múltiplos de 8, más precisa será la colisión.

Ufff. vaya mierda de explicación... Cualquier cosa me decís e intento aclararlo con más ejemplos

Tened en cuenta que tengo que recurrir a estos trucos por la lentitud de "C". Quizás en ensamblador no hace falta tanto lío.

     



Título: Re:Mini proyecto escuela
Publicado por: Dozznar en Abril 04, 2022, 15:45:44
A ver si tengo calma para leerme el hilo completo y ver tranquilo los videos (He visto el último un poco a la carrera pero pinta muy bien)
Encantado de ayudar y aprender. A ver si puedo dar el gran salto algún día (a assembler claro)

Salu2
Título: Re:Mini proyecto escuela
Publicado por: PacoBlog64 en Abril 04, 2022, 16:26:31
Ya....entiendo que no necesitas interacción con fondo porque es de visión lateral y solo hay un suelo....te haría falta interacción con fondo si hubiera plataformas a las que subir y si no recuerdo mal el SF2 no las tenía.
Pero si las hubiera,entiendo que no te quedaría otra que comprobar el fondo....o hay otra manera y me estoy complicando la vida?

No, en el SF2 como mucho se podía romper alguna caja o algún letrero al caer tras un golpe y poco más, pero yo no lo he implementado. Si tuviese elementos en el fondo tampoco podría tirar de colisiones sprite-char por hardware porque el fondo está hecho en modo bitmap, tendría que comprobarlo con una solución similar a la tuya. Es lo que dices, en juegos de otro tipo (plataformas, shooters) es lo habitual.
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 16:54:11
-Como era una operación relativamente compleja y multiplicada por cuatro (cuatro puntos de colisión) por cada ciclo de gameloop tengo un par de truquillos.
   
      1-Precalculo y almaceno los valores de la conversión en dos vectores. Uno para X y otro para Y de manera que luego se pueda hacer una simple suma para la conversión
                       Sprite.CharPos=(P0Y[E0.Y])+P0X[E0.X];
     2.-Y en vez de hacer 4 cálculos con 8 tablas (4 para x y 4 para Y) Avanzo o retrocedo uno o dos caracteres (Dependiendo del tamaño del sprite) en la memoria de pantalla para calcular los 4 puntos de colisión
  Sprite.P0=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos);
  Sprite.P1=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos+1);
  Sprite.P2=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos-40);
  Sprite.P3=*((unsigned char*)ADDR_MATERIAL_RAM+Sprite.CharPos-39);


Yo uso otro "truquillo"....no me hace falta ver si hay algún CHAR bajo la totalidad del collider, sólo lo que entra por cada cara del collider en la dirección del avance.
Es decir, si el collider es rectangular, sólo necesito saber lo que entra por el lado derecho cuando voy a la derecha, el de abajo cuando voy hacia abajo, etc....
Como esto no es una operación demasiado pesada, me guardo sólo las coordenadas de la esquina superior izquierda del collider y aplicando la anchura y la altura, no es complicado hacer la conversión para dos vértices.
Además de los dos vértices a calcular, sólo necesito tres datos (ya que al ser el collider rectangular comparten una coordenada).Calculando la fila/columna común y restando la fila/columna distinta, ya tengo unas coordenadas de INICIO de la VRAM a rastrear y luego voy en un loop en saltos de 8 (tantos saltos como el resultado de la resta de fila/columna distinta)...
...jajajajaa!!! Esto es más difícil de explicar que de ver
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 17:00:33
Estas son las rutinas de conversión que utilizo:
1-De (x,y) a (columna,fila) en la VRAM->
         Fila         = 3 LSR(Y-$32)
         Columna = 3 LSR(X-$18)
2-De (columna,fila) a dirección de memoria en VRAM
         DIR MEM = VRAM BASE + 3ASL (Fila) + 5 ASL (Fila) + Columna

Si pasara directamente de (x,y) a DIR MEM VRAM, la operación es muy sencilla ya que hay que hacer (y-$32) y quitarle los bits 0,1,2 y sumarlo a eso rotado dos veces a la izquierda y luego sumarle la columna ( 3 LSR(x-$18))....la verdad es que las matemáticas binarias me molan un montón!
Título: Re:Mini proyecto escuela
Publicado por: Dozznar en Abril 04, 2022, 17:05:49
Yo uso otro "truquillo"....no me hace falta ver si hay algún CHAR bajo la totalidad del collider, sólo lo que entra por cada cara del collider en la dirección del avance.
Es decir, si el collider es rectangular, sólo necesito saber lo que entra por el lado derecho cuando voy a la derecha, el de abajo cuando voy hacia abajo, etc....
Como esto no es una operación demasiado pesada, me guardo sólo las coordenadas de la esquina superior izquierda del collider y aplicando la anchura y la altura, no es complicado hacer la conversión para dos vértices.
Además de los dos vértices a calcular, sólo necesito tres datos (ya que al ser el collider rectangular comparten una coordenada).Calculando la fila/columna común y restando la fila/columna distinta, ya tengo unas coordenadas de INICIO de la VRAM a rastrear y luego voy en un loop en saltos de 8 (tantos saltos como el resultado de la resta de fila/columna distinta)...
...jajajajaa!!! Esto es más difícil de explicar que de ver

mmmm. Muy interesante. Me lo apunto para probar. Parece más óptimo que lo que yo hago. Ya te contaré  ;)
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 17:07:36
mmmm. Muy interesante. Me lo apunto para probar. Parece más óptimo que lo que yo hago. Ya te contaré  ;)
Sólo hay que tener en cuanta una cosa.....que los sprites no sean muy rápidos, ya que podrías atravesar alguna pared)....en mi caso de miniproyecto todos los avances son pixel a pixel, por lo que está el control asegurado
Título: Re:Mini proyecto escuela
Publicado por: Dozznar en Abril 04, 2022, 17:08:11
Estas son las rutinas de conversión que utilizo:
1-De (x,y) a (columna,fila) en la VRAM->
         Fila         = 3 LSR(Y-$32)
         Columna = 3 LSR(X-$18)
2-De (columna,fila) a dirección de memoria en VRAM
         DIR MEM = VRAM BASE + 3ASL (Fila) + 5 ASL (Fila) + Columna

Si pasara directamente de (x,y) a DIR MEM VRAM, la operación es muy sencilla ya que hay que hacer (y-$32) y quitarle los bits 0,1,2 y sumarlo a eso rotado dos veces a la izquierda y luego sumarle la columna ( 3 LSR(x-$18))....la verdad es que las matemáticas binarias me molan un montón!

Y ésto también tiene buena pinta. Lo estudio.
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 17:12:25
Cuando revise bien mis rutinas y las simplifique un poco y las ordene, a ver si cuelgo los SEQ files.....por ahora me da un poco de verguenza enseñar el caos organizado que tengo montado  ;D ;D ;D
Título: Re:Mini proyecto escuela
Publicado por: darro99 en Abril 04, 2022, 18:36:50
Hola a todos.

Citar
Gracias josepzin! Le preguntaré a @darro99

Escribo lo que yo hago para obtener los caracteres que tengo a derecha e izquierda del personaje y así saber en que plataforma/suelo/lugar de la pantallas te encuentras.

- Primeramente tengo dos direcciones en la pagina cero que contienen las coordenadas x e y del personaje. Estas 'variables' con fáciles de calcular al principio de la generación del nivel pues sabes de antemano donde vas a colocar al personaje.
Esta nomenclatura es de Kickass, es como una estructura de datos que puedes encontrar en cualquier lenguaje como C por ejemplo:
Código: [Seleccionar]
namespace vars_player{
.label pant_y = $46 //Coordenada y del juagador en la pantalla de caracteres
.label pant_x = $47 //Coordenada y del juagador en la pantalla de caracteres
}
Aquí solo se declara estos nombres asignados a las paginas cero $46 y $47.

- También debemos declarar un puntero a la pantalla para una vez obtenida la dirección de la misma poder recoger su valor.
Código: [Seleccionar]
namespace paint{
.label dir_pant = $48 //Esta dirección realmente son dos, $48 y $49 pues es un puntero, y necesitamos dos bytes.
}

- Por último también definimos un lista con las direcciones altas y bajas de cada una de la lineas de la pantalla.
Código: [Seleccionar]
tabla_screen_lo:
  .byte [ SCREEN_CHAR +   0 ] & $00ff
  .byte [ SCREEN_CHAR +  40 ] & $00ff
  .byte [ SCREEN_CHAR +  80 ] & $00ff
  .byte [ SCREEN_CHAR + 120 ] & $00ff
  .byte [ SCREEN_CHAR + 160 ] & $00ff
  .byte [ SCREEN_CHAR + 200 ] & $00ff
  .byte [ SCREEN_CHAR + 240 ] & $00ff
  .byte [ SCREEN_CHAR + 280 ] & $00ff
  .byte [ SCREEN_CHAR + 320 ] & $00ff
  .byte [ SCREEN_CHAR + 360 ] & $00ff
  .byte [ SCREEN_CHAR + 400 ] & $00ff
  .byte [ SCREEN_CHAR + 440 ] & $00ff
  .byte [ SCREEN_CHAR + 480 ] & $00ff
  .byte [ SCREEN_CHAR + 520 ] & $00ff
  .byte [ SCREEN_CHAR + 560 ] & $00ff
  .byte [ SCREEN_CHAR + 600 ] & $00ff
  .byte [ SCREEN_CHAR + 640 ] & $00ff
  .byte [ SCREEN_CHAR + 680 ] & $00ff
  .byte [ SCREEN_CHAR + 720 ] & $00ff
  .byte [ SCREEN_CHAR + 760 ] & $00ff
  .byte [ SCREEN_CHAR + 800 ] & $00ff
  .byte [ SCREEN_CHAR + 840 ] & $00ff
  .byte [ SCREEN_CHAR + 880 ] & $00ff
  .byte [ SCREEN_CHAR + 920 ] & $00ff
  .byte [ SCREEN_CHAR + 960 ] & $00ff
tabla_screen_hi: 
  .byte [ [ SCREEN_CHAR +   0 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR +  40 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR +  80 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 120 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 160 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 200 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 240 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 280 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 320 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 360 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 400 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 440 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 480 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 520 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 560 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 600 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 640 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 680 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 720 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 760 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 800 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 840 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 880 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 920 ] & $ff00 ] >> 8
  .byte [ [ SCREEN_CHAR + 960 ] & $ff00 ] >> 8
Donde SCREEN_CHAR es una constate que contiene el inicio de la pantalla. En mi caso es la dirección $4400

Función que recoge el carácter a la derecha del jugador:
Código: [Seleccionar]
getCaracterDer:
ldy vars_player.pant_y
lda tabla_screen_lo,y
sta paint.dir_pant
lda tabla_screen_hi,y
sta paint.dir_pant + 1

ldy vars_player.pant_x
iny
lda (paint.dir_pant),y

Lo que se hace es cargar el puntero dir_pant con las coordenadas prefijadas del personajes gracias a la tabla de direcciones. Una vez cargado el puntero con la linea correspondiente que nos marca pant_y podemos recoger el desplazamiento sobre esta dirección con pant_x con el direccionamiento indirecto.
Al final de la función obtenemos en el acumulador el carácter que marcaban las coordenadas pant_y/pant_x.

Espero que esto sirva de algo.
Salu2!
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 20:03:06
Espero que esto sirva de algo.
Salu2!

Gracias @darro99!

Toda ayuda es poca
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 04, 2022, 20:06:33
Estas son las rutinas de conversión que utilizo:
1-De (x,y) a (columna,fila) en la VRAM->
         Fila         = 3 LSR(Y-$32)
         Columna = 3 LSR(X-$18)
2-De (columna,fila) a dirección de memoria en VRAM
         DIR MEM = VRAM BASE + 3ASL (Fila) + 5 ASL (Fila) + Columna
Ahora viene lo bueno!

DIR MEM = VRAM BASE  + 3ASL(3LSR(Y-$32)) + 5ASL(3LSR(Y-$32)) + 3 LSR(X-$18) =
              = VRAM BASE  + [(Y-$32) AND $F8] + 2ASL[(Y-$32) AND $F8] + 3 LSR(X-$18)

La operación queda bastante simple...dos restas y tres rotaciones
 Sólo  hay que tener en cuenta las limitaciones a meter (por ejemplo, si queréis tener el Sprite siempre totalmente visible....o si queréis que atraviese los borde tipo Pacman, etc)
 Lo que está claro con esta fórmula es que
          Y>= $32
          X>= $18,
ya que una X = $17 está en el borde izquierdo de la pantalla...esto no es muy complicado comprobando BCS tras las restas
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 12, 2022, 00:53:12
https://youtu.be/UfkPOYDMRdQ

Ya he conseguido hacer que las colisiones con fondo funcionen bien!
Desistí de la técnica de leer en el fichero lógico de la pantalla y ahora todo va ok después de unos cambios!  ;D

Ahora,antes de meterme en el siguiente fregao voy a ordenar y simplificar todo un poco....creo que si guardo las coordenadas de la esquina superior izquierda e inferior derecha del collider box (y varío las coordenadas con las rutinas de movimiento) voy a ganar bastante espacio y velocidad.

Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 12, 2022, 01:06:43
Creo que después me meteré con temas de raster, que de vez en cuando hay un parpadeo en los sprites.

Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 12, 2022, 09:01:57
Como las Subrutinas de mover colliders y comprobar colisiones son casi idénticas en los desplazamientos verticales y horizontales, igual pruebo a cambiar las instrucciones en que se diferencian desde dentro del propio programa....a ver si con eso ahorro espacio también! ;)
Es decir,según la dirección de avance, el programa modificaría las instrucciones propias del desplazamiento en concreto (pondría etiquetas en ellas para hacer el cambio) y solo tendría una o dos Subrutinas con todo el código en común. Me ahorro dos o tres Subrutinas con cierta extensión!
Título: Re:Mini proyecto escuela
Publicado por: josepzin en Abril 13, 2022, 19:34:08
Lo del fondo va perfecto, al pixel!

En los lenguajes de alto nivel lo ideal siempre es tener rutinas genéricas, pero ensamblador es hijo de su padre Código Máquina y allí rigen otras reglas, igual yo creo que vas muy bien, asi visto desde afuera :P
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Abril 13, 2022, 20:07:32
Lo del fondo va perfecto, al pixel!

Uso otro "truco"  ;) .... Muevo primero el collider box (antes que el personaje) y si hay colisión, lo devuelvo a su posición inicial y se abandona la rutina del movimiento. No espero a tener una colisión para luego mover personaje y collider a la posición anterior....

Si se chocara contra algo mortal, haría el movimiento como si nada y el personaje moriría en el siguiente frame...esto aún lo estoy dando vueltas
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Octubre 02, 2022, 09:22:48
Hola a todos!

Por motivos personales y de tiempo tengo esto bastante en stand y....espero dedicarle el tiempo que se merece próximamente. :()
Título: Re:Mini proyecto escuela
Publicado por: Dashiad en Octubre 02, 2022, 22:54:32
Sólo hay que tener en cuanta una cosa.....que los sprites no sean muy rápidos, ya que podrías atravesar alguna pared)....en mi caso de miniproyecto todos los avances son pixel a pixel, por lo que está el control asegurado
Si en vez de posicionar las bounding boxes a partir de donde están los sprites, lo haces al revés (posicionar los sprites a partir de donde están las bounding boxes), puedes mover y colisionar las bounding boxes (a la velocidad que sea), sin ligarlo a la velocidad que puedas repintar.
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Octubre 14, 2022, 16:51:56
Hola @Dashiad !

Pero el problema lo tienes igual no?....me refiero a que los bounding también tendrán una velocidad en pixels por unidad de tiempo.

no es exactamente un problema de repintado.Lo tengo desligado de las colisiones para evitar que los sprites "vibren" al chocar....es decir,varío las coordenadas del collider en una tabla,y si choca lo pongo "a ras" del obstáculo y detrás va el Sprite....cuando están los cálculos hechos,pongo un flag en true para que lo pinte el raster
Si la velocidad fuera algo mayor que la anchura/altura del collider, podrías atravesar ciertos obstáculos.....
Pensaré en lo que dices y probaré.
Tb había pensado alargar los colliders en la dirección del movimiento para velocidades muy rápidas....aunque igual queda mal moverse tantos píxeles por fame....
Título: Re:Mini proyecto escuela
Publicado por: Dashiad en Octubre 14, 2022, 20:35:51
Si algo se mueve a 3 pixels por frame, y el pintado = movimiento, puedes atravesar cosas.
Pero si lo separas,  el movimiento y las colisiones se pueden calcular varias veces por frame de repintado.
Esto lo puedes hacer en terminos de "pixeles" (moviendo 3 veces 1 pixel), o por trigonometría (intersecciones de lineas, etc), depende del caso.
Por ejemplo, en un "Pong", si la pelota se mueve 5 pixeles por frame, y en un frame determinado la pelota está a 1 pixel de tocar una de las raquetas, en el siguiente repintado hay que haber hecho la colisión, rebotar la pelota, y moverla. Para hacer eso, la posición de los objetos no se obtiene de la posición de los "sprites", sino al revés. Los "objetos" del juego se mueven, colisionan, tienen efectos, y cada X tiempo, se pintan.
Es como si en el bucle de juego, la entrada se evaluara 1 vez, el movimiento y colisiones se evaluaran X veces, y luego se pintara 1 sola vez.
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Octubre 17, 2022, 23:23:04
Es como si en el bucle de juego, la entrada se evaluara 1 vez, el movimiento y colisiones se evaluaran X veces, y luego se pintara 1 sola vez.
Muchas gracias por los detalles @Dashiad !!! ;D
Ciertamente no se me había ocurrido mover un objeto varias veces y comprobar varias veces las colisiones entre repintados
Entre repintado y repintado estaba dejando descansar al procesador porque aún me quedaban meter cosas como el sonido y tb hacer pruebas con el scroll.
Pero lo que cuentas tiene más sentido que comprobar colisiones 1 vez,mover y esperar el barrido...

Gracias de nuevo!
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Noviembre 12, 2022, 13:47:22
Hola a todos de nuevo!
@Dashiad, he estado probando desvincular del todo el movimiento del repintado y ahora lo que me pasa es que la velocidad de los sprites es inestable.....supongo que haciendo el movimiento a través de una interrupción esto mejorará bastante.
Haré una interrupción que dure 1/3 de frame para evaluar posiciones y colisiones a ver qué tal resulta!.Evitaré que coincidan cálculos y repintados jugando con los relojes

Como lo véis?Os parece buena solución?
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Noviembre 12, 2022, 13:51:28
También os tengo que contar que todo el programa que tenía hecho de los monstruitos se me fastidió :(.....solo pude salvar los Sprites y las pantallas.
La verdad es que la emulación de la disketera del C64 Maxi me falla bastante,y eso que la tengo en accurate....
En fin,ahora estoy haciendo un Pong para jugar con mis hijos y probar cosas
Saludos!
Título: Re:Mini proyecto escuela
Publicado por: Dashiad en Noviembre 12, 2022, 14:04:53
Posiblemente, todo el bucle principal del juego debería ser disparado por la interrupción...Lo anterior debería hacer el movimiento más estable, no al revés.
De la lista de cosas  a hacer en cada bucle, hay cosas que tienen un tiempo constante (leer la entrada del usuario, tocar musica), y otras que tienen un tiempo variable (mover, actualizar estado del juego) y otras que podrian ser opcionales (pintar).
Si primero haces las que requieren un tiempo constante y luego haces las de tiempo variable, puedes mirar el registro de la linea de raster, para saber si aún te queda tiempo para pintar en ese frame.
Si te queda tiempo, pintas. Si no, podrías incrementar una variable de "frameSkip".
Si al principio del bucle, "frameSkip" está,por ejemplo, a 3, durante ese bucle, sólo haces las tareas de tiempo constante, y el repintado (te saltas actualizar el mundo).
Así, aunque haya fases del juego donde hay más objetos a actualizar, o más cálculo que hacer, el juego perderá frames, o el movimiento dará un parón, pero el juego sigue "bajo control".
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Noviembre 12, 2022, 15:02:40
Gracias de nuevo @Dashiad !
Tiene todo el sentido del mundo lo que dices y me pondré a ello.
Estoy dándole vueltas y en un juego como el Pong,lo fundamental es que la pelota vaya finísima,si no es un horror.
Con lo cual la pelota debe ir por encima de todo lo demás
El resto de cosas son muy sencillas y si esperan un frame ni se nota.
La cosa sería poner el movimiento de la bola por interrupciones(asegurando que no se superponga con el repintado,que iría con VSync a 60 por segundo.El sonido tb se podría meter aqui
 El resto de cosas(palas y obstáculos móviles)creo que irían bien en un bucle "normal"
Es más....el movimiento de la bola debería pasar por encima de todo(nmi?) Asegurándose de que no interrumpa nunca el VSync...con un Pong lo tendría facil
El movimiento de la bola es prácticamente de tiempo constante,salvo en los rebotes
Título: Re:Mini proyecto escuela
Publicado por: SingletonJohn en Noviembre 12, 2022, 15:39:59
Descarto lo de nmi para la bola....es una tontería y me daría problemas si quiero hacer un sei/cli