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 ... 7
1
General / Re:Guía de hardware nuevo para C64
« en: Septiembre 23, 2019, 21:18:08 »
He montado el unijoysticle de @rik (en plan casero) y va muy muy bien!!

Es muy de suponer que van a salir muchas cosas más basadas en el ESP32: Con bluetooth, wifi y la potencia que tiene (hasta 240Mhz,con 2 cores), se podrían unir en un solo dispositivo varias funciones, y a un precio de risa (4 euros en aliexpress).
Ya hay emuladores completos basados en el ESP32:

https://www.youtube.com/watch?v=CS1qRkNlhy0

El proyecto con 11 emuladores (desgraciadamente, el C64 aún no está disponible):
https://github.com/retro-esp32/RetroESP32


2
Programación / Re:Controlador inalámbrico para c64
« en: Septiembre 04, 2019, 19:32:56 »
Ahh..@josezpin me pasó el link a la versión 2, que es exactamente lo que buscaba!

3
Programación / Re:Controlador inalámbrico para c64
« en: Septiembre 04, 2019, 19:21:13 »
@riq,
Si no he leido todo muy mal, esto va por WiFi...Sería posible montarlo usando sólo bluetooth?
Entiendo que el problema de montarlo por bluetooth es, sobre todo, el soporte HID para los gamepads..
He estado mirando, por un lado, el soporte de bluetooth HID en ESP32, y parece que está:
https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/bluedroid/ble/ble_hid_device_demo
Por otro lado, está, para arduino, con el shield de usb host, soporte para gamepads de PS4 usando bluetooth (https://github.com/felis/USB_Host_Shield_2.0/blob/master/PS4BT.h)

Evaluaste la opción de montarlo sólo con bluetooth, o por las cosas que querias hacer te venia mejor WiFi?

4
Con un tester, puedes comprobar si las soldaduras del hat están bien. Yo he tenido ese tipo de problemas cuando montaba la mía, y eran soldaduras que estaban mal.
En algún lado del hat está el conversor de niveles..habría que comprobar los dos lados del conversor, tanto hacia el cable serie, como hacia la pi:

* wiring.png (193.66 kB . 1500x760 - visto 59 veces)

5
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 26, 2019, 19:19:44 »
Eh, eh...No os confundáis, que ni de una forma (no he terminado nunca un juego!) ni de otra (hay muchas cosas que aún no controlo!) esos comentarios son más que ideas que leo o que voy desarrollando poco a poco.
Que todo va dirigido por el raster, es algo conocido...El que entonces, se lleve todo el bucle según el raster, es mi opinión / idea. De hecho, mi bucle principal es en realidad 8 punteros a rutinas.
Hay una rutina a la que se llama cada linea de raster
Otra, a la que se llama cada dos lineas de raster
Otra, cada 3, etc
Pero esto es cosa mia...Estoy mucho más interesado en discutirlo, y ver qué se nos ocurre, que en intentar parecer que sé mucho de lo que hablo.

6
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 25, 2019, 18:44:47 »
No es que quiera esos ciclos para nada, ahora mismo, simplemente no quiero consumirlos a lo tonto. En las primeras fases puede que un consumo excesivo de ciclos no importe al no apreciarse, pero en fases más avanzadas, con más información que manejar, esos algoritmos mal planteados pueden llegar a ser un quebradero de cabeza.
Eso es...Lo que digo es que la referencia de cuántos ciclos consume, debe ser en el peor caso posible.Si optimizas un caso que no es el peor posible, que te permite ahorrar ciclos sólo en determinadas circunstancias, no te va a valer de mucho.

En cuanto al timing, por lo que comentas, me imagino que solo se trata de que todo fluya en más o menos el mismo tiempo en cada bucle del juego pero con las pequeñas diferencias que pueden surgir para que de la sensación de fluidez. Obviamente no puede tardar x en un dibujado y 1,5x en el siguiente, todo tiene que estar dentro de unos patrones.
Supongo que sabes los problemas que da "que te adelante" el raster mientras estás dibujando en pantalla...Media pantalla se queda en un frame actualizado, mientras la otra mitad muestra un frame antiguo..Lo que lleva, como minimo, al parpadeo de la pantalla o de los sprites..

Es por eso que el timing del juego normalmente  esta dirigido por dónde está el raster.
Por frame, teniendo en cuenta "bad lines", tienes 18656 ciclos, dependiendo del numero de sprites, distribuidos en 312 lineas de raster.
Si quisieras llegar a pintar en cada frame (50 frames por segundo en PAL), en esos ciclos tendrías que meter completo el bucle de juego.
El pintado comenzará en una línea X de raster, y, si necesita, en el peor de los casos, de, digamos, 150 lineas de raster para finalizar, pones una interrupción en a linea 0 del raster (en realidad, no sería ahi...es solo un ejemplo).
Lo primero que podría hacer esa rutina, es poner una nueva interrupción, en la linea 151 de raster, para ejecutar las rutinas de movimiento.Que, si en el peor caso, toman 30 lineas de raster, lo primero que hace es poner una nueva interrupción, en la linea 181 de raster...
Por eso digo que, si en algunos casos, el movimiento, o las colisiones, o lo que sea, en vez de tomar 30 lineas de raster, toman 20, eso no va a cambiar que la siguiente fase comienza en la linea 181 de raster (o es muy dificil de aprovechar).

O sea, que el bucle de juego no va en un while(1), y si el juego se acelera/decelera poco, no se va a notar..En cuanto empieces a pintar fuera de sincronía con el raster, empezarán las cosas raras.
Además, seguramente usarás el raster para multiplexar sprites, cambiar modos de video, etc, lo cual aumenta la dependencia con el raster.

¿Por qué a los 15 años no me surgían tantas dudas? Si se me ocurría una forma de hacer una cosa y funcionaba pasaba a la siguiente y tan contento?
Aqui tienes toda, toda la razon del mundo. Con 15 años,sabías lo que sabías, así que pasaba uno a la acción de cabeza, y listo...En cuanto tienes muchisima más información, has pasado por muchos proyectos...Has pasado de la mentalidad de "ir al grano", a la mentalidad de "y si luego quisiera hacer esto?" que te permite la tecnología moderna...
Antes, ibas al grano, porque era lo que sabías. Ahora, si hiciera uno exactamente lo mismo, tendría un montón de conocimientos en la cabeza gritando "Pero qué chapuza estás haciendo???"

Y esto lleva a una reflexión que me parece interesante...Niños de 19 y 20 años, en los 80, con el conocimiento justo, sacaban juegos en 4 meses, programando directamente sobre la máquina..Y, encima, iban aprendiendo nuevas cosas, haciendo cada vez mejores juegos.
Ahora nos podemos llevar años sólo mirando tutoriales, videos, e historias, pero seguir paralizados y no acabar de sacar 1 juego.

Yo creo que hay dos alternativas: o sacar un juego, de cabeza, con lo que uno sepa, sin preocuparse de nada más, sólo de terminarlo...O ponerse a informarse de todo, leerlo todo, repensarlo todo, optimizar y depurar cada cosita,esperando algún día hacer el "megajuego"...

En la comunidad creo que hay de ambos tipos de personas..Pero creo que es importante decidir en cual de las dos opciones se mete uno, para evitar frustrarse, que es lo que hay que evitar a toda costa! :-)


