Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.


Mensajes - Dashiad

Páginas: [1] 2 3 ... 6
1
General / Re:Nuevos juegos publicados
« en: Enero 07, 2019, 18:04:37 »
Habeis comentado el Wolfling? No estoy seguro de si ya esta terminado o si aun estan trabajando en el. Yo aun no lo he probado.
Me he bajado lo que hay en csdb, y no tengo ni idea de cómo salir de la primera pantalla..
Por mi proyecto de juego, me fijo mucho en la gestión del scroll de los juegos que veo...Aunque he visto muy pocos juegos de todos los que hay para C64 (especialmente, de los modernos), no recuerdo que en los 80 se usara éste tipo de scroll.En los juegos que recuerdo, el personaje estaba normalmente en el centro de la pantalla, y el mapa se movía junto con el personaje.
En éste juego (y también, aunque ligeramente distinto, en el  Sams Journey), el scroll es más inteligente: la referencia para mover el mapa no es directamente el personaje, sino la dirección en la que mira el personaje.
Si el personaje se mueve a la derecha, el scroll tiende a dejar al personaje a la izquierda de la pantalla.Más se mueve hacia la derecha, más a la izquierda queda el personaje, dejando ver más mapa en la dirección en la que se mueve.
Alguien conoce otros juegos que implementen este tipo de política de scroll?

