Autor Tema: El p*** salto  (Leído 8124 veces)

Laddh

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 233
    • Ver Perfil
El p*** salto
« en: Marzo 02, 2016, 11:17:09 »
Parecerá una tontería, pero me ha costado semanas dar con una rutina en la que controlar que el sprite saltara y volviera a su posición Y original, y no se fuera volando por la pantalla acumulando saltos. Al final me ha salido esto, código de el salto a la derecha:

 
Código: [Seleccionar]
V       = $D000
SALTODER LDA SWITCH ;PARA QUE NO VUELVA A SALTAR MIENTRAS ESTA
        CMP #1      ;EN UN SALTO Y SALGA VOLANDO
        BEQ FUERA
        LDA #195    ;QUE MIRE A LA DER
        STA 2040
        LDA V+1
        STA ACTUALV1 ;GUARDO POS V+1
        LDX #25      ;BUCLE PARA EL SALTO
        LDA #1
        STA SWITCH
G1      lda #12 ; RASTER PARA MOVIMIENTO FLUIDO
        cmp $d012
        bne G1
        DEC V+1 ;SALTA
        INC V
        JSR TESTX ;TESTEA SI + DE 255
        DEX
        CPX #0
        BNE G1 ;ACABA BUCLE SALTO X=0
GG1     LDA V+1 ;VUEVE A V+1 INICIAL, QUE NO VUELE
        CMP ACTUALV1
        BNE GG1
        LDA #0 ;AHORA YA PUEDE VOLVER A SALTAR
        STA SWITCH
FUERA   RTS

Mi solución a sido meter ese conector SWITCH, para que no volviera a meterse en el salto mientras ya estaba en uno. Hala, ya tengo el salto para el próximo proyecto.

Arrancar con SYS2080 para verlo.

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 13630
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:El p*** salto
« Respuesta #1 en: Marzo 02, 2016, 11:45:19 »
Que sepas que cuando salta no valida los bordes :P
www.retroinvaders.com | www.commodoreplus.org  | josepzin.blogspot.com

Laddh

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 233
    • Ver Perfil
Re:El p*** salto
« Respuesta #2 en: Marzo 02, 2016, 12:16:54 »
Correcto, otra cosa a controlar, en el salto no respeta los limites pero será en la siguiente pelea. Esto es un no parar...

Maniako

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 1008
  • SYS 8*4096
    • Ver Perfil
Re:El p*** salto
« Respuesta #3 en: Marzo 02, 2016, 12:24:28 »
Para estos menesteres pongo a 1 una variable y mientras esa variable esté a 1, pasa de volver a empezar otro salto hasta que no se acabe el que está dando.

Cuando acaba el salto, la pongo a 0 y listo para otro salto.

No sé si es lo mismo.
LDA #$50
STA $0400
RTS
Lloré cuando conseguí hacer esto con el monitor del FC1.

Laddh

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 233
    • Ver Perfil
Re:El p*** salto
« Respuesta #4 en: Marzo 02, 2016, 12:38:23 »
Exactamente Maniako, hemos llegado a la misma conclusión.

pastbytes

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 556
  • SYS 0
    • Ver Perfil
