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.


Temas - Zub

Páginas: [1]
1
Desarrollo / Mazinger C64 (Preview) - Playtesting
« en: Mayo 26, 2018, 17:58:48 »
Abro hilo nuevo para compartir con vosotros la Preview del Mazinger C64 que se ha mostrado en Explora Commodore y que como sabéis se lleva cocinando hace tiempo...



https://mega.nz/#F!UAU1VBwL!yBjLqNGQxwllEaWsRENQvw

Se trata de una versión preliminar con 3 niveles, no tiene todavía la intro ni toda las músicas de Gryzor, pero quería que podáis  jugar y opinar, cualquier feedback es bienvenido (sed buenos). Importante leer el manual ya que hay bastantes controles. Supongo que el juego puede resultar chungo para el jugador casual, espero que haya algunos interesados-frikis que perseveren.

Me interesa sobre todo vuestras impresiones sobre los controles, A.I. de los enemigos, etc. Al ser una especie de beat'em up, es difícil conseguir un equilibrio para que no sea ni muy difícil ni muy fácil (que no haya el típico truquito que te permite vencer fácil).

Espero que os guste. Un saludo a todos!


2
General / Mazinger C64
« en: Septiembre 13, 2016, 19:23:34 »
Commodoreros y niños setenteros en general.. Este proyecto está más vivo que nunca...





Seguiremos informando  ;)

3
General / Pack Erbe 88
« en: Febrero 01, 2016, 13:21:41 »
El otro día en un arranque nostálgico me puse a mirar en Google acerca de aquel lejano "Pack Erbe 88" que como tantos otros conseguí que me regalaran hace mil años. Sin duda, lo único que buscaba era acceder al Operation Wolf que era la recreativa del momento (impagable el momento cuando vi la cabina con la Uzi la primera vez). Los amigos de Erbe fueron listos y nos "obligaron" a comprar el pack entero para poder acceder a ese título, con varios títulos de su desarrolladora in-house (Topo Soft). En C64 nos venían:

* Chicago's 30. [Horrible]
* Silent Shadow. [Dos jugadores simultáneos, pero bastante malo]
* Mad Mix Game [Aprobado]
* Psycho Pigs UXB. [La gran sorpresa, un jueguillo realmente divertido, sobre todo a dobles]

El Operation Wolf es para mí un clásico del C64. Excelente conversión, que además usa técnicas realmente avanzadas e ingeniosas en su implementación. Creo que acertaron al sacrificar gráficos y detalles para tener una versión mono-carga.

Pregunta: En los múltiples artículos de internet pone que fue la campaña navideña de 1987 cuando Erbe sacó el pack, pero estoy prácticamente seguro de que se equivocan. Fue al año siguiente (navidades del 88) a modo de recopilatorio de juegos ya hecho ese año, y con la novedad del Op Wolf. La review de este último en Zzap es enero del 89 (concuerda) y además todos los juegos se publicaron en 1988. ¿Lo podéis confirmar?

4
Desarrollo / Técnica de multiplexación Usagi Yojimbo
« en: Diciembre 10, 2015, 15:50:16 »
A mi me lo explicó una persona que lo desensambló.. pero creo que no se trata exactamente de cronometrar con los timers de las CIAs sino de generar interrupciones con dichos timers (en un momento determinado). La multiplexación de sprites se sigue haciendo mediante interrupciones pero en vez de éstas ser generadas por el VIC (raster) son generadas por los timers de las CIAs.

Desconozco que ventajas o inconvenientes puede tener este sistema, así a priori y sin conocerlo me parece más cómodo manejar interrupciones raster.

He visto un post antiguo que menciona este asunto. He visto que se quedó este tema en el tintero y creo que puedo arrojar algo de luz :)

La dificultad para multiplexar sprites en este tipo de juegos es que todos los sprites se concentran en "filas" contiguas. El esquema clásico de ordenarlos en el eje Y e ir asignando interrupciones de raster no funciona bien porque al estar muchos contiguos (sprite de torso -> sprite de piernas) la transición es demasiado abrupta y se produce flicker o incluso se pierden sprites. Aún así es posible hacerlo (Double Dragon 3 es el mejor ejemplo) con el truco que os voy a explicar, y añadiendo más lógica a la rutina IRQ de raster. Básicamente, cuando actualizas un sprite para multiplexarlo, tienes que comprobar si existen N sprites más en una altura similar y procesarlos de golpe.

En el caso de Usagi Yojimbo, la idea de los timers es confusa al principio pero si lo pensáis es bastante ingeniosa. Existen 4 personajes en pantalla, que tienen dos sprites de ancho y 3 de alto (6 en total). Cada personaje tiene su timer, que se programa para avisar del momento en el que hay que actuailizar la posición Y del sprite. Es totalmente equivalente a lo que se suele hacer con Raster, pero al ser 4 fuentes independientes de interrupción, no hay que preocuparse de la relación entre ellas. Es decir, cada timer actualiza a su personaje en función de su posición Y en pantalla, sin importarle de en qué posición estén los otros 3. Con interrupciones de raster como os comentaba antes, se hace mucho más lío.

Sin embargo la técnica anterior no soluciona el tema de las transiciones rápidas (la problemática es igual). Pero otra cosa grandiosa de este juego (copiado en Altered Beast y Double Dragon 3) es la "copia on the fly de sprites intermedios". Imaginad que el personaje de Usagi está compuesto por los siguientes sprites:

AB
CD
EF

Queremos asignar el Sprite hardware 0 a la columna ACE, y el 1 a la columna BDF. Para simplificar nos centramos en la parte izquierda (ACE). Tenemos que pintar el sprite 0 en la posición A, y luego actualizar su posición 21 pixels para abajo y actualizarlo a C. Luego repetir lo mismo de C a E. Para evitar la problemática de la transición tan abrupta, hace lo siguiente:

- Los sprites no están directamente alojados en el banco del VIC sino que se almacenan (por cierto, comprimidos) en otra zona de memoria. Para pintar A,C,E habría que copiar dichos sprites al banco gráfico (copiar 3*63 bytes). En el caso de Usagi, además hay que descomprimirlos... Todo ello en tiempo real, creo que a 25 fps.

- En lugar de copiar los 3 sprites A,C,E "a pelo", lo que se hace es copiar 5 sprites. 2 de ellos son transiciones generadas "on the fly" que tienen la mitad superior (10 filas) del sprite superior, y 11 filas del inferior:

A
A/C
C
C/E
E












El timer no programa 3, sino 5 interrupciones para actualizar el sprite: A->A/C->C->C/E->E

¿Qué se consigue con ésto? Cuando llegan las transiciones de un sprite a otro, al estar los personajes casi todos a la misma altura se acumulan las IRQ. TEned en cuenta que son 2 sprites por personaje y 4 timers. Perfectamente puede ocurrir que tengas que actualizar los 8 sprites a la misma altura, y que cuando vayas por el 5 el raster que pinta la pantalla ya esté bastante por debajo de la zona de transición.

Al habilitar estas transiciones, se da un margen de 10 líneas para cambiar el sprite de valor. Cuando el raster pasa de pintar A a A/C, te puedes adelantar y cambiarlo mucho antes de la transición porque el contenido de las 10 últimas filas de ambos es igual.

De este modo se puede "apilar" varias veces un mismo sprite en el eje Y sin tener el más mínimo glitch ni flicker. Por supuesto, la contrapartida es CPU (copia de sprites en tiempo real) y memoria adicional para almacenar las transiciones.

Este mismo esquema se usa en DD3 pero sin compresión.  Fijaros que al hacer copia "on the fly", solo hace falta definir los sprites en una dirección X. Si el personaje se da la vuelta, al copiar se invierten los bytes en tiempo real. De este modo ahorras mucho espacio para tener más frames.

 ;)

Páginas: [1]