2
General / Re:IND: preservación de material [hilo oficial]
« en: Diciembre 11, 2018, 14:16:38 »
Yo hace unos meses compré un libro del que no tengo otras referencias:
"Commodore 64 para niños" , de A. Dahl
(En Amazon sí que existe una referencia al libro, pero no está disponible:
https://www.amazon.es/Commodore-64-Para-Ninos-Children/dp/848615393X)

Es bastante curioso por el tipo de lenguaje que usa (y por las analogías que hace para ayudar a los niños a entender las cosas: usa continuamente el ejemplo de una máquina de escribir, lo cual complica doblemente las cosas a los niños de hoy...comprobado...)
No tiene demasiadas páginas, debería ser posible escanearlo, pero qué software aconsejáis para hacerlo?

3
Mercadillo / Re:Importacion de lote de discos 5.25 para C64
« en: Diciembre 03, 2018, 00:39:28 »
Una caja de 10 discos 3M que he recibido hace poco, pesa 238 gramos (pesado con mi balanza), y según la declaración del paquete, 0.23 Kg, asi que coincide.

Desgraciadamente, se equivocaron de tipo al enviarlo...Y no tengo ni un floppy para probar decentemente la unidad de disco que compré..
Así que, si al final los consigues...Ya tienes otro para hacer negocioss :-P

4
General / Re:Commodore 64 de Lego
« en: Diciembre 02, 2018, 01:46:38 »
Si, salió hace algunas semanas en el canal de Perifractic...muy chulo..y sí que está a la venta:
https://www.perifractic.com/Perifractic/Takeout_Store/Entries/2018/11/17_Brixty_Four__Metallic_Black_Base.html

(Aunque no son precisamente baratos)

5
Programación / Re:Problemas con scroll suave a toda pantalla
« en: Diciembre 02, 2018, 00:47:26 »
Sigo por donde lo dejé..
A partir de la segunda imagen, el algoritmo debería ser:

- Por cada fila del mapa en pantalla: (5 o 6)
      - Por cada tile de la fila en pantalla: (10 o 11)
             - Por cada fila del tile: (entre 4 y 1)
                    - Por cada caracter de la fila (entre 4 y 1)
                          - Dibujar el caracter en la posición de pantalla correspondiente. (1)

Eso son 4 bucles anidados, y, enmedio, hay muchos punteros a calcular, variables que mantener, y condiciones que comprobar (bordes).

El objetivo tiene que ser, simplificar en lo posible ese bucle.Todo lo que haya dentro, va a impactar exponencialmente el tiempo de pintado. Lo ideal es dejarlo en bucle muy simple, parecido al que mostraba i03862 en su ejemplo.

En el código de i03862 , a partir de ciertos puntos fijos en la pantalla, indexando con X, se muestra un caracter de una lista, indexada por Y.

En el caso de los tiles, la idea es exactamente la misma.
Los puntos en pantalla a "fijar", son las posiciones donde empieza cada tile.En la imagen 1, los puntos de pantalla, serían:
1024 --> comienzo del tile 0
1028 --> comienzo del tile 1
....
1184 --> comienzo del tile 20

Esos son los puntos de "destino".Los puntos de "fuente", están en la memoria de tiles:
$2000 --> comienzo del tile 0
$2010 --> comienzo del tile 1
....
$2140 --> comienzo del tile 20

Entonces, lo que sería ideal sería un código del tipo:

LDA $2000,X  ; Leemos del tile 0
STA 1024,Y  ; Escribimos en la posicion de pantalla donde va a estar el tile 0
LDA $2010,X  ; Leemos del tile 1
STA 1028,Y   ; Escribimos en la posicion de pantalla donde va a estar el tile 1
...

X se debe incrementar hasta que llegue a 16. Cada 4 incrementos de X, Y se debe incrementar en 36, para pasar a la linea inferior de la pantalla.
Así, estamos pintando más de 1 tile a la vez. Mi código dibuja una fila completa de tiles (10 u 11) en el bucle.Por lo que el bucle se ejecuta tantas veces como filas de tiles hay (5 o 6).

Y de esta forma tenemos un bucle muy simple, que es la idea inicial.
Para llegar a ese tipo de bucle, sólo tenemos que precalcular los puntos de inicio en pantalla, los puntos de inicio de los tiles, y almacenar estos punteros SOBRE el propio bucle (modificando el código), antes de saltar a él.

Pero esto supone que el mapa está 100% alineado...Qué ocurre si no lo está?
Lo que se me ocurrió, es aplicar un par de ideas.

El problema del alineamiento se trata diferente en X y en Y.
Primero, cómo tratar el problema en Y
Lo que no quería, era convertir la primera y ultima linea, en casos "especiales", que me llevaran a introducir comprobaciones dentro del bucle.
Se hace "al revés".
Mirando la imagen 2 del post anterior, para el tile 0, mi código calcula una posición de pantalla de (1024-40-1) = 983. Es decir, va a generar un código del tipo:

LDA $2000,X
STA 983, Y

Y lo que va a hacer, es cambiar el offset inicial, haciendo que cuando entra por primera vez en el bucle, X se ha cargado con un  6, e Y con un  41, por lo que empieza a pintar en la posición correcta.

Que la primera linea se dibuje así, viene muy bien.Los punteros de pantalla a la fila siguiente, se calculan  sumando 160  (4*40)  a los punteros de la fila anterior.Si la primera fila no se calculara así, no se podría simplemente sumar para calcular los siguientes.Sería un caso especial, y eso significa condiciones que gastan ciclos.

Eso gestiona el offset en Y. Ahora toca gestionar el offset en X
Si el offset en X es 1, como en la imagen 2, lo que significa es que si estamos pintando la posición 0,4,8 o 12 del tile, hay que pintar en el ULTIMO tile. Y en el resto de los casos, pintar en el primero.

Esto se hace, de nuevo, almacenando el offset en X , SOBRE el programa.Después de cada dibujar cada linea de caracteres, y cuando se suma 36 al registro Y para pintar en la siguiente linea, además, se suma 4 a esa posición del programa donde se almacena el offset.

Es decir, al pintar una fila de tiles, se van a dibujar 4 lineas de caracteres.Al dibujar la primera linea, en el caso de la imagen 2, la condición que existe en el programa, es:
Código: [Seleccionar]
dbucle   CPX #$00  ; Este 00, será sobreescrito por el offset en X, en este caso , '1' : CPX #$01
         BCS tilecp0    ; Si es igual o mayor, se dibuja el tile 0
tilecp10  LDA PT_CURTILELO,Y  ; Si no, se dibuja el tile 10.
          STA $0400,X
         JMP tilecp1     ; Y se salta al tile 1
tilecp0  LDA PT_CURTILELO,Y   ; Dibujado del tile 0
         STA $0400,X   
tilecp1  LDA PT_CURTILELO,Y
         STA $0400,X

En este trozo de código, que es parte del bucle principal,se ve que las posiciones de origen y destino de todos los tiles, son las mismas.. porque en realidad, cuando se vaya a ejecutar el bucle, se habrán sobreescrito con los punteros precalculados.
Cuando se termina de dibujar una linea completa de caracteres, se suma 36 a X, para pasar a la siguiente linea, y se incrementa en 4 el contenido de dbucle+1, con lo que el CMP se hará sobre '5'.

Y esto explica más o menos en qué consiste el nucleo del código. El resto es principalmente precálculo de los punteros.

6
Programación / Re:Problemas con scroll suave a toda pantalla
« en: Noviembre 30, 2018, 00:51:21 »
Como ejemplo:

  - Tiles de 4x4
  - Memoria de mapa comienza en $1000
  - Memoria de tiles comienza en $2000
 
    Supongamos que el mapa es de 20x10 tiles. O sea, ocupa 200 bytes, y en caracteres, 160x80 caracteres.
    Esos 200 bytes están incializados a:
    0,1,2,3,4,5......200

    Los tiles van a ser:
    @@@@ AAAA  BBBB  CCCC
    @@@@ AAAA  BBBB  CCCC
    @@@@ AAAA  BBBB  CCCC
    @@@@ AAAA  BBBB  CCCC

    y asi, hasta el caracter 200. Cada posicion de mapa tiene un tile distinto.

   Se dejan las ultimas 5 lineas para marcador.

     
    Si pintamos la coordenada 0,0 de mapa (con el 0,0 arriba a la izquierda), los tiles a pintar van a ser los de la primera imagen (no sé como ponerla inline...)
    El primer tile es el 0...y debajo de él , está el tile 20
   
    Aquí, el mapa está alineado con los tiles: hay 10 tiles en horizontal, 5 en vertical (50 tiles en total)

    Pero qué ocurre si nos movemos en diagonal hacia abajo? Ocurre lo que pasa en la segunda imagen: el mapa no está alineado con los tiles, y queda una zona donde entran nuevos tiles. El resultado es que hay 11 tiles en horizontal, y 6 en vertical (66 tiles en total)

Si llamamos MAPX y MAPY , a las coordenadas X e Y en el mapa, esas coordenadas nos dan 1 tile.
Si llamamos MAPTILEX y MAPTILEY a las coordenadas en X e Y del tile que está arriba a la izquierda, eso nos da un offset dentro del tile.

En la imagen 2, tendríamos un MAPX=0, MAPY=0, MAPTILEX=1, MAPTILEY=1
(En este ejemplo, MAPX va de 0 a 19, MAPY de 0 a 9, MAPTILEX de 0 a 3 y MAPTILEY de 0 a 3)

Mirando la imagen 2, verás que todos los tiles que hay en el borde, están afectados por MAPTILEX , MAPTILEY, o ambos.

Eso significa que, en una implementación simple, el bucle de pintado ya empieza a tener unas cuantas comprobaciones que hacer...
Pero eso no es el mayor problema.
Lo "natural" sería pintar primero el tile 0, luego el tile 1, tile 2, tile 3....

El tile 0 comienza en $2000.
Según la imagen 2, hay que copiar:

$2000+4+1 ($2005)-->$0400
($2006) --> $0401
($2007) --> $0402

Ahora llegamos a la siguente fila del tile.Como el primer caracter no se ve, por el scroll, el puntero a la memoria de tiles, hay que incrementarlo en 2, y el puntero a la memoria de pantalla, en 37 (40 - 3)

($2009) --> $0428 
($200A) --> $0429
($200B) --> $042A

De nuevo, en la siguiente fila del tile 0:
($200D) ---> $0450 
...

Una vez pintado el primer tile, habría que calcular la posición en pantalla del comienzo del tile 1, y repetir

Si empiezas a pensar cuántas condiciones, comprobaciones, sumas y multiplicaciones (sólo para ir al comienzo de un tile en memoria, hay que multiplicar por 16, o sea, resultado de 2 bytes) vas a necesitar para pintar todo el mapa, verás que se empieza a poner complicado...


7
Programación / Re:Problemas con scroll suave a toda pantalla
« en: Noviembre 29, 2018, 22:51:11 »
Aqui va el código.
Está hecho con el C64 Studio, aunque el mapa de tiles tiene formato del CBM Prg Studio.
El asm de entrada es "main.asm".

Puedes activar o desactivar que pinte la memoria de color, cambiando la primera linea de config.asm (drawColor=1)

Al ejecutarlo, la zona de pantalla con fondo blanco indica qué parte del raster se ha consumido para pintar el mapa.
Es un mapa de tiles 4x4, pintando en pantalla 40x20 caracteres (5 lineas inferiores para marcador).En charmap.asm está la definición de caracteres, tiles, y mapa (el mapa ahora mismo no tiene sentido...)

Pero creo que va a ser muy criptico entender qué hace, a base de mirar el código..Yo mismo he tenido que reescribirlo un par de veces porque ni yo mismo, pasado un tiempo, lo entendía...Está muy optimizado, y yo ya casi me he quedado sin ideas sobre dónde conseguir 1 ciclo más..
(Por cierto, que esta versión que subo aquí, con respecto a la que puse anteriormente, ha corregido un caso en el que el pintado tardaba más de 1 frame)

Ahora escribo un post sobre pintado de mapas con tiles, donde más o menos se vean los fundamentos, y así  se pueda entender mejor el código.

8
Programación / Re:Problemas con scroll suave a toda pantalla
« en: Noviembre 29, 2018, 19:46:24 »
Sobre los tiles, lógicamente, depende del tipo de  juego que quieras hacer, pero si va a usar scroll, entiendo que quieres que el mapa tenga unas cuantas pantallas.
Si el mapa se mantiene en memoria como tú indicas (lo que yo llamo "descomprimido"), 32 pantallas ocuparían 32Kb (a 1Kb por pantalla, por simplificar, independientemente de marcadores y todo eso).

Si haces un matamarcianos, 32 pantallas te darian para, digamos, 4 fases de 8 pantallas de largo...Lo cual, si se adapta al juego que quieres hacer, pues te puede valer.
En la memoria de mapa, lo que se guarda es el indice del caracter a pintar.

Pero si hacemos grupos de 4x4 caracteres (tiles):
AAAA  BBBB
AAAA  BBBB
AAAA  BBBB
AAAA  BBBB

El mapa ahora se almacena como una secuencia de tiles.
En la memoria de mapa, no se guardan caracteres, sino el ìndice de tile.
Cada tile ocupa 16 bytes. Supongamos que se permiten 256 tiles distintos. En total, tenemos 4096 bytes, por lo que nos quedan ahora 28Kb de los 32Kb que hemos reservado para mapa.

Una pantalla, que es de 40x25 (por simplificar, 40x24), requiere entonces 10*6 tiles, 60 bytes, para almacenarse. Y en los 28Kb que nos quedan, podemos guardar 28*1024/60 pantallas, o sea, 477 pantallas.

Hemos pasado de 32, a 477.

Pero supongamos que hacemos metatiles, en grupos de 4x4 tiles. En el mapa, lo que tenemos ahora, son indices a metatiles, los cuales tienen indices a tiles, los cuales tienen indices a caracteres.
Seguimos teniendo 256 tiles, lo que son 256*16 bytes , 4096 bytes.
Permitimos 256 meta-tiles, lo que son otros 256*16 bytes, otros 4096 bytes.
Ahora, de los 32Kb, hay 24 Kb de mapa : (32Kbs - 4Kbs de tiles - 4Kbs de metatiles).

Cada metatile son 16x16 caracteres = 256 caracteres, por lo que 1 pantalla entera, se guarda en 4 metatiles, lo que son 4 bytes. Con 24Kb disponibles para mapa...Puedes tener 6144 pantallas. Aproximadamente, sería un mapa de 80x80 pantallas.

Lógicamente, los metatiles suponen muchisima repetición. A lo alto, una pantalla es sólo 1 metatile y medio (24 caracteres). Ese tamaño de mapa, es para un juego de rol, o algo parecido, donde las ciudades se harian con metatiles especificos, y el resto (bosques, rios, etc), con repeticiones de tiles gigantes

O se pueden hacer metatiles de 2x2 tiles, (8x8 caracteres), que no provoca tanta repetición, y todavía da para un mapa de 40x40 pantallas.

Lo que hemos fijado es la memoria (32Kb). Si lo que fijamos es el tamaño del mapa, usar metatiles o tiles siempre va a ocupar mucha menos memoria.

Pero, lógicamente, todo esto complica (mucho) las rutinas de pintado.

Usando mapa descomprimido, con scroll fino, la posición de la esquina superior izquierda de la pantalla es :
- x de mapa, y de mapa --> da un caracter
- x de scroll fino, y de scroll fino.

Si metes tiles, la posición de la esquina superior izquierda de pantalla es:
- x de mapa, y de mapa --> da un tile
- x de tile, y de tile  ---> da un caracter
- x de scroll fino, y de scroll fino.

Si metes metatiles, la posición de la esquina superior izquierda, es:
- x de mapa, y de mapa --> da un metatile
- x de metatile, y de metatile --> da un tile
- x de tile, y de tile --> da un caracter
- x de scroll fino, y de scroll fino.

Y a eso es a lo que llamo añadir indirecciones, que hay que resolver al pintar el mapa. De los 3 registros, uno (X) lo vas a necesitar para la memoria de caracteres...Tienes sólo el Y para resolver los pasos de mapa a tile, de tile a caracter, etc.

Lo "normal" es meter tiles, de 2x2, de 4x4 o de 5x5...Los metatiles son para mapas muy bestias..
Más tarde subo mi código para mapas con tiles de 4x4...El código se complica "un poco".

9
Programación / Re:Problemas con scroll suave a toda pantalla
« en: Noviembre 28, 2018, 21:00:24 »
Por lo que veo, es una variación de las rutinas de limpiado de pantalla.
Pero mientras no controles donde está el raster, y dónde pintas, lo normal va a ser que te parpadee.

Estás fijando el mapa a una lista de bytes sobre la que vas iterando.Sin embargo, un juego que tenga scroll, muy posiblemente vaya a requerir un mapa más complejo.En cuanto se complica la forma en la que está el mapa en memoria, el desenrrollar bucles empieza a no ser tan sencillo...

Ahora mismo, tienes una indirección (usando x), sobre la memoria de pantalla, y una indirección (usando y), sobre el mapa. El mapa es "procedural", ya que se "genera" a través de código (el registro y hace overflow y comienza otra vez desde cero).
Si lo que tienes es un mapa real en memoria, incluso si está 100% descomprimido, ( o sea, tienes el mapa entero, carácter a caracter, en memoria), no vas a poder pintarlo así. Y aquí es donde empiezan a sumarse ciclos al código.
Lo normal es que tengas un mapa basado en tiles de 4x4, 5x5 u 8x8...Y, si tienes metatiles (grupos de 4x4 tiles), el mapa está guardado como secuencias de metatiles, que hay que resolver a sus tiles, que hay que resolver a los caracteres, y entonces pintar en pantalla. Y es aqui donde empiezas a perder ciclos de reloj, sobre todo si también tienes que pintar la memoria de color.

10
Programación / Re:Problemas con scroll suave a toda pantalla
« en: Noviembre 28, 2018, 12:37:43 »
Yo vivo en Madrid, y me apunto a cualquier quedada sobre programación del C64!! Cuando lo hacemos?

11
Programación / Re:Problemas con scroll suave a toda pantalla
« en: Noviembre 28, 2018, 00:31:11 »
Yo casi aseguraría que el problema está en que estás dibujando caracteres por delante y por detrás del raster.
Las variables scrloc01....16, las estás usando para intentar pintar en toda la pantalla a la vez, incrementando solo x.
Eso hace que estés poniendo caracteres en muchas "y" distintas, tanto si ha pasado el raster por allí, como si no.
Es decir, para x=0, dibujas en srcloc01,x .Suponte que en ese momento el raster está exactamente en esa posición.
Empiezas a dibujar en srcloc02,x , luego en 03,x.. Esas posiciones están más abajo.Sin embargo, el raster sigue pintando la fila donde está srcloc01.
Posiblemente, cuando incrementas x, y vuelves a srcloc01,x , el raster, de las 8 lineas que tiene que pintar para esa fila, le ha dado tiempo a pintar 2 o 3.
Y ahora actualizas esa fila, que está a medio dibujar por el raster, y vuelves a ir hacia abajp.
Cuando vuelves a pintar en todos los srcloc0X, y vuelves al 01, el raster ya ha pasado por ahi.Esa linea no te va a dar problemas ya (aunque no es la correcta), sino que vas a alcanzar el raster una línea más abajo (en 02)
Y eso es por lo que sale el patrón en diagonal. El raster viaja de izquierda a derecha, y tú estás pintando de arriba a abajo.
En el código que subí en este post, aún no uso scroll fino, porque buscaba velocidad pintando un mapa de tiles (ahora busco tiempo para implementar metatiles). Ese código se basa en dibujar siempre por detrás del raster, y no tiene parpadeos, sin usar doble buffer.

Pero, para no "adelantar" al raster, si en la parte de arriba de la pantalla (40 caracteres), hay 10 tiles, pinto la primera fila de los 10 tiles, luego la segunda fila de los 10...Si pintara el primer tile completo, luego el segundo, etc, estaría pintando por delante y por detrás del raster.

De todas formas, ten en cuenta que ese modelo de pintado, aunque "cómodo" (sólo hay que actualizar x), cuando pongas un mapa real, muy posiblemente no lo puedas usar.



12
General / Re:Pi1541... alguien la tiene ya?
« en: Octubre 16, 2018, 22:07:51 »
Yo la he montado este fin de semana...He montado primero la versión sencilla en una breadboard , y cuando he visto que tiraba, la he montado en una placa y añadido los botones.
Yo no sé nada de disketeras, fastloaders, etc, por lo que no he probado demasiado...pero los cuatro o cinco discos que he cargado, solo uno ha dado un problema..pero creo que no tengo el último firmware.
Todo muy casero, pero funciona  :D

13
Programación / Re:Mapas en c64 con scroll
« en: Septiembre 16, 2018, 23:04:52 »
Pues aqui está, al fin, la primera implementación del pintado de mapas, y, por ahora, consigo dibujar tanto la memoria de video como la de color en menos de un frame, usando tiles de 4x4 y color por caracter (no por bloque).
Hay 1 restricción: el color del caracter viene dado por su código de caracter. Es decir, al dibujar el caracter "1", ese "1" va a la memoria de video y a la de color. Es decir, la letra "A" siempre sería blanca.
El algoritmo no está basado en mover la memoria de video  (o de color ) sobre sí misma, sino en la coordenada de mapa.En cada frame se calculan los tiles visibles, y se copia de la memoria de tiles, sin doble bufer.
Por ahora dejo un par de prg, ( necesitan ser arrancados con SYS 8192 ), uno de ellos repinta sólo la memoria de video, y el otro repinta también la de color.
El scroll funciona con el joystick, y por ahora no usa el scroll hardware.Es un mapa de 40x40 tiles de 4x4.

Aún queda bastante por optimizar, para hacer que con sprites en pantalla, y con las interrupciones necesarias para reutilización de sprites, el tiempo de pintado se mantenga por debajo del frame.

El fondo blanco se activa para visualizar la duración del pintado.
 

14
Si es la panera, mira si llegan y salen los voltajes correctos de los reguladores...Dicho de otra forma, en la patilla superior derecha del SID, qué voltaje ves cuando se queda la pantalla en negro?
Te lo digo porque a mi me daba pantalla en negro por el conector de alimentación, que estaba algo suelto..Y puede parecer que es un problema de poner o quitar un chip, y lo que ocurre es que el movimiento que le das a la placa al quitarlo y ponerlo sea lo que genere contacto o no.

15
General / Re:Emulación de disketera usando sólo arduino (mega)
« en: Junio 01, 2018, 13:23:11 »
Otra cosa interesante, es investigar algo esto:

https://github.com/markusC64/1541ultimate2

Por lo que he visto en fotos, la FPGA que utiliza la ultimate2 no es tan grande ni tan cara (logicamente, la U2 tiene más cosas que simplemente la FPGA), pero entre hacer un fork de la Pi1541 (que aún está muy en desarrollo, según el log de github), e investigar si es posible sacar sólo la parte de disco de la U2 e implementarla para una FPGA pequeñita...No sé, las dos cosas están interesantes.

Páginas: [1] 2 3 ... 6