Re:El p*** salto
« Respuesta #5 en: Marzo 02, 2016, 14:46:15 »
Hay que tener en cuenta que esta forma de codificar es muy limitada, por ejemplo, no permite poner musica durante el juego, o por lo menos no sin interferencias entre las dos rutinas, y una cosa que es mas evidente, mientras se ejecuta el salto los enemigos y el resto del codigo del juego quedarian congelados.
Nunca hice un juego en C64, pero me parece que lo normal es tener variables y banderas de estado, y poner todo el codigo del juego en la rutina de interrupcion que se llame una vez por cuadro (50 o 60 veces por segundo). Lo ideal es que el codigo comience a ejecutarse una vez que empieza el borde inferior de la pantalla, para tener la mayor cantidad de tiempo de ejecucion libre de interrupciones del VIC. Luego puede ser que uno agregue codigo que se ejecute durante el dibujado de la imagen, o durante el borde lateral, pero eso ya depende de cada juego.
Lo que se haria es basicamente renderizar la imagen justo antes de que se dibuje cada cuadro, por lo que en este caso particular habria que chequear una bandera para saber si estamos en un salto, y tendriamos un contador que nos dice en que paso del salto estamos, que podria traducirse como en que cuadro de animacion del salto estamos. Se podria tener una tabla en X y en Y con las diferencias de coordenadas a sumar o restar al sprite, por ejemplo digamos que el salto tiene 20 cuadros, hariamos una tabla donde en el paso 1 (el paso 0 es la posicion original) podriamos poner 2,2 (significa que si estamos en el paso 1, sumamos 2 en X y 2 en Y a las coordenadas del sprite), en el paso 2 podria ser 3,2 (avanzamos 3 en X y 2 en Y), y asi con los 20 cuadros. Cuando llegamos a la rutina de interrupcion, preguntamos si estamos en un salto, vemos el numero de cuadro en una variable, y segun ese numero saltamos a la posicion correspondiente de la tabla (se puede usar el registro X o Y para acceder a la posicion de memoria del elemento por direccionamiento indirecto). Leemos los valores de la tabla y sumamos las coordenadas (se puede tener dos tablas para X e Y, o colocar pares de coordenadas en la tabla), luego incrementamos en 1 unidad el numero de cuadro del salto, si llegamos a 20, apagamos la bandera que indica que estamos en un salto.
De esta manera se hace todo en multitarea, no frenamos el resto del codigo mientras ejecutamos el salto, y ademas al tener una tabla, podemos hacer saltos bastante elaborados, incluso acrobaticos. El refinamiento que le quedaria a eso es hacer que el salto sea mas lento, porque puede ser que el personaje se quede mas de un cuadro de imagen en la misma posicion, y no tiene sentido andar repitiendo coordenadas. Lo que se podria hacer es agregar un contador extra que decrementamos luego de procesar un cuadro del salto, si este contador llega a 0, ahi recien decrementamos el numero de cuadro del salto. Por ejemplo podriamos bajar la velocidad del salto a la mitad, esto es que cada 2 cuadros de imagen se avanza un cuadro de la animacion del salto. Lo que hariamos es preguntar si estamos en el salto, si es asi, buscamos el numero de cuadro del salto, sumamos las coordenadas como ya vimos, y luego decrementamos el contador de velocidad de salto, que vale 2 y pasa a valer 1, como no llego a 0, aqui terminamos el proceso del salto. En la proxima interrupcion de video, otra vez procesamos el salto como ya lo hicimos, y las coordenadas van a ser las mismas, porque no avanzamos el numero de cuadro del salto, luego decrementamos el contador de velocidad del salto, que era 1 y ahora pasa a ser 0, como es 0 esta vez si incrementamos el numero de cuadro del salto (por lo que en la proxima interrupcion si van a cambiar las coordenadas), y ponemos el contador de velocidad del salto a 2 nuevamente. De esta manera cada par de coordenadas de la tabla se va a repetir en 2 cuadros de imagen y la velocidad del salto es la mitad.
« última modificación: Marzo 02, 2016, 14:48:28 por pastbytes »

Maniako

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 1008
  • SYS 8*4096
    • Ver Perfil
Re:El p*** salto
« Respuesta #6 en: Marzo 02, 2016, 15:35:13 »
Y la europea?
LDA #$50
STA $0400
RTS
Lloré cuando conseguí hacer esto con el monitor del FC1.

Maniako

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 1008
  • SYS 8*4096
    • Ver Perfil
Re:El p*** salto
« Respuesta #7 en: Marzo 02, 2016, 15:44:23 »
Dejando de lado mis tonterías  ;D, prefiero usar una tabla para el salto. Queda más bonito un salto arqueado que uno en diente de sierra.

Se agradecen estos consejos , siempre es bueno ir aprendiendo .
LDA #$50
STA $0400
RTS
Lloré cuando conseguí hacer esto con el monitor del FC1.

pastbytes

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 556
  • SYS 0
    • Ver Perfil
Re:El p*** salto
« Respuesta #8 en: Marzo 02, 2016, 15:51:17 »
Ademas de que queda mejor, el asunto es que se puede hacer otras cosas a la vez. Un ejemplo extremo podria ser el bomb jack, o cualquier juego de plataformas donde caemos lentamente y podemos dirigir la caida, o incluso disparar o frenar la caida (en el bomb jack). Si quisieramos que los enemigos siguieran caminando durante el salto, tendriamos que llamar al codigo del juego durante el bucle del salto, y puede que mientras saltemos los enemigos corran a distinta velocidad. Y si nos matan durante el salto se complicaria mas aun.

Laddh

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 233
    • Ver Perfil
Re:El p*** salto
« Respuesta #9 en: Marzo 02, 2016, 15:52:14 »
Hola pastbytes, interesante lo que comentas aunque al principio de leer no sabía si me respondías o te habías equivocado de hilo. En lo que he hecho hasta ahora no he utilizado nunca tablas, aunque creo entender por lo que dices que una vez implementada puede facilitar las cosas, de momento lo hago más "realtime", aunque me apunto estudiar hacer las cosas con tablas.
Disiento en lo que no permite música y movimiento de enemigos, te adjunto un nuevo prg que muestra la misma rutina con música y enemigos sin interferencias.
No creo que un juego de C64 completo pueda caber en una sola interrupción, pero bueno es cuestión de probar cosas.
Y ahora voy a leerme unas cuantas veces más lo que has escrito, creo que tiene jugo.

Un saludo.

pastbytes

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 556
  • SYS 0
    • Ver Perfil
