Proyecto, un juego para Dragon 32

Avatar de Usuario
pser1
Mensajes: 2150
Registrado: 08 Dic 2012 18:34
Agradecido : 244 veces
Agradecimiento recibido: 250 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor pser1 » 24 Mar 2017 10:43

Último mensaje de la página anterior:

minter escribió:
pser1 escribió:Ya está incorporado el sistema de textos comprimidos. Y además funciona -507
Ha costado mas de lo previsto debido a los dos sistemas de presentación de textos empleados:

¿Pero estamos locos o que?
¿Qué te ha costado? Pero si te ha llevado menos de 24 horas implementarlo!!!! -shock -shock -shock
Alucinante!!! -thumbup

El tema costar depende de como lo vea quien lo implementa ...
Numero de intentos fallidos y detectar los errores de diseño / concepto / programación.
Todo se arregla con tiempo y de ésto, por el momento, dispongo de bastante -thumbup
saludos
pere

Avatar de Usuario
Chema
Mensajes: 1812
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 819 veces
Agradecimiento recibido: 293 veces
Contactar:

Re: Proyecto, un juego para Dragon 32

Mensajepor Chema » 28 Mar 2017 21:21

Vaya, pues pensé que te lo había comentado. Es una propiedad que yo uso mucho :)

Recuerda llamar al compresor con todo el texto que quieras comprimir cuando compiles. Se supone que busca la tabla de tokens óptima de algún modo. Al menos lo intenta.

Genial que avances tan rápido!

Avatar de Usuario
pser1
Mensajes: 2150
Registrado: 08 Dic 2012 18:34
Agradecido : 244 veces
Agradecimiento recibido: 250 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor pser1 » 05 Abr 2017 21:59

Hola amigos,
El juego "TibuRon" ya es jugable de principio a fin. Estoy a la espera de jojo073 para llevar a cabo los últimos retoques/añadidos.
He querido hacer un experimento:
- cargar las pantallas al final de la RAM y luego copiar los datos sobre el área de pantalla al vuelo sin que el usuario lo note (256x156)
lo cual equivale a 32 bytes por linea y 156 líneas (casi 5k).
Para ello he utilizado una técnica que en los foros de CoCo3 se llama StackBlast, básicamente utilizando los dos punteros del stack
(el de sistema S y el de usuario U) para mover de golpe OCHO bytes (registros A,B,CC,DP de 8 bits y los registros X,Y de 16) en cada instrucción.
Ello comporta un montón de problemas ya que al mangonear la página directa DP en cada lectura, si se produce una interrupción
y la rutina del sistema requiere apuntar a la página cero, seguro que casca todo.
Además a cada lectura se modifica también el registro CC por lo que bloquear las interrupciones mediante este registro fracasa, hay que buscar alternativas ... Por ejemplo, bloquear los IRQs a nivel hardware!

Asumiendo que podemos leer en una instrucción 8 bytes y en la siguiente grabarlos, adaptando uno de los punteros para ir en secuencia,
en cuatro veces se copia una fila de pantalla (8x4=32 bytes). El tema es que esto requiere emplear 132 ciclos de reloj que para 156 lineas
a copiar resulta en 20.592 ciclos.
Si conseguimos detectar el final de cuadro, podemos trabajar a escondidas del VDG durante 120 lineas o sea 6.840 ciclos, todo lo que
se haga luego ya será con el VDG actualizando la pantalla pisándonos los talones!

Problema:
- En el tiempo que usa el VDG para llegar a la primera linea de pantalla, es decir en las 120 lineas, disponemos de 6.840 ciclos que
a razón de 132 para copiar cada línea, nos habrá permitido llegar hasta la 52 solamente.
Nos quedan todavía 104 lineas por actualizar lo cual ya pinta muy mal. Imaginemos que hacemos 50 líneas mas (50x132) son 6.600 ciclos,
mientras tanto la VDG habrá redibujado (6.600/57) 115 líneas, es decir ya nos habrá pillado y rebasado.
Nosotros estaremos por la 52+50 o sea la linea 102. Derrota absoluta = parpadeo! -banghead

