¡¡Nuestro compañero Chema no está quieto!!

Avatar de Usuario
ron
Mensajes: 17175
Registrado: 28 Oct 2010 14:20
Ubicación: retrocrypta
Agradecido : 508 veces
Agradecimiento recibido: 532 veces

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor ron » 20 Mar 2014 18:25

Último mensaje de la página anterior:

o bien el cumulus o la controladora puesta !, yo tengo un interfaz de joystick que en su día me pasó Silicebit que va conectado al puerto de la impresora.

http://www.48katmos.freeuk.com/joy.htm

PASE interfaces
O.P.E.L Interface
Altai interface
Dktronics interface
Protek programmable interface
Downsway Programmable Interface
IJK and MCP interfaces

Avatar de Usuario
Silicebit
Mensajes: 1325
Registrado: 16 May 2011 21:13
Ubicación: La buhardilla del silicio.
Agradecido : 30 veces
Agradecimiento recibido: 78 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Silicebit » 21 Mar 2014 23:10

Chema escribió:El único problema que le veo al Protek es que usa el puerto de expansión. Los que tenemos cumulus lo tenemos ocupado :/

Por lo demás me gustaría ver como se las apaña para hacer su trabajo porque la interfaz son el teclado se las trae (se usa por un lado la VIA y por otro lado un puerto del AY). A ver si sólo va a funcionar si se usan las rutinas de teclado de la ROM...

Por eso las Microdisc originales vienen con un conector IDC macho en el cable, como podéis ver en las fotos AQUÍ, para no "perder" el conector de expansión. Creo que los Cumulus usan un cable de 80 hilos, así que con ellos no es posible el poner un conector de expansión adicional sobre el cable, sin embargo con el clon de la controladora sí. -grin

En cuanto saque el esquema se verá como funciona el invento, a ver como se las arregla para simular las pulsaciones del teclado.


ron escribió:o bien el cumulus o la controladora puesta !, yo tengo un interfaz de joystick que en su día me pasó Silicebit que va conectado al puerto de la impresora.

http://www.48katmos.freeuk.com/joy.htm

PASE interfaces
O.P.E.L Interface
Altai interface
Dktronics interface
Protek programmable interface
Downsway Programmable Interface
IJK and MCP interfaces

El que te pasé es un interfaz PASE, es el más simple de todos, sólo son unos diodos del tipo 1N4148. Lo malo de este interfaz es que corrompe el sonido, mientras que el IJK no.
El 6809 es el Rolls-Royce de los 8bits, el 6502 es el Mercedes, y el Z80 el SEAT 850. Sorry, but... I think different. :-P -0r1c -m3s3x -t4nd1 -cbmja YouTube

Avatar de Usuario
Chema
Mensajes: 1536
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 441 veces
Agradecimiento recibido: 186 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Chema » 22 Mar 2014 00:31

Qué guapa es la Microdisc!! Un Atmos con una a su lado es una pasada. No será el mejor equipo, pero compite en estilo con cualquiera, ¿no os parece?

Al mío le falta la pegatina con el logo.. Creo que vi una por ahí para imprimir y pegar, igual me lo hago...

Avatar de Usuario
Chema
Mensajes: 1536
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 441 veces
Agradecimiento recibido: 186 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Chema » 21 Abr 2014 13:33

Hola a todos.

He estado bastante desconectado de los foros últimamente (demasiado lío personal), pero que sepáis que sigo trabajando en este juego. Y he avanzado bastante. Hay muchos de los detalles que tenía en la lista ya resueltos, desde la redefinición de las teclas de juego, hasta selección del volumen para el sonido pasando por completar los power-ups, la pantalla de menú y añadir una opción para pausa. He metido algunos niveles algo "diferentes" por en medio, etc. Todo eso y perseguir y limpiar algunos bugs que me han traído de cabeza.

Prácticamente está en una versión alfa a puntito de convertirse en beta :) Tengo que completar algunos efectos, tocar un poco la IA de algún enemigo que me ha quedado a medias, añadir un límite al número de niveles (ahora no lo hay y no parece razonable), y esas cosas. No me he metido con el soporte de joystick aún (tengo que estudiar el tema) y me gustaría ver si puedo meter un "final boss", pero no es seguro.