7
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 25, 2019, 02:53:12 »
El comprobar primero  colisiones por hardware puede quitarte trabajo..El problema es...para qué quieres esos ciclos?
Me explico: Si te ahorras n ciclos en un determinado frame, no puedes "acelerar" pintar el siguiente , o tocar la música antes, o mover antes..Todo debe ir regido por un ritmo que se tiene que mantener.
En cada frame, habrá cosas que requieran siempre el mismo numero de ciclos (la música), y otros, un numero variable (el movimiento, las colisiones...). De las cosas variables, el juego debería estar diseñado para mantener el ritmo en los casos peores (en este caso, multiples colisones de sprites).
Entonces, tienes A ciclos para mover, B ciclos para colisionar, C ciclos para actualizar estado, D ciclos para pintar...Si haces que, en algunos casos, B se resuelva en menos tiempo, no va a cambiar el momento en el que se debe ejecutar C.

Pero, aqui se vuelve al frameskip. Si nuestro juego, en el caso peor de colisiones, sólo es capaz de repintar cada 3 frames,pero en el caso mejor, fuera capaz de repintar cada 2, sería una forma "indirecta" de usar esos ciclos ganados.

Sobre coordenadas de pantalla vs coordenadas de mundo: supongamos que hay un enemigo justo en el borde de la pantalla.Nos movemos y el scroll hace que quede fuera.Volvemos ahora hacia atrás.Si no almacenas la posición del enemigo (en coordenadas de mundo), el enemigo podría haber desaparecido. No es que sea malo, hay muchos juegos que hacen eso..