Existe una solución (o mas), ¿Alguien puede aportar alguna idea al respecto?
En un próximo mensaje explicaré la solución que me dió Stewart Orchard del grupo World of the Dragon, con quien colaboré al hacer
la conversión de la ROM del cartucho Orchestra-90 de CoCo para Dragon. Un gran experto en Dragón (hard y soft)
A ver quien se anima!
saludos
pere

Avatar de Usuario
kikems
Mensajes: 2238
Registrado: 30 May 2013 19:23
Agradecido : 455 veces
Agradecimiento recibido: 694 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor kikems » 06 Abr 2017 02:43

El único que entiende lo que pones creo que es Chema y poco más, pero felicidades por el esfuerzo y el trabajo bien realizado.

Avatar de Usuario
minter
Mensajes: 1744
Registrado: 22 Jul 2014 18:51
Agradecido : 1040 veces
Agradecimiento recibido: 460 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor minter » 06 Abr 2017 09:08

Puf!!!
Cualquier método indirecto le lleva al micro más de 6 ciclos!
Mediante registro y un par de punteros... 7+2+7+2=18 ciclos para mover un byte!
A mí en vez de pintar TIBURON... me quedaría en TI. Y ya me alcanzó el video! -grin
Este método de calzar 8 bytes de golpe con 33 ciclos me parece una pasada! No me salen los cálculos! -banghead
Como no sea posible interrumpir el VDG antes de que empiece a pintar de nuevo... y bajar el framerate... no se me ocurre nada.
Una pasada! -thumbup

Avatar de Usuario
Chema
Mensajes: 1812
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 819 veces
Agradecimiento recibido: 293 veces
Contactar:

Re: Proyecto, un juego para Dragon 32

Mensajepor Chema » 06 Abr 2017 09:31

jajaja, kikems, pues esta vez no del todo. Los temas específicos de Dragon o de su CPU se me escapan totalmente.

Por ejemplo no entiendo lo de bloquear las interrupciones a nivel de hardware ¿es eso posible? Si no lo es, entonces la rutina sólo funciona bien cuando nos aseguramos de ejecutarla en ranuras de tiempo donde no haya interrupciones, por ejemplo, del retrazado vertical.

Lo de usar trucos con la pila (aquí DOS, flipo) ya lo había oído antes (por ejemplo creo que Cobra en el speccy usa la pila para mover a pantalla bloques de 16-bits, debe ser una técnica común). En el Oric no se puede, porque el puntero es fijo en página 1, así que no tengo experiencia con eso. Ni idea de cómo se lo pueden montar para mover 8 bytes... ¿hay alguna instrucción para hacer PUSH de todos los registros a la vez? -shock

A mí, así a bote pronto, se me ocurre que podrías hacerlo a la inversa. Es decir, esperas por la interrupción de pantalla, esperas en un bucle con un timing preciso a que empiece a actualizar la primera línea y vas tú detrás volcando. Persigues tú al rayo y no al revés. Como es más rápido no lo pillas, pero tienes todo el tiempo de una pantalla y el blank para volcar.

Si eso no se puede hacer y tienes que ir tú por delante recuerda que hay una zona con texto que igual puedes usar. Quiero decir que puedes empezar a actualizar cuando el rayo sale fuera del gráfico, no cuando se produce la interrupción de pantalla. Eso te da más tiempo. No sé cómo se podría hacer eso sin interrupciones temporizadas y sin bucles específicos de espera.

¿Estás intentando implementar un doble-búfer completo? Es que en las demos ya parecía ir bien, como sea que lo hayas hecho, por eso pregunto. Si consigues volcar una pantalla completa en menos de un frame eso abre un montón de posibilidades muy interesantes, porque no poder hacerlo genera muchísimos problemas. Por ejemplo juegos con scroll del terreno o con muchos objetos que se mueven por todas partes.

