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 - migrator

Páginas: [1] 2 3 ... 5
1
Programación / Re:Re-iniciándome en la programación del C64
« 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...

2
Programación / Re:Re-iniciándome en la programación del C64
« 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.

3
Programación / Re:Re-iniciándome en la programación del C64
« 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.


4
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 25, 2019, 00:05:41 »
Citar
A qué llamas offset aqui?
Citar
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

Precisamente eso es lo que hago en el punto 1, restarle el alto del borde (a lo que estoy llamando offset) a la coordenada y del sprite para igualar el 0 del sprite y el 0 de los caracteres.

Citar
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).

Hace tiempo que no programo nada en ensamblador del C64 (o C16), pero recuerdo que cuando hacía algo con scroll mayor que la pantalla guardaba unas coordenadas en el mundo y otras locales a la pantalla y calculaba todo lo local en referencia a esas coordenadas en la pantalla. Las coordenadas en el mundo solo las utilizaba para lanzar eventos especiales, como alcanzar cierto lugar del mapa.

He estado viendo alguno de los fuentes del enlace de josepzin y cuando llego a las colisiones... ¡utiliza las colisiones por hardware! así que tendré que seguir revisando otros ejemplos.

Estás haciendo que le dé muchas vueltas a la forma en la que realizarlo, me gusta, me gusta. Así es como se aprende. Muchas gracias.

5
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 24, 2019, 09:13:53 »
Pero cierto, no se cómo hacéis vosotros, pero yo para los gráficos digo siendo clásico. Prefiero dibujarlos "a la antigua" sobre el papel milimetrado y luego pasarlos a un editor, me da la impresión de que lo puedo controlar todo más.

6
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 24, 2019, 08:27:06 »
Gracias por el aporte.

Sí, ya caí en ello, por eso realizo el cálculo del carácter bajo el Sprite teniendo en cuenta que los caracteres son de 8x8.

Tras calcular las relativas al carácter bajo el sprite, las paso (de nuevo) a coordenadas de pantalla, les vuelvo a sumar el Offset y calculo la diferencia entre ese resultado y las del Sprite, sabiendo que me tiene que dar un resultado entre 7 y 0, con lo que reposiciono el Sprite hasta que este resultado sea 0.

Es decir, algo así para la coordenada Y de un sprite:

Supongamos un sprite en (x,79).
Supongamos un OFFSET en Y de 29.

    1.- Restamos el offset a la coordenada del sprite para obtener su posición en la parte de texto (el fondo) de la pantalla.

