Port del AGD de Z-80 a 6809

Avatar de Usuario
pser1
Mensajes: 2250
Registrado: 08 Dic 2012 18:34
Agradecido : 319 veces
Agradecimiento recibido: 355 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 05 Sep 2018 16:37

Último mensaje de la página anterior:

Chema escribió:
pser1 escribió:De todas formas, nos conviene mas analizar el motivo real por el que los sprites se mueven a velocidad *tan* dependiente del número
de ellos que pululan por pantalla.
pere

Mmmm ¿qué método usas para dibujarlos? sé que es un xor, me refiero a cómo es la lógica para irlos actualizando, cuándo esperas por el refresco de pantalla...
No he visto la versión de Dragon (ya podíais poner un video -nb ) pero pintando sprites tan pequeños con xor debería de haber muchos, pero muchos muchos, para que se notase ralentización, porque imagino que esperas al sincronismo vertical y pintas todo (o lo intentas) en el período de blank, ¿no?
Ahí debería haber ciclos de reloj de sobra para pintar, no sé, como media docena al menos. En el Oric eran como 5.6us (el reloj es de 1MHz, así que 5600 ciclos). Si no te da tiempo, entonces actualizará cada 2 frames, a 25Hz y ahí sí que debería haber ciclos de sobra.
Igual estás muy cerca del límite (no sé qué otras cosas se hacen por frame ni el tiempo que llevan) y con uno o dos sprites puedes ir a 50Hz y con más saltas a 25Hz, que es la mitad de velocidad y eso es lo que notas.

Hola Chema,
si emplean el sistema de hacer EOR para pintar y de nuevo para borrar ...
El sistema que utiliza el motor AGD es realmente rebuscado, las rutinas Spritexx parece que trabajan linea a linea las 16 lineas del sprite
borrando primero la 'antigua' y añadiendo a continuación la 'nueva', esto es peor que dibujar dos sprites a la vez ya que los punteros a
pantalla y a los datos son diferentes para cada ocurrencia del sprite (antiguo, nuevo). En z80 usan el opcode "exx" 32 veces, 16 para
cada uno de ellos, realmente terrorífico para el sistema 6809!
Creo que hablan de 25 frames por lo que deben dedicar dos interrupciones FS antes de actualizar y posiblemente la versión 6809 no está
esperando dos cuadros ... ya abriré un hilo nuevo, publicaré el fuente de Foggy completo y podremos comentar directamente sobre el código
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2250
Registrado: 08 Dic 2012 18:34
Agradecido : 319 veces
Agradecimiento recibido: 355 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 05 Sep 2018 23:01

Buenas noches,
parece que Chema me ha 'picado'!
Una vez resueltos los problemas básicos que llevamos a medias con Kees, me he dedicado a mirar estas partes de
código que pueden afectar la velocidad 'variable' de los sprites en pantalla.
Me da la impresión de que he encontrado al culpable o culpables ...
Por si acaso, he preparado dos versiones que, en mi opinión, ya no adolecen del defecto mencionado y que me
gustaría que las probáseis y me comentáseis cual de las dos os parece mejor. Ni mas rápido ni mas lento, simplemente
aquella que mantenga la velocidad mas constante, a vuestro criterio.
Adjunto dos zips: FOG0U4A y FOG0U4B
Cada uno contiene los binarios para PM3 y PM4, los POKES para mas vidas, aunque tal vez ya no hagan falta, son
FOG0U4A - PM3 - POKE&H24D5,nn
FOG0U4A - PM4 - POKE&H24C0,nn
FOG0U4B - PM3 - POKE&H24CC,nn
FOG0U4B - PM4 - POKE&H24B7,nn

Espero vuestras opiniones -thumbup -drinks
saludos
pere
FOG0U4A.ZIP
(28.21 KiB) Descargado 12 veces

FOG0U4B.ZIP
(28.2 KiB) Descargado 12 veces

Avatar de Usuario
minter
Mensajes: 2037
Registrado: 22 Jul 2014 18:51
Agradecido : 1510 veces
Agradecimiento recibido: 625 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor minter » 05 Sep 2018 23:26