Para que veas lo que es no poder hacerlo, en 1337 (mi versión de Elite para Oric) todo el tema de doble-búfer se lleva 1/3 del tiempo total de cuadro (¡incluyendo todo el 3D!), así que la tasa de FPS cae un 33%. En otros casos hay que andar usando técnicas que sólo redibujen las partes que sea necesario redibujar (los "rectángulos sucios") para ahorrar tiempo.

Así que si lo haces funcionar, podrías pensar en nuevas producciones de mucha calidad para el Dragon! -thumbup

Avatar de Usuario
pser1
Mensajes: 2150
Registrado: 08 Dic 2012 18:34
Agradecido : 244 veces
Agradecimiento recibido: 250 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor pser1 » 06 Abr 2017 10:52

minter escribió:Puf!!!
Cualquier método indirecto le lleva al micro más de 6 ciclos!
Mediante registro y un par de punteros... 7+2+7+2=18 ciclos para mover un byte!
A mí en vez de pintar TIBURON... me quedaría en TI. Y ya me alcanzó el video! -grin
Este método de calzar 8 bytes de golpe con 33 ciclos me parece una pasada! No me salen los cálculos! -banghead
Como no sea posible interrumpir el VDG antes de que empiece a pintar de nuevo... y bajar el framerate... no se me ocurre nada.
Una pasada! -thumbup

Hola de nuevo,
por supuesto que no te pueden salir los números si no echas mano de la chuleta con los ciclos de cada instrucción
y buscas alguno interesante.
Por cierto, Chema, si podemos meter y sacar del stack 8 bytes! Es meterse en un serio compromiso, pero se puede!
Adjunto parte del código que hace solo esta parte.
Al lado estan los ciclos acumulados y el control de fin de pantalla a mover
saludos
pere

Código: Seleccionar todo

stkF01   puls   d,x,y,cc,dp      ; (13)    ; lee 8 bytes del origen - Pull del stack añade 8 al puntero
         pshu   d,x,y,cc,dp      ; (26)    ; los pone en destino - pushs en stack resta 8 al puntero
         leau   16,u            ; (31)    ; avanzar puntero a siguiente bloque de 8 bytes
         puls   d,x,y,cc,dp      ; (44) 
         pshu   d,x,y,cc,dp      ; (57) 
         leau   16,u            ; (62)    ; siguientes 8 bytes
         puls   d,x,y,cc,dp      ; (75) 
         pshu   d,x,y,cc,dp      ; (88) 
         leau   16,u            ; (93)    ; siguientes 8 bytes   
         puls   d,x,y,cc,dp      ; (106) 
         pshu   d,x,y,cc,dp      ; (119) 
         leau   16,u            ; (124)    ; siguientes 8 bytes = 32 bytes -> una linea en modo PM4
         cmpu   #$1f80         ; (129)    ; fin de pantalla a llenar?
         blo   stkF01         ; (132)    ; no, siguiente linea

Avatar de Usuario
pser1
Mensajes: 2150
Registrado: 08 Dic 2012 18:34
Agradecido : 244 veces
Agradecimiento recibido: 250 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor pser1 » 06 Abr 2017 11:11

Hola,
Chema, acertaste con tu propuesta de solución. Paradójicamente, si en luchar de echarnos a correr como locos para que no nos pille
la VDG actualizando RAM, nos limitamos a esperarle (bucle de retardo desde la detección del final de pantalla hasta inicio de la siguiente)
entonces disponemos de un frame completo (312x57) 17.784 ciclos con los cuales podemos mover datos de (17.784/132) 134 lineas.
Cuando la VDG llegue de nuevo a la primera fila de pantalla, solo nos quedan por hacer (156-134) 22 lineas, para las cuales utilizaremos
(22x132) 2.904 ciclos. La VDG en este periodo avanzará (2.904/57) 51 líneas ... pero nosotros ya hemos acabado con la linea 156, o sea
que NO nos ha doblado, no hay parpadeo!
El bucle de retardo para esperar a la primera línea contiene además todo el código necesario para bloquear las interrupciones y
guardar las configuraciones de las PIAs para reponerlas al finalizar la copia. O sea *no* es tiempo perdido!
Para haceros una idea, os copio aquí la parte previa, mientras espera a que la VDG llegue a la primera linea de pantalla