De todas formas es perfectamente jugable y da una buena idea de cómo va a quedar al final. No creo que varíe mucho de como es ahora mismo. No os dejo un vídeo esta vez, para no desvelar más detalles :)

He enseñado el juego a un par de amigos (y a mi hijo) y lo encuentran en general adictivo y divertido. Pero alguna opinión menos positiva también he tenido, sobre todo aquellos que esperaban un mata-mata simplemente y la temática les despista un poco. Es claramente un mata-mata, pero el puzle (por llamarlo de algún modo) con los interruptores hace que tengas que buscar estrategias para progresar de la manera más eficiente posible.

Por ejemplo, al principio es muy sencillo, pero si te limitas a pasar los niveles sin recoger energía y objetos, lo haces rápidamente pero vas menos preparado para los niveles más difíciles (que llegan enseguida). Además cuando el puzle se complica un poco, es mejor pensar cómo resolverlo que dedicarte a pulsar interruptores sin ton ni son.

La cosa es que puedes progresar hasta el nivel 7 más o menos enseguida. Subir del 15 o así ya empieza a ser complicado (al menos para mí).

Y por ahí viene otra de las críticas que he recibido: puede resultar repetitivo. Yo no lo veo así, teniendo en cuenta lo que se puede hacer con este tipo de máquinas, pero claro para gustos...

Bueno que hacer una versión de un juego conocido al menos te asegura que los que lo encontraron divertido sigan haciéndolo. Hacer algo nuevo es mucho mucho más difícil.

A ver si preparo una versión de prueba y encuentro testers que quieran pegarse con él un poco en serio a ver qué ideas surgen.

Más noticias pronto (espero) :)

Avatar de Usuario
Silicebit
Mensajes: 1325
Registrado: 16 May 2011 21:13
Ubicación: La buhardilla del silicio.
Agradecido : 30 veces
Agradecimiento recibido: 78 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Silicebit » 22 Abr 2014 10:27

Una pregunta... ¿Cada vez que cargues el juego tienes que ajustar la temporización del retorno vertical?
El 6809 es el Rolls-Royce de los 8bits, el 6502 es el Mercedes, y el Z80 el SEAT 850. Sorry, but... I think different. :-P -0r1c -m3s3x -t4nd1 -cbmja YouTube

Avatar de Usuario
Chema
Mensajes: 1536
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 441 veces
Agradecimiento recibido: 186 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Chema » 22 Abr 2014 10:45

Si, slicebit. Por desgracia es así. No hay manera de saber el estado del barrido en arranque. Creo que se ha comentado si sería posible estimarlo de algún modo varias veces, y no se ha llegado a nada útil. Sería la bomba encontrar un método.

Lo que sí que haré es soportar el mod (VSync Hack), que creo que se puede autodetectar que está presente. Eso hará la vida más fácil a los que lo tengan (¿alguien?) y, sobre todo, al jugar en Oricutron (que lo emula). Otro problema adicional es que esto me dará una interrupción cada vez que empiece (¿o acabe?) un cuadro y no cuando ha acabado de pintar la parte que me interesa como cuando lo calibras a mano. Así que voy a tener el tiempo para el volcado más justo. Espero que no de problemas...

A ver, que yo lo hago cada vez que lanzo el juego y me lleva unos pocos segundos (todo es coger el vicio), así que tampoco es para tanto, pero entiendo que es una molestia. También es cierto que los resultados merecen la pena...

Avatar de Usuario
Silicebit
Mensajes: 1325
Registrado: 16 May 2011 21:13
Ubicación: La buhardilla del silicio.
Agradecido : 30 veces
Agradecimiento recibido: 78 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Silicebit » 22 Abr 2014 11:04

Si hubiera una versión para disco, se podría salvar el dato de la temporización -una vez ajustado- en un pequeño archivo, y el juego podría cargarlo al comienzo. Con ésto sólo tendremos que ajustarlo una sola vez, claro está que sólo funcionaría en el Oric donde se haya hecho el ajuste. También se podría resetear ese dato para usar el juego en otro Oric.