Hoy de noche, toca transnochar!!!!

Avatar de Usuario
pser1
Mensajes: 2250
Registrado: 08 Dic 2012 18:34
Agradecido : 319 veces
Agradecimiento recibido: 355 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 05 Sep 2018 23:29

minter escribió:Hoy de noche, toca transnochar!!!!

A ver si ahora, con velocidad mas moderada, ya puedes llegar hasta la última pantalla empleando un mínimo de vidas.
Por primera vez he acabado empezando con las tres vidas std. A pesar de 'ganar' dos con los botiquines, he finalizado con una solamente!
Suerte y ya me contarás
saludos
pere

Avatar de Usuario
Chema
Mensajes: 2002
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 1224 veces
Agradecimiento recibido: 406 veces
Contactar:

Re: Port del AGD de Z-80 a 6809

Mensajepor Chema » 06 Sep 2018 00:05

pser1 escribió:Buenas noches,
parece que Chema me ha 'picado'!

-507 -507 me alegro. Ayudar no ayudaré, pero si te vale de motivación.... -rofl

Venga, ahora no nos dejes con la miel en los labios y dinos qué has encontrado o probado...

De todos modos yo igual reharía la parte del pintado para que fuese lo más óptima en dragon, porque es muy dependiente de la máquina y donde merece la pena optimizar más por lo general.

No creo que afecte al juego cómo dibujes los gráficos.

Avatar de Usuario
pser1
Mensajes: 2250
Registrado: 08 Dic 2012 18:34
Agradecido : 319 veces
Agradecimiento recibido: 355 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 06 Sep 2018 13:54

Chema escribió:De todos modos yo igual reharía la parte del pintado para que fuese lo más óptima en dragon, porque es muy dependiente de la máquina y donde merece la pena optimizar más por lo general.

Estoy convencido de que procesando primero la imagen 'anterior' con los EORs necesarios (3x16) recuperaríamos el fondo de
pantalla y a continuación se podrían hacer los EORs con el nuevo frame, otra vez 3x16
Y se ganaría muchísimo sobre todo al evitar el demonio de EXX que en 6809 es una subrutina bastante pesada.
Pero las 'mejoras' al motor habrá que hacerlas cuando esté convertido totalmente y habrá que ver las modificaciones
que el grupo AGD está ya haciendo actualmente. He leído en algún hilo que incluso trabajaban en el tema de reducir el número de
frames por sprite y calcular los movimientos hacia la izquierda por espejo de los de la derecha, algo que hice en Tiburón empleando
el truco de la tabla inversora de bytes ... en fin ya se verá!
Venga, ahora no nos dejes con la miel en los labios y dinos qué has encontrado o probado...

El problema apareció al implementar el modo aventura, que garantiza que los cambios que se realicen en una pantalla, como completar
una escalera o añadir un objeto, se mantendrán aunque Foggy salga de dicha pantalla y luego vuelva a entrar.
He aquí la parte de código, que está pensada para el Atom, que copié sin analizar

Código: Seleccionar todo

-----------------------------------------------------------------------
4) Add rbloc routine after main game loop
-----------------------------------------------------------------------
                                                                                 ; back to start
         inc   frmNo                                                               ; inc frmno
         inc   clock                                                               ; inc clock
         jmp   MLoop                     ; switched to a jmp mloop for test mode   ; jmp mloop   
   IF AFLAG                                                                        ; .if aflag
RBloc                                                                              ; rbloc:
         ldd   eop                     ; reset temp blockpointer                   ; lda #<eop   
         std   tmp                                                                ; sta tmp
                                                                                 ; lda #>eop
         ...                                                                     ; sta tmp+1
-----------------------------------------------------------------------