Código: Seleccionar todo

stkBlst   lda    $ff02                     ; limpia flag de interrupcion recibida
stkF00     lda    $ff03            ; (5)      ; llega interrupcion vertical (FS)?
         bpl    stkF00         ; (8)      ; no, espera
                                       ; 120x57=6.840 ciclos -(11+90) ciclos = 6.739 / 8 -> 842,375
         ldx   #843            ; (11)   ; valor para hacer la espera exacta (espera 1a linea de pantalla)
         opt   cc
lTime      leax   -1,x            ; (5)      ; decrementa contador
         bne   lTime            ; (8)      ; no finalizado, sigue. (843x8= 6.744)
         opt   cc
         pshs   cc,dp            ;  (7)   ; salva registros CC y DP en el stack
         orcc   #$50            ; (10)   ; deshabilita interrupciones (de soft)
         ldx    #$ff00         ; (13)   ; apunta a las PIAs
         lda   $21,x            ; (18)   ; lee configs
         ldb   $23,x            ; (23)   ; de PIA1
         pshs   d               ; (30)   ; guarda valores
         lda   1,x            ; (35)   ; lo mismo
         ldb   3,x            ; (40)   ; para PIA0
         pshs   d               ; (47)   ; salva valores
         sts   stkF02+2         ; (54)   ; guarda puntero stack
         lda    #$34            ; (56)   ; valor para deshabilitar irqs a nivel hardware
         sta    1,x            ; (61)   ; afecta a irq hsync (HS)
         sta    3,x            ; (66)   ; afecta a irq vsync (FS)
         sta    $21,x            ; (71)   ; afecta a firq impresora
         sta    $23,x            ; (76)   ; afecta a firq del cartridge
         clr   $ff48            ; (83)   ; deshabilita NMI de disquet y para el motor
         lds   #$6720         ; (87)   ; apunta a origen de datos cargados para leer 8 bytes desde origen
         ldu   #$c00+8         ; (90)   ; apunta a destino (inicio pantalla mas 8 bytes por el efecto de Push)
                              ; llega aqui 6.845 ciclos despues del FS aprox. como deseado

Ahora solo queda la parte final de la rutina que debe dejar las PIAs configuradas como antes y asegurarse de que tanto
la página directa (DP), como los flags (CC) sean los recibidos a la entrada
La primera línea es modificada por la parte del bucle de espera, para poder recuperar el valor del puntero del stack
ya que la rutina copiadora utiliza *todos* los registros de la CPU

Código: Seleccionar todo

stkF02   lds   #$0000                  ; restaura puntero stack
         ldx   #$ff00                  ; apunta a las PIAs
         puls   d                        ; toma valores para PIA0
         sta   1,x                     ; los
         stb   3,x                     ; restaura
         puls   d                        ; toma valores para PIA1
         sta   $21,x                     ; los
         stb   $23,x                     ; restaura
         puls   cc,dp,pc                  ; restaura CC, DP y retorna

saludos
pere

Avatar de Usuario
pser1
Mensajes: 2150
Registrado: 08 Dic 2012 18:34
Agradecido : 244 veces
Agradecimiento recibido: 250 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor pser1 » 06 Abr 2017 11:28