¡¡Nada más que te doy quebraderos de cabeza, Chema!! :-P
El 6809 es el Rolls-Royce de los 8bits, el 6502 es el Mercedes, y el Z80 el SEAT 850. Sorry, but... I think different. :-P -0r1c -m3s3x -t4nd1 -cbmja YouTube

Avatar de Usuario
Chema
Mensajes: 1536
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 441 veces
Agradecimiento recibido: 186 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Chema » 22 Abr 2014 12:05

Para nada... A mí el tener lluvia de ideas me viene genial. Creo, de todas formas, que eso no sería suficiente. No es cuestión del valor del temporizador (que sabemos -creo- cual es) sino de que los contadores lleguen a 0 en el momento adecuado. Cuando arrancas el Oric, no hay manera de saber dónde está el retrazado, así que puedes tener una interrupción a 50Hz, pero no sincronizada con el barrido.

Si supiésemos el estado al arranque de la CPU imagino que podríamos calcular todo de manera automática, pero creo que eso no es posible... aunque la parte del hardware ahí se me escapa completamente. Y que no se vea afectado de forma no predecible con el proceso de carga del juego, esa es otra.

Una cosa: acabo de hacer una prueba rápida para soportar el mod del Vsync y, al menos en Oricutron, funciona perfectamente :) Ahora a ver cómo hago el proceso de autodetección...

Avatar de Usuario
luiscoco
Mensajes: 2328
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 30 veces
Agradecimiento recibido: 44 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor luiscoco » 22 Abr 2014 12:36

Habría que ver con los de hardware , si hay algo que el software pueda hacer para reiniciar algo, el barrido o alguna interrupción o salida que afecte e inicializar el sicronismo, cuando el programa ya este listo y esperando el momento adecuado.


Enviado desde mi HTC Desire C mediante Tapatalk

Avatar de Usuario
Chema
Mensajes: 1536
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 441 veces
Agradecimiento recibido: 186 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Chema » 23 Abr 2014 10:48

Ya introduje la autodetección. Es una delicia, al menos en el Oricutron que simula el mod. Lo seleccionas y el juego arranca directamente, sin necesidad de calibración alguna.

Estoy teniendo bastante realimentación de los probadores de la versión alfa. Hay muchas sugerencias para mejorar el juego en general, y creo que voy a introducir casi todas. Lo malo es que lleva tiempo, pero creo que merece la pena.

dancresp
Mensajes: 4993
Registrado: 13 Nov 2010 02:08
Agradecido : 14 veces
Agradecimiento recibido: 83 veces

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor dancresp » 25 Abr 2014 14:20

Chema escribió:Ya introduje la autodetección. Es una delicia, al menos en el Oricutron que simula el mod. Lo seleccionas y el juego arranca directamente, sin necesidad de calibración alguna.

Entonces esto quiere decir que si que es posible detectar el inicio del barrido, ¿no?

Avatar de Usuario
Chema
Mensajes: 1536
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 441 veces
Agradecimiento recibido: 186 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Chema » 25 Abr 2014 14:35

No sin el mod. Se trata de un cable que conecta la salida de sincronismo del conector RGB del Oric a la entrada de cinta. La propia electrónica del Oric filtra los pulsos del barrido horizontal y deja los del vertical, que pueden verse desde la CPU a través de la VIA en un bit del puerto CB1.

Si está presente el cable, el juego lo autodetecta y listo. Si no tienes que seguir con la calibración a mano.

Naturalmente el mod está simulado en el Oricutron, así que basta con activar la opción y el juego arranca directamente.

Avatar de Usuario
Chema
Mensajes: 1536
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 441 veces
Agradecimiento recibido: 186 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Chema » 05 May 2014 19:42

¡Mecachis! Que se me había olvidado que prometí seguir soltando la chapa acerca de cómo estaba programado esto.... A ver, déjame ver dónde me había quedado...

-bRick

La IA de los enemigos
El esquema para implementar el movimiento de los enemigos es bastante sencillo. La idea es algo parecido a la "multitarea cooperativa" de antaño: en cada instante se recorren todos los enemigos activos y se invoca a una función que implementa su IA. Estas funciones deben realizar el trabajo en pasos de manera que cuando se las llame, hagan un par de cálculos, modifiquen lo que sea necesario y retornen lo antes posible para que el sistema pase a la siguiente.