79-29 = 50

  2.- Ahora calculamos la coordenada de un carácter ahí situado, para ello lo dividimos entre 8 y obteniendo el entero (no necesito realizar cálculos de decimales, así que con tres desplazamientos de bits a la derecha me sirve. Esto me dará el carácter en el que se encuentra la parte inferior de sprite, pero yo necesito el que hay bajo él, así que le sumo 1

50/8 = 6 + 1 = 7  <-- Esta será la fila del carácter

  3.- Como hemos despreciado los decimales, hago la conversión inversa para obtener la diferencia real entre el carácter y el sprite.

7*8 = 56 + 29 (offset) = 85 <-- Esta es la coordenada equivalente del carácter bajo el sprite

Teniendo esto, sé que la diferencia entre las coordenadas del sprite y del carácter es:

85-79 = 6 <-- Esto es lo que queda entre el "suelo" y el sprite, que siempre ha de ser inferior a 8, así que ajusto el sprite para que sea 0 (exactamente encima de él).

Estoy haciendo pruebas calculando también el carácter en el que se encuentra el sprite e igualando a 7 (justo por encima del siguiente).

De esta forma me está funcionando. Además, sabiendo la posición del carácter, lo recojo para saber qué carácter es y, de esa forma, saber el tipo al que corresponde y si hay que ignorarlo en el cálculo (por ser atravesable) o no.

Esto me está funcionando perfectamente. 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 ;D

Por eso no sé si me estoy liando un poco y si hay formas más sencillas de hacerlo, ya que este método son muchos cálculos y muchos ciclos en cada redibujado, que ahora está bien pero cuando haya más cosas que calcular no sé, no sé.
Es hora de seguir practicando y poner en práctica todo lo que aprenda con los enlaces que me habéis pasado.

7
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 23, 2019, 15:32:37 »
Pues estoy en ello, dándole vueltas al tipo de lío en el que me quiero meter.
En el C16 deje inconcluso un juego de un explorador que quedaba atrapado en una caverna y tenía que salir de ella (original al 100%, lo sé). Era una aventura de las de buscar objetos y usarlos en el sitio correcto. Pero el guión era muy rocambolesco con situaciones un tanto absurdas (había zonas a las que se accedía por cuerdas, otras por escaleras y algunas que solo eran accesibles ¡agarrado a un globo! que había que conseguir de una forma determinada tras encontrar el helio para inflarlo. Incluso había que ir a la NASA para colarse en un cohete y llegar al cielo, en donde San Pedro nos daría la llave de... ¡De locos! Habría que darle un par de vueltas a ese guión. Lo que con 15 años nos parece un prodigio de imaginación, con cierta edad uno se pregunta qué se había fumado en aquel entonces.
Ya tenía hecho el mapeado y los gráficos (y lo tengo todo localizado después de tanto tiempo), que habría que actualizar un poco si me pongo a ello.

Así que esa es una opción, pues se me quedó la espinita clavada. Pero para comenzar estaba pensando en algo más sencillo como paso previo.

Lo importante es disfrutar con lo que se haga e intentar hacerlo lo mejor posible.

Ya iré informando (y preguntando), y si consigo que vaya adelante nunca vienen mal colaboradores. Pero ahora mismo no voy a pedirle a nadie que colabore en un proyecto sin que haya algo sólido y pueda garantizar que no se trabaje por nada.

Pero se agradece tener a tanta gente entusiasta de este maravilloso equipo, y con tantos conocimientos como hay aquí.

8
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 23, 2019, 11:06:09 »
Muchas gracias. ¡A estudiar!

9
Programación / Re:Re-iniciándome en la programación del C64
« en: Agosto 23, 2019, 10:28:09 »
Gracias, xwolfoverride.

No, la pantalla no es scroll. Hice puebas de scroll para refrescar un poco el ensamblador, pero, de momento es una pantalla estática.

Me quedo con lo que me has dicho de que el método que utilizo es el correcto. Es básicamente lo que quería saber. Sabiendo esto, se me plantea la posibilidad de hacerlo de dos formas:

1.- Recoger esos datos (laterales y las dos esquinas inferiores) mediante una interrupción, para tener controlado en todo momento el sprite, y guardarlos en memoria para poder capturarlos en la rutina de movimiento.
2.- Hacerlo solo en la rutina de movimiento.

Con la primera opción tendría siempre controlado al sprite, pero serían ciclos perdidos en el caso de no producirse ningún movimiento. Con la segunda el sprite solo lo controlaria si se produce movimiento, ahorrando ciclos pero dependiendo de las condiciones almacenadas la última vez que se movió. Como tengo varias ideas sobre qué juego hacer ya me decidiré por una u otra según las necesidades.

Por otra parte, para las pantallas me había planteado tener una tabla para el diseño de cada una de ellas en la que los primeros bytes sirvieran de puntero hacia la rutina de comportamiento de su contenido (enemigos, mayormente). No sé si esto es lo adecuado o, por el contrario, es mejor generar un patrón de movimiento para cada tipo de enemigo y simplemente pasarles, en cada pantalla, los parámetros particulares de cada una de ellas.

¡Buff, ya no estoy tan acostumbrado al ahorro de ciclos y memoria como hace 30 años!
¡Cómo ha ido cambiando en estos años la forma de de enfrentarse al desarrollo de una aplicación!

Últimamente me estoy leyendo (y releyendo en el caso de muchos libros clásicos) y aprendiendo cosas que antes había pasado por encima por no necesitarlas.
También estoy buscando el código de algún juego clásico comentado para poder analizarlo, pero no encuentro ninguno.

Al menos no empiezo de cero, pero me da que voy a ser bastante pesado por aquí si quiero llevarlo a buen puerto.

10
Programación / Re-iniciándome en la programación del C64
« en: Agosto 23, 2019, 08:53:05 »
Hola a todos.

Últimamente me ha dado por ponerme de nuevo con la programación del C64. Bueno, en realidad iniciarme con la programación del C64, pues yo salté del C16 al Amiga, aunque hice algunas cosillas en el C64.

La cuestión es que en mis tiempos mozos ;D me dedicaba a realizar versiones propias para el C16 de los juegos de C64 que veía en casa de mis amigos, y me quedó el gusanillo de hacer algo serio para el C64.
Siempre utilicé el lento BASIC con algunas rutinas en código máquina para acelerar determinadas cosas (el C16 carece de sprites por hardware, y ahora me he propuesto hacer un juego totalmente en ensamblador. Pero, aquí está el problema, hay muchas cosas básicas que todavía me quedan por aprender. Os cuento.

Para refrescar un poco el CM he programado algún scroll de texto, contadores decimales en pantalla (para puntuaciones) , capturas de teclado, control de RAM de pantalla y de color, movimiento de sprites, música por interrupciones, multiplexación de sprites y otras cosas básicas.

Por cierto, estoy usando el CBMprgStudio.

Lo último que he hecho es un Sprite que cae desde la parte superior de la pantalla y parándose sobre los caracteres que defino como "suelo", para control de colisiones como paso previo para un juego de plataformas.

El problema, que no sé si es la "forma correcta" de hacerlo o si hay alguna manera más sencilla y/o directa.

Básicamente recojo las coordenadas de sprite, les resto las no visibles (el offset) las convierto a las coordenadas del caracter bajo el Sprite. Recojo el carácter que hay en esa posición y si es un carácter "sólido" compruebo la diferencia entre las coordenadas de éste y del Sprite y ajusto el Sprite hasta que esa diferencia sea 0 para que quede bien posicionado sobre el carácter "suelo".
Esto me funciona en esta prueba, pero en un juego me obligaría a hacerlo en las 2 esquinas inferiores del Sprite (los pies) y en los laterales (para controlar las paredes).

¿Sería está la forma correcta o me estoy liando mucho?

Otra cosa. Me imagino que hay diferentes métodos para almacenar las pantallas con enemigos y sus movimientos, pero ¿Alguna más o menos sencilla que me sirva como guía para adaptarla a lo que necesite?

Tampoco sé que rutinas sería interesante (o necesario) meterlas en interrupciones, ¿Entrada, colisiones, movimiento de sprites...?

Toda ayuda me vendría genial, porque aunque tengo bastante experiencia programando juegos nunca lo hice totalmente en ML. Para aprender hay que darse muchas tortas, pero siempre que se aprenda la dirección adecuada, no para estrellarse continuamente contra un muro por no saber hacia dónde ir.

Muchas gracias.

11
Lo pedí en cuanto me enteré de su existencia. Aunque solo fuera por el precio, 5.03€ en Amazon, merece la pena.
Lo tengo desde hace unas tres semanas y solo comentar algunas cosillas:

1.- Es un libro obligado para todo amante del C64
2.- Todos los ejemplos se pueden descargar desde el blog, complemento esencial al libro.
3.- Como libro de referencia y consulta no está nada mal, siempre que conozcas algo de ML.
4.- Como libro de aprendizaje, le faltan ejercicios que obliguen a estrujarse un poco el cerebro para ir asentando lo aprendido. Aunque sé que ese no es el espíritu del libro, no estaría mal incluir alguno al final de cada capítulo.

En definitiva: ¡Felicidades por el libro!, totalmente recomendable.


12
General / Re:Commodore 64 de Lego
« en: Diciembre 04, 2018, 22:54:06 »
Pues no sabía que se vendía. Habrá que echarle un ojo, a ver si los Reyes...  ;)

13
General / Commodore 64 de Lego
« en: Diciembre 02, 2018, 00:34:59 »
No sé si ya lo conocéis, pero por si acaso.
De todos los Commodore 64 totalmente hechos de Lego que he visto, este es sin duda el mejor.
Una pena que no esté a la venta.

https://www.microsiervos.com/archivo/juegos-y-diversion/brixty-four-commodore64-lego.html

14
Commodore Amiga / Nuevo Workbench 3.1.4 para amiga classic
« en: Octubre 01, 2018, 21:42:44 »
Pues parece ser que tras tiempo de desarrollo y tras las primeras beta, y alguna retirada por bugs, Hyperion lanzó ayer domingo 30 de septiembre la actualización del Workbench 3.1. La primera gran actualización tras AmigaOS 3.5 y 3.9 y un gran lavado de cara (y de bugs) del veterano 3.1.

http://hyperion-entertainment.biz/index.php/where-to-buy/direct-downloads/188-amigaos-314


15
Off-topic / Re:Consulta sobre remake
« en: Octubre 05, 2017, 19:44:51 »
No, no te creas, con un C64 pelado corre sin problemas. Hasta creo que podría hacerlo funcionar en un VIC20.
 ;)

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