@Chema
el tema de doble buffer lo utilicé en el Rotador de imágenes en PMODE3, pero aquí no me resulta posible.
El programa ocupa casi 20k, que se han de cargar tras la pantalla gráfica, o sea en $2400 (9.216 decimal)
20+9=29k, imposible tener una segunda pantalla gráfica de 6k en una máquina de solo 32K
Lo que he hecho ha sido reagrupar todo el código de la presentación con sus sprites y música y lo he ubicado
todo al final del programa que gestiona el juego.
De esta forma puedo cargar los ficheros WAV (aprox 6k cada uno) en los últimos 6k de RAM, machacando la
presentación que ya no hace falta y respetando al stack y cadenas del sistema.
Para las pantallas puedo hacer lo mismo, cargarlas *siempre* a partir de $6720, como un buffer gráfico
y luego copiarlas a saco sobre la pantalla *fija* en $c00. Esto no es precisamente un doble buffer en el que
estás alternando entre dos pantallas, trabajando en una mientras muestras la otra ... pero permite que la
pantalla cargada se vea "de golpe"

La diferencia respecto al sistema anterior de cargar a la vista del usuario es que en el sistema antiguo cuando
cambias de pantalla ves como se forma la siguiente (haciendo persiana levemente) mientras que en el nuevo,
has de esperar a que el disco haya cargado la pantalla completa y aparece entera de golpe. La anterior da
mas sensación de continuidad al no haber la inevitable espera a que acabe el disco.
Ya veremos que opinan los usuarios en cuanto se publique el programa.
saludos
pere

Avatar de Usuario
Chema
Mensajes: 1812
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 819 veces
Agradecimiento recibido: 293 veces
Contactar:

Re: Proyecto, un juego para Dragon 32

Mensajepor Chema » 06 Abr 2017 16:12

Pues me alegro de que te haya funcionado y ahora entiendo lo que pretendías hacer. Suena bien :)

Pero, vamos, que ya puedes hacer un juego en doble bufer completo... Para el sigui net proyecto !

Avatar de Usuario
kikems
Mensajes: 2238
Registrado: 30 May 2013 19:23
Agradecido : 455 veces
Agradecimiento recibido: 694 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor kikems » 08 Abr 2017 13:03

Pser1 me alegra ver que , aunque inicialmente querías hacer un juego de arcade o plataformas, el haberte metido en una aventura gráfica te ha permitido concentrarte en otros factores de optimización, rutinas y necesidades diferentes a los habituales.

Avatar de Usuario
jojo073
Mensajes: 3196
Registrado: 14 Nov 2010 20:41
Agradecido : 45 veces
Agradecimiento recibido: 143 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor jojo073 » 08 Abr 2017 14:19

un trabajo titanico de pser1... a ver si busco un rato con kikems y me pongo a repasar el juego con la guia para ver si le podemos temer algo mas de dialogo...
Flipante trabajo para dragon

Avatar de Usuario
ron
Mensajes: 17738
Registrado: 28 Oct 2010 14:20
Ubicación: retrocrypta
Agradecido : 797 veces
Agradecimiento recibido: 856 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor ron » 08 Abr 2017 18:12

Ahora es cuando se puede valorar todo el esfuerzo que ha dedicado pser1 a este proyecto. Pero como todos los buenos programadores, son mentes en constante aprendizaje y siempre están buscando cosas nuevas que funcionen mejor, más rápido y que consuman lo menos posible.

El arte de la depuración y de la búsqueda del último bit libre, eso ahora no pasa, pero en este caso más claro es imposible.

Es una grandísima alegría que la llegada a puerto sea inminente con tibuRon o sin el ! jaaj axD

Avatar de Usuario
Nandove
Mensajes: 875
Registrado: 10 Ene 2011 12:16
Agradecido : 154 veces
Agradecimiento recibido: 117 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor Nandove » 08 Abr 2017 20:45

Pasada de esfuerzo, sigo sin creerme que todo entre en un simple dragon :)

Avatar de Usuario
minter
Mensajes: 1744
Registrado: 22 Jul 2014 18:51
Agradecido : 1040 veces
Agradecimiento recibido: 460 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor minter » 08 Abr 2017 23:06

Atención, lo que voy a decir es en tono de broma o guasa. Igual no es el lugar, pero es que soy así de incorrecto.

Nandove escribió:Pasada de esfuerzo, sigo sin creerme que todo entre en un simple dragon :)