8
Mirando este documento:
http://www.zimmers.net/anonftp/pub/cbm/programming/serial-bus.pdf
y un arduino, podrías ver si las señales que se están intercambiando, son las correctas.

Como ahora te dice DEVICE NOT FOUND, el siguiente párrafo es de ayuda:

When ATN is pulled true, everybody stops what they are doing. The processor will quickly pull the
Clock line true (it's going to send soon), so it may be hard to notice that all other devices release the
Clock line. At the same time, the processor releases the Data line to false, but all other devices are
getting ready to listen and will each pull Data to true. They had better do this within one
millisecond (1000 microseconds), since the processor is watching and may sound an alarm ("device
not available") if it doesn't see this take place.


(Nota: aqui "True" es 0V, y false son 5V )
Asi que un pequeño programa en Arduino que esperara a que ATN bajara a 0V, luego a que CLK bajara a 0V, e inmediatamente pusiera a 0V la línea de DATA, debería ser bastante para que, al menos, el error de DEVICE NOT FOUND desapareciera. Si desaparece, el problema puede estar en el hat.

9
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 24, 2019, 23:47:48 »
Supongamos un sprite en (x,79).
Supongamos un OFFSET en Y de 29.
A qué llamas offset aqui?
La posición del sprite la defines por su esquina superior izquierda del sprite "hardware", por el bounding box de la parte "activa" del sprite (cuadrado que contiene a todos los pixeles no transparentes de un determinado frame/estado), o por el centro del sprite (o bounding box)?

Si el sprite es 24*21, pero el area dibujada (en un cierto frame/estado), es de 18x16, es a eso a lo que llamas "offset"?
Si es eso, ese bounding box puede estar precalculado, no hace falta hacer la resta en cada iteracion (que creo que es lo que haces en el paso 1) ).

Para los puntos 2 y 3, se podría jugar restando a la posicion del sprite, la diferencia entre el 0 del sprite, y el 0 de pantalla. Con esa resta, los 3 bits menos significativos dan "los decimales", mientras el resto de bits da el caracter.(Estoy sólo pensando en voz alta...son cosas que tengo "apuntadas" para cuando me meta en estos problemas)
La única forma en la que veo que puede fallar es en la que tú comentas, pero solo por movimientos superiores a 8 píxeles, en los que el desplazamiento sea superior a 1 carácter y, por lo tanto, se quedarían caracteres intermedios sin calcular y alguno podría ser un muro o suelo y nuestro sprite lo saltaría.  La solución fácil, el personaje no utilizará armas con balas, sino un potente láser que lo atraviesa todo
Tampoco puede desplazarse (saltando, cayendo, etc) más de 8 pixeles a la vez.
Hay más casos en los que utilizar el registro de posición de los sprites para almacenar la posición del personaje, da problemas:
- Como decía antes, cuando quieres hacer frameskip sin perder velocidad en el juego.
- Cuando el personaje se puede mover, con scroll, por un mapa más grande que la pantalla (diferencia entre coordenadas de mundo, y coordenadas de pantalla).

10
Cuidado con ese modelo de fuente, que puedes encontrarte sorpresas debajo de esa placa:
https://commodoremania.com/foro/index.php/topic,2018.msg31845.html#msg31845

Si hay algo roto, puede que te esté haciendo contacto ahora..y en dos días, te vuelva a dejar de funcionar

11
He revisado el cable serie con el tester y está bien por lo que me temo que pueda ser el 7406 del Commodore pero en mi caso tengo un Commodore 64C y creo que será otro chip porqué el U8 es uno de 64 pines.
Mi pi1541 la monté yo, así que no sé cómo va con el display OLED.Yo la uso con la salida HDMI, y ahi ves las señales que se intercambia la raspberry con el C64. Si conectas la pi por HDMI, ves algo?

El cable serie del hat, va a un conversor de niveles, el cual está conectado a los pines de la pi...Has comprobado también ese lado?

Viendo cómo se comporta, parece que las lineas de ATN y de CLK están bien, ya que si no, te debería dar un DEVICE NOT FOUND (si recuerdo bien de mis experimentos con arduino). O sea, el C64 se está dando cuenta de que hay algo conectado al puerto serie (se ha producido al menos el handshake con la señal de ATN)..por lo que miraría la línea de DATA.


12
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 24, 2019, 00:13:50 »
Hola! Yo estoy en lo mismo que tu, haciendo tonterias previas a algún juego serio...Tras haber montado mapa con scroll, ahora estoy liado con la estructura general del juego.

Sobre lo que comentas, yo pondría un "pero" a una cosa:
Básicamente recojo las coordenadas de sprite, les resto las no visibles (el offset) las convierto a las coordenadas del caracter bajo el Sprite.
Dependiendo del juego, que la posición del sprite sean las coordenadas guardadas en los registros del VIC, puede servirte o no.
Supón que tienes una bala hecha con un sprite, que se mueve X pixeles en horizontal, en cada repintado. Si las coordenadas de la bala son las del sprite, podría atravesar una pared que tuviera menos de X pixeles de ancho.
Si la bala se mueve de 8 en 8 pixeles, y puede haber paredes de hasta 4 pixeles de ancho, la bala, en cada actualizacion, debería moverse 4 pixeles, comprobar colisiones, luego otros 4...Básicamente, interpolar.

O sea, la idea sería romper la dependencia entre el repintado y el movimiento.
En algunos juegos, cuando habia mucho enemigo en pantalla, se ralentizaba todo. Se podría hacer que el juego repintara cada frame, o cada 2 frames, o cada 3, pero que las cosas no fueran más "lentas", porque el movimiento y las colisiones seguirian calculándose cada frame. Si las posiciones las guardas directamente en los registros de los sprites, tendrías parpadeos y cosas raras en pantalla.


13
Comprado!
Por algún motivo (nostálgico), las cosas del C64 me gusta tenerlas en papel...

14
Programación / Re:Mapas en c64 con scroll
« en: Febrero 27, 2019, 00:57:51 »
Añadido scroll por hardware, y comienzo de posicionamiento de la pantalla según la dirección de movimiento del personaje. Esto aún queda por pulirlo bastante. La idea es que si el personaje se mueve en una dirección, vea lo máximo de pantalla en esa dirección. La estructura interna del código ha cambiado, ya con más forma de juego que de simple test.
Pero, al cambiar la estructura, algunas optimizaciones aun no las he migrado.Esto se nota en que, durante el scroll, el color naranja usado en el fondo,que indica la duración de la rutina de pintado de pantalla, tiene un borde inferior que va cambiando de posición, indicando que, según el offset en X, la rutina de pantalla dura más o menos, cosa que hay que optimizar.Este problema seguramente es más grave en el eje Y (cuando lo añada!)
Me he pasado al C64 studio....Me gusta más el ACME que el assembler del CBM prg studio.

Aún hay que arrancarlo con sys 8192

15
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?

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