Autor Tema: Re-iniciándome en la programación del C64  (Leído 1493 veces)

migrator

  • Commodorista
  • ***
  • Mensajes: 67
  • SYS 0
    • Ver Perfil
Re:Re-iniciándome en la programación del C64
« Respuesta #15 en: Agosto 25, 2019, 00:36:59 »
Pues ahora que lo dices... tienes razón, detectando primero si hay colisión por hardware puedo evitarme hacer cálculos cuando no sea necesario. Serviría siempre que el sprite se mueva por un fondo plano. No sé, tiene toda su lógica.


josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 9578
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Re-iniciándome en la programación del C64
« Respuesta #16 en: Agosto 25, 2019, 00:38:06 »
Lógica tiene, otra cosa es que funcione o sea práctico :P

Eso lo deberían decir los que han hecho cosas.

Dashiad

  • Commodorista
  • ***
  • Mensajes: 99
  • SYS 0
    • Ver Perfil
Re:Re-iniciándome en la programación del C64
« Respuesta #17 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..



josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 9578
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Re-iniciándome en la programación del C64
« Respuesta #18 en: Agosto 25, 2019, 12:41:59 »
Se nota cuando alguien sabe de verdad y cuando otros hablamos desde fuera :P

migrator

  • Commodorista
  • ***
  • Mensajes: 67
  • SYS 0
    • Ver Perfil
Re:Re-iniciándome en la programación del C64
« Respuesta #19 en: Agosto 25, 2019, 12:48:35 »
Citar
El comprobar primero  colisiones por hardware puede quitarte trabajo..El problema es...para qué quieres esos ciclos?

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. Así que lo que intento es hacerlo de la forma más eficiente posible, por eso me planteo las diferentes opciones que se me presentan para probarlas y analizar su viabilidad dentro de un proyecto complejo y no solo en la prueba de cada una de ellas por separado.

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.

Citar
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..
Obviamente los enemigos tienen que estar en coordenadas del mundo, pero una vez en pantalla yo lo gestionaba por coordenadas locales. Guardaba las dos coordenadas, unas para conocer su situación en el mundo y saber cuando debían aparecer y otras para lo que ocurría en pantalla. Lo mismo hacía para los objetos y el resto de los elementos del juego.

Y esto me lleva a replantearme, gracias a tu comentario, si no será mejor guardar solo los dos tipos de coordenadas para el jugador y gestionarlo todo según las coordenadas del mundo... se ahorrarían unos cuantos bytes, a costa de la posible rutina de conversión de esas coordenadas globales a locales. Me lo apunto para probarlo.

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

No sabéis lo que os agradezco todos los comentarios, entre ellos y los enlaces que habéis publicado me están dando una visión más amplia de lo que es un desarrollo completo en ML.
« última modificación: Agosto 25, 2019, 12:51:02 por migrator »

Dashiad

  • Commodorista
  • ***
  • Mensajes: 99
  • SYS 0
    • Ver Perfil
Re:Re-iniciándome en la programación del C64
« Respuesta #20 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! :-)


migrator

  • Commodorista
  • ***
  • Mensajes: 67
  • SYS 0
    • Ver Perfil
Re:Re-iniciándome en la programación del C64
« Respuesta #21 en: Agosto 26, 2019, 09:26:05 »
Citar
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???"
Exactamente lo que me pasa. Exactamente lo mismo que cuando comienzas a programar y generas el típico "código espagueti", si la cosa funciona la calidad del código es lo que menos te importa. Con el tiempo, la práctica, los proyectos y el conocimiento aprendes a estructurarlo todo y llega un punto en que te horrorizas de hacer algo que años atrás (y la ignorancia) te harían sentirte orgulloso.

¿Ves? esto último que has comentado del raster es de las cosas que más me van ayudar en el planteamiento. Antes solo utilizaba el raster para el dibujo de los gráficos (y de paso como timing para retrasar la ejecución en el caso de que ésta fuera demasiado rápida), y para controlar el número de ciclos de una rutina mediante el clásico cambio de color del borde, pero no me había planteado dividir la ejecución del programa en pequeños procedimientos que se ejecutarán en determinadas interrupciones del raster para mantener un timing constante dentro del programa. Es lo que tiene no haber hecho nunca nada totalmente en ensamblador, y es lo bueno que tiene preguntar a quienes realmente saben.

Seguimos aprendiendo y probando cosas nuevas...

josepzin

  • Administrador
  • Commodore Master
  • *****
  • Mensajes: 9578
  • Commodoreador web
    • Ver Perfil
    • Mi blog
Re:Re-iniciándome en la programación del C64
« Respuesta #22 en: Agosto 26, 2019, 12:42:32 »
Impresionante lo de Dashiad... :O

Dashiad

  • Commodorista
  • ***
  • Mensajes: 99
  • SYS 0
    • Ver Perfil
Re:Re-iniciándome en la programación del C64
« Respuesta #23 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.