Bah! Eso no es nada!!! Seguro que si se pone Danicresp, te mete el juego en un Dragón 16 y escrito en BASIC del Commodore. A lo Chuck Norris.

Vale, ahora fuera broma...

Si, es increíble la curva de aprendizaje de Pere con el 6809. La velocidad a la que va aprendiendo trucos nuevos de programación.
Nos deja en la cuneta en la primera curva.
Pero es muy de agradecer que haga participe a todo el mundo de sus avances comentando y explicando todo.

Hay una cosa que no me ha quedado clara. ¿Al final se ha podido incorporar la música? O... ¿Ha quedado solo para la intro y durante el juego se escuchan los pasos del Jefe? ¿Como finalmente habéis decidido?.

¿Y las pantallas... se van cargando al vuelo desde el disco o están en memoria?

Y ya puestos a preguntar cosas...

¿Puede el dragón leer un archivo desde disco y mandar al DAC la información... como si reprodujera un audio digitalizado? Quiero decir... ¿Puede reproducir digitalizaciones?
Recuerdo que manejar el DAC, no deja recursos para hacer otras cosas, no?

Enhorabuena al duo Pere y Jojo por el juego! -drinks

Avatar de Usuario
luiscoco
Mensajes: 2336
Registrado: 15 May 2011 04:23
Ubicación: Caracas, Venezuela
Agradecido : 34 veces
Agradecimiento recibido: 46 veces
Contactar:

Re: Proyecto, un juego para Dragon 32

Mensajepor luiscoco » 09 Abr 2017 03:06

Felicidades a todos los integrantes por el proyecto y en especial a pser1

Avatar de Usuario
pser1
Mensajes: 2150
Registrado: 08 Dic 2012 18:34
Agradecido : 244 veces
Agradecimiento recibido: 250 veces

Re: Proyecto, un juego para Dragon 32

Mensajepor pser1 » 09 Abr 2017 13:53

minter escribió:Hay una cosa que no me ha quedado clara. ¿Al final se ha podido incorporar la música? O... ¿Ha quedado solo para la intro y durante el juego se escuchan los pasos del Jefe? ¿Como finalmente habéis decidido?.

Se decidió dejar la música solamente para la presentación, ya que a lo largo del juego acaba por hacerse pesada, un latazo vamos!)
¿Y las pantallas... se van cargando al vuelo desde el disco o están en memoria?

Se cargan según necesidad. Ni en una máquina con 64K podríamos cargar muchas pantallas de digamos 5K además del juego en si
Y ya puestos a preguntar cosas...
¿Puede el dragón leer un archivo desde disco y mandar al DAC la información... como si reprodujera un audio digitalizado? Quiero decir... ¿Puede reproducir digitalizaciones? Recuerdo que manejar el DAC, no deja recursos para hacer otras cosas, no?

SI puede! Este experimento lo hicimos hace tiempo con Simon Jonassen, lo divertido del caso es que un disco entero, léase 180k nos duraba solamente unos ocho segundos. Es natural si piensas en el tamaño de los ficheros de sonido sin comprimir, tipo WAV sampleados a tan solo 22k.
En la práctica la lectura de disco (que va mediante interrupciones) da tiempo suficiente para ir enviando los bytes leídos hacia el DAC
Leyendo secuencialmente el disco entero no da problemas, pero si quieres leer ficheros concretos, cosa que puede implicar leer sectores no contiguos esto conlleva reposicionar el cabezal de lectura y acaba provocando esperas en la rutina lectora que envía los datos al DAC y por tanto sonidos que se alargan distorsionando el resultado.

En el juego utilizo dos muestras re-sampleadas a solo 8K y luego les quito las muestras pares, reduciendo el fichero a la mitad.
Lo mas que puedo cargar al final de la RAM son unos 6k, así que con esta pequeña cantidad de datos y recalculando por interpolación
los valores eliminados, obtengo sonidos aceptables que duran escasos segundos ... suficientes para lo que esperaba.


saludos
pere


Volver a “Software Dragon”

¿Quién está conectado?

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