Cada enemigo debe tener entonces un área de datos donde almacenar su estado (su "contexto"). Como es costumbre en máquinas basadas en 6502, es mejor tener vectores de bytes (uno por dato, o dos por dato si los son de 16 bit), en lugar de todo en un bloque (como sería una estructura en C) para acceder más rápidamente. Creo que esto ya lo comenté antes.

En este juego este área de datos está formado por lo siguiente:

Código: Seleccionar todo

; Posición en el mapa
sprite_cols      .dsb MAX_SPRITES+1 
sprite_rows      .dsb MAX_SPRITES+1   

; Comando principal de la IA
pcommand_l      .dsb MAX_SPRITES+1
pcommand_h      .dsb MAX_SPRITES+1

; Comando adicional de la IA
ccommand_l      .dsb MAX_SPRITES+1
ccommand_h      .dsb MAX_SPRITES+1

; Variable interna (su uso depende de la función ejecutada)
sprite_var1      .dsb MAX_SPRITES+1

; Estado de animación o paso en el algoritmo
anim_state      .dsb MAX_SPRITES+1

; Velocidad de reacción del enemigo
; Una máscara para aplicar al número de frame actual (que es un byte que se incrementa en cada cuadro)
; se hace un AND entre ambos para ver si se ejecuta el comando (Z=0) o se retorna sin hacer nada  (Z!=0)
reac_speed      .dsb MAX_SPRITES+1

; Velocidad de movimiento máxima.
max_speed      .dsb MAX_SPRITES+1

; Punteros al gráfico y máscara actuales
sprite_grapl   .dsb MAX_SPRITES+1
sprite_graph   .dsb MAX_SPRITES+1
sprite_maskl   .dsb MAX_SPRITES+1
sprite_maskh   .dsb MAX_SPRITES+1

; Dirección del movimiento: 0=parado, >0 a la derecha, <0 a la izquerda
sprite_dir      .dsb MAX_SPRITES+1

; Estado del enemigo: 0=inactivo 1=normal 2=explotando
sprite_status   .dsb MAX_SPRITES+1