Re:El p*** salto
« Respuesta #10 en: Marzo 02, 2016, 16:16:55 »
Ahi parece que ejecutas codigo principal para el movimiento del protagonista, y codigo en interrupcion para los enemigos. Cuando tengas que hacer que los enemigos salten y caminen, vas a tener que codificar como te explique antes.
En cuanto a la musica, todo depende de que se sincronice bien con el resto del codigo, supongo que la rutina de la musica se ejecuta durante el borde y termina antes de que le toque ejecutarse al bucle (porque te sincronizas con una linea determinada del video), imagino que habras probado distintas lineas hasta eliminar la interferencia.
Por otro lado, el movimiento del personaje no se ve tan fluido porque parpadea, no se si es porque lo veo en VICE, pero da la impresion de que dibujas mas cuadros de los necesarios. Tambien cada tanto desaparece y aparece el sprite, cuando se lo deja sin mover.

Laddh

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 233
    • Ver Perfil
Re:El p*** salto
« Respuesta #11 en: Marzo 02, 2016, 16:25:28 »
Exacto, el loop es la rutina del joy que controla el sprite y todo lo demás por interrupciones. Sí, parpadea porque la línea del raster esta elegido al azar, al fin y al cabo solo es un ejercicio para practicar el salto, que como he comentado me ha costado un huevo conseguir, por eso he querido compartir mi logro.
Intentare conseguir el nivel de excelencia en el producto final ;)
Gracias y un saludo.

pastbytes

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 556
  • SYS 0
    • Ver Perfil
Re:El p*** salto
« Respuesta #12 en: Marzo 02, 2016, 17:03:59 »
Esta muy bien, no comentaba para desmerecer tu logro, despues de todo, yo ni siquiera hice algo asi en asm (todavia). Mis comentarios apuntaban a que no te compliques demasiado refinando ese codigo porque para un juego es mas conveniente implementar todo en la interrupcion. Por ejemplo, el salto en los enemigos va a tener que hacerse paso a paso como comentaba antes, y cuando tengas eso hecho te va a convenir reutilizar ese mismo codigo para mover el protagonista, en lugar de usar una rutina distinta. Pero para eso falta, solo me estaba adelantando.
En cuanto al codigo, se puede poner totalmente en la interrupcion, siempre que no superes los 20 milisegundos que hay entre un cuadro de imagen y el siguiente. No es necesario tener codigo fuera de la interrupcion, normalmente ese codigo se usa para tareas que no sean criticas en tiempo, que puedan ser interrumpidas por la rutina de interrupcion. No se me ocurre que podria hacerse ahi en un juego que no se pueda hacer durante la interrupcion, pero podria ser algun calculo, por ejemplo convertir el puntaje a caracteres decimales.
En un caso extremo, se tendria todo el juego ejecutandose durante los bordes, que es cuando el VIC no interrumpe al 6510, y el tiempo sobrante serian unos microsegundos por cada linea de imagen, se podria tener un programa principal fuera d ela interrupcion que ejecutara tareas de fondo, por ejemplo darle el puntaje, activar una bandera, y esperar a que el programa la vuelva a poner en 0 cuando termine de calcular o imprimir. En el codigo principal habria un bucle infinito, que chequearia distintas banderas para ver si tiene alguna tarea que realizar, si detecta la bandera de calculo de puntaje, empieza a procesarlo y cuando termina pone a 0 la bandera. Durante todo el tiempo de proceso ese programa seria interrumpido 50 veces por segundo por la rutina del juego, y tambien una vez por cada linea de barrido por el VIC, por eso se puede dejar el programa principal para tareas que no requieran tiempos criticos.

Maniako

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 1008
  • SYS 8*4096
    • Ver Perfil
Re:El p*** salto
« Respuesta #13 en: Marzo 02, 2016, 17:33:45 »
No creo que se haya molestado.

Aquí sin ir más lejos, reconozco que sé cosillas y he trasteado lo mio de más jovencito, pero la realidad es que hago 1000 rutinillas probando las más mínima chorradas que se me ocurren y si, me siento orgulloso de ellas por absurdas o sinsentido que sean puesto que cada una me ha ayudado a subir un escalón más.

Si algún forero me aclara, rectifica, modifica, aconseja, me muestra mejores formas de hacerlo o lo que sea, yo encantado de ello. Por eso me metí en este foro., para recibir latigazos y.... ejem, para recibir ayuda y de buén grado ;)
 
PD: Mi nivel de programador es de nadador estilo perrito usando símiles natatorios. ;D
LDA #$50
STA $0400
RTS
Lloré cuando conseguí hacer esto con el monitor del FC1.

Laddh

  • Desarrolladores
  • Commodore Master
  • ******
  • Mensajes: 233
    • Ver Perfil
Re:El p*** salto
« Respuesta #14 en: Marzo 02, 2016, 17:46:25 »
Como se dice por aquí.... AL HIERRO!!!!
El caso es sacar cosas nuevas.