Como podéis ver, la segunda línea incrementa la variable clock, cosa que para Atom
parece ser lo correcto, pero que fracasa estrepitosamente en los 6809
-----------------------------------------------------------------------
Este es el código donde se utiliza la variable clock para determinar si se hace algo o bien se espera la llegada del próximo FS (retrazado vertical)
La primera línea lee la variable TIMER que se incrementa en 1 a cada interrupción FS
En la segunda línea se compara con la variable clock. Si clock va 'por delante' de $0113, debido al incremento traidor, entonces se salta
el código útil y se va a VSync4 llegando a VSync0 donde se queda miserablemente esperando a que la variable TIMER alcance el valor
de la variable clock. El resultado es que se desperdicia uno de cada dos retrazados, trabajando efectivamente a 25 frames, pero no
haciendo *nada* la mitad del tiempo.
Esto si que es un buen ejemplo de 'daños colaterales' no esperados -507
saludos
pere

Código: Seleccionar todo

-----------------------------------------------------------------------
VSync3   ldb   $0113                     ; get current clock                  
         cmpb   <clock                     ; compare to previous clock value
         bne   VSync4                  ; if not equal exit loop            
         dec   <reg_B                  ; decrement inner loop               
         bne   VSync3                  ; not zero? loopback                  
         ldb   <reg_D                  ; get outer loop counter
         stb   <reg_B                  ; restore in reg_B                  
          dec   <reg_B                  ; decrment outer loop
          bne   VSync2                  ; not zero? continue sound            
VSync4   lda   <reg_D                  ; get last used outer counter         
VSynca   sta   <sndTyp                  ; save for next time                  
VSync1   lda   $0113                     ; get actual timer low value         
         rora                           ; is it odd?                        
         bcc   VSync0                  ; no, skip next                     
         jsr   VSync5                  ; yes, go for shrapnel               
                                                                           
VSync0   lda   $0113                     ; get actual timer                  
         cmpa   <clock                     ; compare to last read            
         beq   VSync0                  ; yes, wait until clock changes      
         sta   <clock                     ; update last read value         
         rts                           ; return                              
                                                                           
VSync5   jmp   ProShr                  ; shrapnel and others               
-----------------------------------------------------------------------

Avatar de Usuario
Chema
Mensajes: 2002
Registrado: 21 Jun 2012 20:13
Ubicación: Gijón
Agradecido : 1224 veces
Agradecimiento recibido: 406 veces
Contactar:

Re: Port del AGD de Z-80 a 6809

Mensajepor Chema » 06 Sep 2018 14:09

Jajaja vale, lo pillo. En algún sitio me pasó algo así a mí también, pero ahora no recuerdo.

pser1 escribió:Estoy convencido de que procesando primero la imagen 'anterior' con los EORs necesarios (3x16) recuperaríamos el fondo de
pantalla y a continuación se podrían hacer los EORs con el nuevo frame, otra vez 3x16


Seguro. Puedes tener para cada sprite su posición actual y la nueva (dos punteros a la pantalla directamente, si ya procesaste las coordenadas, para que sólo quede el bucle de pintar). Esperas el sincronismo y pintas los sprites a toda leche en la antigua (si hace falta desenrolla los bucles) y pintas de nuevo en la posición nueva. Tiene que dar tiempo en un frame para que no se vea nada de parpadeo y tienes que hacerlo con todos los sprites para que no se corrompan si pasan uno por encima de otro. Luego puedes copiar los punteros de la posición nueva a la actual y seguir...

Yo suelo preparar los punteros a la pantalla (por ejemplo a la primera fila del sprite) y al gráfico a pintar, así queda sólo lda/sta, lda/sta, lda/sta... siguiente línea lda/sta, lda/sta, lda/sta, y así...

Si no te da tiempo en el período de blank y aparecen parpadeos ocasionales, siempre puedes intentar tener los sprites ordenados por coordenada Y (primero los que estén más arriba en la pantalla) e intentar ir por delante del retrazado (lo que se llama, creo, "race the beam").

Bueno, en realidad no sé qué hago pontificando, si fijo que todo esto ya lo sabías incluso mejor que yo -rofl Es mi alma de profe, que sale de vez en cuando... no lo puedo evitar... -banghead

Avatar de Usuario
minter
Mensajes: 2037
Registrado: 22 Jul 2014 18:51
Agradecido : 1510 veces
Agradecimiento recibido: 625 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor minter » 06 Sep 2018 14:54

He notados dos sutiles diferencias entre una versión y otra.

La primera versión me va mas fluida a costa de perder frames algún enemigo. Pero la velocidad es constante.

La segunda versión parece que pierde menos frames pero el froogy se me ralentiza un poco.

El problema es que mi ordenador, apenas tiene capacidad para mover los dos emuladores a la vez. Por lo que pierdo frames en la propia emulación por falta de potencia.

En la foto se ve que tengo el ordenador al 100% de CPU y la temperatura a 52º (a 54º me salta pantallazo azul. -banghead )

Pero las dos versiones son jugables.

El sonido va sincronizado con los saltos y el movimiento de los enemigos o soy yo que necesito comprar otro ordenador? -shock
Adjuntos
Comparacion Froogy-1.JPG
Comparacion Froogy-1.JPG (86.8 KiB) Visto 337 veces

Avatar de Usuario
pser1
Mensajes: 2250
Registrado: 08 Dic 2012 18:34
Agradecido : 319 veces
Agradecimiento recibido: 355 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 06 Sep 2018 15:19

minter escribió:He notados dos sutiles diferencias entre una versión y otra.
La primera versión me va mas fluida a costa de perder frames algún enemigo. Pero la velocidad es constante.
La segunda versión parece que pierde menos frames pero el froogy se me ralentiza un poco.
Pero las dos versiones son jugables.
El sonido va sincronizado con los saltos y el movimiento de los enemigos o soy yo que necesito comprar otro ordenador? -shock

Ahora supongo que puedo explicar las dos versiones ...
- La primera FOG0U4A es la que tiene comentada la linea maldita que incrementa la variable clock
- En la segunda, FOG0U4B además eliminé el 'debouncing' de teclado que se utiliza únicamente al finalizar el juego
por lo que *NO* debería afectar en nada a velocidades ni jugabilidad, era intento de reducir algunos bytes de código
que resultan realmente innecesarios.
El tema de parpadeo o flickering de algunos de los sprites está claramente relacionado con el exceso de tiempo que requieren
las rutinas actuales de borrado/pintado de sprites, pero para mi lo que era realmente molesto (aunque constituía un reto) era pasar
determinadas pantallas donde el sprite se movía a la velocidad del rayo -507
saludos
pere
Pd de momento empatados:
FOG0U4A --- 1 voto
FOG0U4B --- 1 voto
O sea que sería interesante que alguien mas probara ambas versiones y nos diera su opinión para decidir con cual seguimos adelante
Para mi ambas son correctas y ya no tienen problemas de cambios de velocidad ... espero vuestra opinión -thumbup -drinks

Avatar de Usuario
pser1
Mensajes: 2250
Registrado: 08 Dic 2012 18:34
Agradecido : 319 veces
Agradecimiento recibido: 355 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 06 Sep 2018 15:24

Bueno, ahora tocan dos cosas antes de ponerse a 'optimizar' subrutinas:
- Mejorar el código fuente 6809 que genera el programa AGD.exe (fuente en lenguaje C)
- Aplicar los posibles cambios que el grupo AGD está llevando a cabo y que ahora mismo ya son operativos ...
El paso siguiente será convertir un juego que ha creado Alan, un colega del grupo AGD en solo 20 minutos y que parece que utiliza
todas las funciones de disparos, explosiones que están pendientes de convertir, perfecto!
saludos
pere

Avatar de Usuario
pser1
Mensajes: 2250
Registrado: 08 Dic 2012 18:34
Agradecido : 319 veces
Agradecimiento recibido: 355 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 06 Sep 2018 18:08

Venga muchachos que el tiempo se acaba, probad y comentad la que os parezca mejor -nb -nb -nb
Como muy tarde, mañana debería entregarle a Kees la versión elegida de FOG0U4x a la que debo hacerle ciertos retoques para
añadir funciones para que desde el generador de juegos se puedan cambiar los colores de fondo y primer término
Además añadiremos un flag para que el compilador sepa si trabajamos en PM4 o bien en PM3, pero siguiendo las reglas y la
nomenclatura de flags que se utiliza en el proyecto AGD
Hasta pronto
Animaros!
pere

jltursan
Mensajes: 2268
Registrado: 20 Sep 2011 13:59
Agradecido : 114 veces
Agradecimiento recibido: 310 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor jltursan » 06 Sep 2018 19:13

Mi voto es rotundo, la B.

En velocidad efectivamente las veo exactamente iguales, mi equipo debe ser más potente que el de minter -grin ; peeeero, la A tiene un bug que impide progresar, o al menos lo he conseguido reproducir dos veces de dos.
Cuando entro a la pirámide y bajo a la pantalla inferior, la de la calavera y el cristal, no puedo descender correctamente por los ladrillos, concretamente se engancha siempre en el paso a la planta intermedia, no hay manera de descender.

Y yo sigo en mis trece, yo cambiaba el color del inventario. En esa ventana la visibilidad es crucial y debe quedar el texto lo más nítido posible si no queremos que los que usen el vídeo compuesto se queden bizcos ;-)

Por lo demás, absolutamente genial, si se consigue realizar la optimización a rutinas óptimas para el 6809, esto va a quedar suave, suave -thumbup

De paso prepararé la que espero que sea la última entrega de gráficos PM3 (no se que hacer con el mapa y los "bricks", ¿lo corrijo?) y empezaré ya con los PM4 que será más poca cosa.

Otra cosa:

Además añadiremos un flag para que el compilador sepa si trabajamos en PM4 o bien en PM3, pero siguiendo las reglas y la
nomenclatura de flags que se utiliza en el proyecto AGD


No he buscado información, pero ¿la versión CPC permite trabajar con mode 0 y 1 o sólo 0?. Del Spectrum no pregunto, sólo sabe hacer un tipo de gráficos -grin

Avatar de Usuario
pser1
Mensajes: 2250
Registrado: 08 Dic 2012 18:34
Agradecido : 319 veces
Agradecimiento recibido: 355 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 06 Sep 2018 19:59

jltursan escribió:Mi voto es rotundo, la B.
En velocidad efectivamente las veo exactamente iguales, mi equipo debe ser más potente que el de minter -grin ; peeeero, la A tiene un bug que impide progresar, o al menos lo he conseguido reproducir dos veces de dos.
Cuando entro a la pirámide y bajo a la pantalla inferior, la de la calavera y el cristal, no puedo descender correctamente por los ladrillos, concretamente se engancha siempre en el paso a la planta intermedia, no hay manera de descender.

Vaya, que casualidad, a mi me ha pasado algunas veces que Foggy parece ser incapaz de dejarse caer ... y si pulso derecha o izquierda, entonces si se cae. Parece que hay algo oculto y que depende de alguna variable que queda con valor inapropiado ...
Lo que puedo asegurarte es que la única diferencia entre las dos versiones es el tema del 'debouncing' del teclado que lo he eliminado en la version 'B', pero si esto redunda en algún beneficio, pues esta es la que nos quedamos ...
Y yo sigo en mis trece, yo cambiaba el color del inventario. En esa ventana la visibilidad es crucial y debe quedar el texto lo más nítido posible si no queremos que los que usen el vídeo compuesto se queden bizcos ;-)

Tengo tomada nota, pero como estamos con Kees haciendo cambios para poder definir los colores desde el lenguaje de macros, ya he implementado las funciones necesarias y parece que me funcionan ... veremos, de entrada mañana le subiré la versión FOG0U4X que es
la FOG0U4B con los cambios que estoy añadiendo y cuando esta versión funcione en la suite AGD, será el momento para ver como cambiar
los colores al entrar en el modo inventario y dejarlos como estaban al salir ... no me parece nada complicado. Voy a tener que mirarme
tus mensajes anteriores para ver que combinaciones te parecían mejor.
Por lo demás, absolutamente genial, si se consigue realizar la optimización a rutinas óptimas para el 6809, esto va a quedar suave, suave -thumbup.
De paso prepararé la que espero que sea la última entrega de gráficos PM3 (no se que hacer con el mapa y los "bricks", ¿lo corrijo?) y empezaré ya con los PM4 que será más poca cosa.

Perfecto! Por cierto me he dado cuenta de que, creo yo, que no estoy usando la última versión de PM3, lo revisaré antes de subirle la nueva
revisión a Kees
saludos
pere

jltursan
Mensajes: 2268
Registrado: 20 Sep 2011 13:59
Agradecido : 114 veces
Agradecimiento recibido: 310 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor jltursan » 06 Sep 2018 20:07

Perfecto! Por cierto me he dado cuenta de que, creo yo, que no estoy usando la última versión de PM3, lo revisaré antes de subirle la nueva
revisión a Kees


Es posible que sí que la uses, hay un error en los caracteres de la tubería que introduje en la última versión. Eso es lo que tengo pendiente de corregir.

Vaya, que casualidad, a mi me ha pasado algunas veces que Foggy parece ser incapaz de dejarse caer ... y si pulso derecha o izquierda, entonces si se cae. Parece que hay algo oculto y que depende de alguna variable que queda con valor inapropiado ...


Exacto, en la baja al nivel intermedio no puedes emplear ese truquillo y te quedas "entaponao". Por si las moscas volveré a probar una vez más cada versión y si todo queda igual lo confirmaré.

Avatar de Usuario
pser1
Mensajes: 2250
Registrado: 08 Dic 2012 18:34
Agradecido : 319 veces
Agradecimiento recibido: 355 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor pser1 » 06 Sep 2018 20:14

jltursan escribió:
Perfecto! Por cierto me he dado cuenta de que, creo yo, que no estoy usando la última versión de PM3, lo revisaré antes de subirle la nueva
revisión a Kees

Es posible que sí que la uses, hay un error en los caracteres de la tubería que introduje en la última versión. Eso es lo que tengo pendiente de corregir.
Vaya, que casualidad, a mi me ha pasado algunas veces que Foggy parece ser incapaz de dejarse caer ... y si pulso derecha o izquierda, entonces si se cae. Parece que hay algo oculto y que depende de alguna variable que queda con valor inapropiado ...

Exacto, en la baja al nivel intermedio no puedes emplear ese truquillo y te quedas "entaponao". Por si las moscas volveré a probar una vez más cada versión y si todo queda igual lo confirmaré.

Ya se que es como lo de salir y volver a entrar en el coche, pero ... quizás podrías descargar de nuevo el zip y comparar los ficheros binarios
para ver si son idénticos o al comprimir/descomprimir la primera vez algún byte quedo afectado.
Por cierto, el problema te pasa tanto en PM4 como en PM3 entiendo, ¿No?
saludos

Avatar de Usuario
minter
Mensajes: 2037
Registrado: 22 Jul 2014 18:51
Agradecido : 1510 veces
Agradecimiento recibido: 625 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor minter » 06 Sep 2018 20:22

Yo tuve un par de problemas subiedo por la escalera que sube a las nubes dl primer botiquín. Se me caía hasta la pantalla de abajo y me mataban. Era como si ni detectara los atributos de escalera y se volviera transparente. Y me mataban.
Lo que pasa es que lo de.morir en el.juego lo atribuyo a que soy un manta jugando.

jltursan
Mensajes: 2268
Registrado: 20 Sep 2011 13:59
Agradecido : 114 veces
Agradecimiento recibido: 310 veces

Re: Port del AGD de Z-80 a 6809

Mensajepor jltursan » 06 Sep 2018 21:30

Voy a soñar con el caminito, seguro -wacko2

Blanco y en botella, la A_PM3 falla, la B_PM3 funciona. Lo he descargado en el portatil (si hubiese habido corrupción el ZIP habría fallado por lo que descarto una mala descarga) y jugado de nuevo, el A sufre de enganchines y bloqueos, en el B Foggy se mueve libremente.

Aquí los dos snapshots antes de la pirámide, bajad hasta abajo si podéis con el A:

snapshots.zip
(61.38 KiB) Descargado 4 veces

Lo alucinante, es que he probado con el A_PM4...¡y me ha funcionado!, sólo he probado una vez pero ya es relevante, con el PM3 no he pasado ni una. ¿Cosa de la resolución y el desplazamiento de Foggy?


Volver a “Software Dragon”

¿Quién está conectado?

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