; Velocidad de movimiento actual (es un índice a una tabla de velocidades, para implementar aceleraciones, deceleraciones
speedp         .dsb MAX_SPRITES+1

; Movimiento arriba o abajo <0 arriba, or >0 abajo, 0 sin movimiento
speedv         .dsb MAX_SPRITES+1

; Tipo de enemigo
sprite_type      .dsb MAX_SPRITES+1


Parece muy complicado, pero los datos van saliendo de manera natural al ir implementando. Lo más importante son los punteros a los comandos de la IA. Yo estoy usando dos (que llamo continuo y principal), porque me dan más flexibilidad (ahora mismo hablo de eso). Cuando queremos que un enemigo realice una función determinada (por ejemplo perseguir al jugador o simplemente explotar), se instala la dirección de la función adecuada en esos punteros.

En cada cuadro, entonces, el motor recorre los enemigos mirando a ver lo que tiene que hacer de este modo (el código es un resumen de lo que hay implementado, para dejar solo lo importante):

Código: Seleccionar todo

;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Move the sprites
;;;;;;;;;;;;;;;;;;;;;;;;;;;
move_sprites
.(
   ldx #MAX_SPRITES
loop
   ; ¿Está el enemigo activo?
   lda sprite_status,x
   beq skip

   ; Miramos si tiene un comando continuo y saltamos a esa rutina si es así
        ; Se hace con código automodificable
   lda ccommand_h,x
   beq noccommand
   sta smc_jmpc+2
   lda ccommand_l,x
   sta smc_jmpc+1
smc_jmpc
   jsr $1234   

noccommand   
   ; Miramos si tiene un comando primario y saltamos a esa rutina si es así
        ; Se hace con código automodificable
   lda pcommand_h,x
   beq noprimcommand
   sta smc_jmp+2
   lda pcommand_l,x
   sta smc_jmp+1
smc_jmp
   jsr $1234
+noprimcommand


Hasta aquí es fácil, porque sólo se mira si la parte alta del puntero es diferente de cero (no se tienen comandos en direcciones debajo de $00ff porque es la página cero) y, si no lo es, entonces hay un comando al que saltar con jsr.

Generalmente yo pongo en los comandos primarios cosas como el seguir al jugador o moverse de izquierda a derecha, y en los secundarios o continuos cosas como la animación del enemigo, pero acabo mezclándolos más o menos según me interesa. El tenerlos separados me permite simplemente combinar cosas.

Tras esto el motor sigue con el movimiento del enemigo. Para sincronizar el movimiento tengo una variable llamada frame_bit que parte de un valor 00000001 y va rotando el 1 en cada cuadro. Así un enemigo que se mueva cada cuadro (lo más rápido permitido) tiene una velocidad en binario de 11111111, uno que se mueva cada dos cuadros 10101010, etc. Esto lo tuve que hacer para evitar que dos naves moviéndose a la misma velocidad lo hicieran en cuadros alternos, porque el resultado era visualmente horroroso.

Código: Seleccionar todo

   ; Comprueba si debe moverse según su velocidad que, recordemos, es una tabla...
   ldy speedp,x
   lda tab_speedh,y
   
       ; ... que contiene máscaras para asociar al frame_bit
   and frame_bit
   beq nomoveh

   ; Vale,toca moverlo. Esto es simplemente sumarle el valor de la variable sprite_dir (dirección) a la variable sprite_cols (columna actual)
   lda sprite_cols,x
   clc
   adc sprite_dir,x
   sta sprite_cols,x
nomoveh
   
   ; Ahora el movimiento vertical
   ; mucho más simple, sólo arriba o abajo
        ; pero cada dos frames, que sino es demasiado rápido
   lda frame_counter
   and #%1
   bne skip

        ; Como antes, sumamos la velocidad, comprobando que no nos
        ; salimos de la pantalla.
   lda speedv,x
   beq skip
   clc
   adc sprite_rows,x
   bmi skipv
   cmp #20-1
   bcs skipv
   sta sprite_rows,x
skipv

   ; Hecho, a por el siguiente: hasta el X=0 (inclusive)
   dex
   bpl loop



Bueno, en realidad se hacen algunos apaños con el movimiento para el jugador, porque hay algunos detalles que tener en cuenta, pero son cosas menores. Y aquí estamos hablando de la IA.

Veamos un ejemplo sencillo: un movimiento lateral que se invierte al llegar al borde. El id del objeto a tratar viene siempre en el registro X. Podemos implementarlo con una función como ésta:

Código: Seleccionar todo

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Primary command for the simplest
; back and forth movement. When near
; the edge, turn around
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
move_lateral_and_back
.(
   ldy sprite_cols,x
   lda sprite_dir,x
   bmi checkleft
   cpy #250
   bcs turn
   rts
checkleft
   cpy #6
   bcc turn
   rts
.)


Este es muy simple, ni acelera, ni varía la dirección ni nada, pero puede ser base para otros más complejos.

Otro ejemplo: animación en cuatro cuadros. La idea es, dependiendo de la velocidad de animación que queramos, ir cambiando los punteros de gráfico y máscara entre cuatro posibles. Además mantenemos el estado de animación en la variable del objeto anim_state:

Código: Seleccionar todo

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Generic 4 frame animation
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
gen_fourframe
.(
       ; Es el momento de animar?
   lda frame_counter
   and #%11 ; solo cada cuatro cuadros
   beq doit
retme
   rts
doit   
       ; lo es, actualiza anim_state (solo importan los dos bits bajos) y los punteros a gráfico y máscara
   inc anim_state,x
   lda anim_state,x
   and #%11
   beq restoreg

   ; Avanza un frame
   lda sprite_grapl,x
   clc
   adc #32
   sta sprite_grapl,x
   bcc nocarry
   inc sprite_graph,x
nocarry
   lda sprite_maskl,x
   clc
   adc #32
   sta sprite_maskl,x
   bcc nocarry2
   inc sprite_maskh,x
nocarry2
   rts

restoreg   
   ; Vuelve a poner el primer gráfico
   sec
   lda sprite_grapl,x
   sbc #(32*3)
   sta sprite_grapl,x
   bcs noborrow
   dec sprite_graph,x
noborrow
   sec   
   lda sprite_maskl,x
   sbc #(32*3)
   sta sprite_maskl,x
   bcs noborrow2
   dec sprite_maskh,x
noborrow2   
   rts
.)


Y así. Por supuesto en este juego hay comportamientos complejos: desde naves que intentan esquivar tus disparos, que se mueven en círculos a tu alrededor, que intentan chocar contigo... hasta cosas como el Eye of the Beholder que, si está cerrado se mueve lateralmente pero cuando estás cerca se abre y comienza a perseguirte para chocar contigo hasta que te alejas y vuelve a cerrarse. Y algunos otros que no desvelo, para que los descubráis jugando ;)

El sistema es suficientemente flexible como para que la explosión de los enemigos sea un comando de este tipo, pero también el loop que hace la nave del jugador al cambiar de dirección e incluso hay una para los disparos (el normal y el super-shot). Cuando es necesario se instala y a correr.

Vamos a ver con más detalle el que hace explotar una nave. Cuando queremos hacerlo, cargamos en el registro Y el id (índice en los arrays) del enemigo y llamamos a la siguiente función:

Código: Seleccionar todo

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Instala el comando para
; hacer explotar la nave cuyo
; ID se pasa en el registro Y
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
explode_ship
.(
   ; Prepara el comando
   lda #<do_explode
   sta pcommand_l,y
   lda #>do_explode
   sta pcommand_h,y
   
   ; Elimina cualquier comando continuo
   lda #0
   sta ccommand_h,y
   
   ; Detener el movimiento
   sta speedv,y
   lda #8
   sta speedp,y
   
   
   ; Preparar punteros a los gráficos
        ; de la explosión
   lda #<_sprite_explosion
   sta sprite_grapl,y
   lda #>_sprite_explosion
   sta sprite_graph,y
   lda #<_mask_explosion
   sta sprite_maskl,y
   lda #>_mask_explosion
   sta sprite_maskh,y   
   
   ; Indicamos que está explotando
   lda #IS_EXPLODING
   ora sprite_status,y
   sta sprite_status,y
   
   ; Colocamos el estado de animación al inicial (cero)
   lda #0
   sta anim_state,y
   
       ; Hacemos sonar la explosión
   lda #EXPLODE
   jmp _PlaySfx ; Esto salta y retorna de esta función
   


Esta es la parte que lo instala e inicializa. Seguido está el comando en sí que se ejecuta por el sistema:

Código: Seleccionar todo

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Punto de entrada para el comando
; que hace que un enemigo explote
; El objeto tratado viene en el registro X
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
do_explode
       ; Ajuste de velocidad (solo cada dos frames)
   lda frame_counter
   and #%1
   beq doit
   rts
doit
   lda anim_state,x
   cmp #7
   bcc next_step
   ; Si el anim_state es 7, hemos
        ; terminado la secuencia.
   ; Si no se trata del jugador podemos
        ; crear un item. Sino borramos el objeto
   lda sprite_status
   beq delete_object
        ; No es el jugador, salta a crear item y retorna
        ; La función crear item puede no crearlo
        ; en cuyo caso salta a delete_object (más abajo)
   jmp create_item

       ; Borramos un objeto
+delete_object   
       ; Vaciamos los comandos y variables asociadas
   lda #0
   sta pcommand_h,x
   sta sprite_status,x
   sta anim_state,x
   sta speedv,x
   sta speedp,x
        ; decrementamos los enemigos actuales y retornamos
   dec waveobjects
   rts
   
next_step
   ; No hemos acabado, siguiente paso de la animación
   ; incrementar punteros y estado de animación
   inc anim_state,x
   lda sprite_grapl,x
   clc
   adc #32
   sta sprite_grapl,x
   bcc nocarry
   inc sprite_graph,x
nocarry
   lda sprite_maskl,x
   clc
   adc #32
   sta sprite_maskl,x
   bcc nocarry2
   inc sprite_maskh,x
nocarry2

   rts
.)


¿A que es sencillo? Al menos conceptualmente.

Si queréis más sobre la programación de IAs en estos juegos, algo más complejo y variado os recomiendo la de Skool Daze. Esa sí que es complicada, sólo hay que ver las cosas que hacen los personajes durante el juego. En este caso intenté reproducir la del juego original. Escribí los detalles en el foro de Defence-Force (aunque está en inglés, creo que esta IA de lo mejorcito que he visto):
La IA en Skool Daze (en inglés)

Y esto es todo. Si hay alguna duda o queréis que aclare algún punto, decídmelo y edito o posteo más detalles.

¿Qué me queda por contar? No sé si alguien estará interesado en cómo se hace la música o los efectos de sonido (me tuve que implementar un motor simple para ésto) o si me queda algún detalle del juego que os interese...

Espero no haberos aburrido mucho -sleeping y que sea medianamente entendible -nb

dancresp
Mensajes: 4993
Registrado: 13 Nov 2010 02:08
Agradecido : 14 veces
Agradecimiento recibido: 83 veces

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor dancresp » 05 May 2014 21:37

Toca ampliar el Word y rehacer el PDF.

Como no decías nada más del tema ya lo tenía generado... pero bien vale la pena.
Además, como estoy con el ensamblador del 6502 para Oric, me gusta ver las rutinitas que haces...

Avatar de Usuario
Chema
Mensajes: 1536
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 441 veces
Agradecimiento recibido: 186 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Chema » 06 May 2014 09:49

Vaya, lo siento dancresp. Es que se me había olvidado completamente el tema. Si quieres que aclare o amplíe algo, lo que sea, dímelo ¿vale? Me apetece dejar estas cosas por escrito y compartirlas. Al final todos los fuentes de mis programas quedan accesibles en el repositorio de defence-force.

Supongo que habrá un montón de erratas. Por ejemplo acabo de ver que en la función que mueve una nave lateralmente se salta a una etiqueta que no aparece por ningún sitio y que es una rutina para cambiar la dirección de la nave. El código es:

Código: Seleccionar todo

; Helper to make a ship turn
turn
.(
   lda sprite_dir,x
   bmi set1
   lda #$ff
   .byt $2c
set1
   lda #1
   sta sprite_dir,x
   rts
.)


Más que nada por completitud. También hay cosas que tendría que revisar. Por ejemplo hago por algún sitio lda noseque:and #%1:beq dondesea Esto no es nada óptimo, porque sería mejor lda noseque:ror:bcc dondesea que ocupa un byte menos, pero son remanentes de cuando voy haciendo pruebas...

Mi código no es excesivamente bueno. Tiendo a organizarlo de un modo igual un poco particular, que no es nunca el óptimo, excepto cuando trato con rutinas que tengo que optimizar al máximo (ya sea en velocidad o en tamaño).

Otra cosa que puede despistar es la sintaxis del XA (el ensamblador cruzado que trae el OSDK). Está muy bien aunque le faltan algunas cosillas. Si hay que aclarar algo dímelo.

Mucha suerte con el ensamblador del 6502 para el Oric. Viendo las cosas que eres capaz de hacer en Basic, apuesto a que será un proyecto genial!

dancresp
Mensajes: 4993
Registrado: 13 Nov 2010 02:08
Agradecido : 14 veces
Agradecimiento recibido: 83 veces

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor dancresp » 06 May 2014 13:11

Bueno, yo por ahora subo esto:

PDF - Nuestro compañero Chema no está quieto.rar
(133.7 KiB) Descargado 145 veces


Igual te va bien para repasar... -507

Esta claro que el título deberá ser otro, pero por lo pronto no estés quieto... -drinks

Avatar de Usuario
Chema
Mensajes: 1536
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 441 veces
Agradecimiento recibido: 186 veces
Contactar:

Re: ¡¡Nuestro compañero Chema no está quieto!!

Mensajepor Chema » 07 May 2014 21:18

¡Ostras que pasada de curro te has pegado! Mola un montón. Me lo tengo que leer con cuidado :)

Hala, pues entonces vamos con algo más molón (creo). Esto es un video del gameplay del juego, para que veáis cómo se está desarrollando la cosa. Faltan cosas y hay que pulir detalles incluso para llamarlo versión beta, pero ya va tomando forma...

Se agradecen comentarios, sugerencias, etc...

http://youtu.be/4yLFHSy3i54


Volver a “Oric”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado