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

Páginas: 1 ... 6 7 [8] 9 10
106
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?

107
General / Re:Huevos de Pascua en los Juegos
« en: Enero 28, 2016, 10:52:13 »
En el Green Beret lo que soliamos hacer era saltar desde lo alto de alguna estructura y mantener presionada la tecla 1, que congelaba al personaje en ese lugar hasta que se soltara la tecla, era muy util para tomarse una pausa para pensar como seguir. Funcionaba en cualquier parte, pero era util hacerlo en una posicion donde no nos alcanzaran enemigos o balas.
No se si ese truco existe en el original, porque por aqui todo lo que se recibia era pirata, y por lo general estaba crackeado.

Te confirmo que ese bug estaba presente en el cassette original. Yo lo descubrí de casualidad y lo utilizaba estratégicamente. Por ejemplo, cuando al final de la fase 2 te atacan los perros, si saltas y pulsas 1 en lo más alto, te detienes en el aire y pasan todos por debajo :)

108
General / Re:Huevos de Pascua en los Juegos
« en: Enero 28, 2016, 10:49:13 »
En el Army Moves se puede leer lo siguiente en la posición F800 de RAM:

******************** HI TO ALL HACKERS, AND MANDY SMITH IF SHE’S
THERE. (LITTLE TART ). ANY FAN MAIL, SEND TO OCEAN SOFTWARE. ANY
EXTREMELY PRETTY BLONDES ( AGE 17+ ) LOOKING FOR A REAL MAN, THEN
PHOTOS IN THE POST A MOI ‘. NOW FOR A BIT OF INSIDE INFO ! EYES -
BLUE. HAIR – YES. SEX – SURE, ANYTIME.BRAINS – WELL, I’M WORKING FOR
OCEAN. FAVE GROUPS ARE :- LEVEL 42 – SIMPLE MINDS – AHA – WHAM -
DURAN-DURAN – MICHAEL JACKSON LEVEL 42′S LATEST LP ON CD IS MEGA BRILL
FAVE GAMES :- WHY ‘ARMY MOVES’ OF COURSE NO, I HAVEN’T GOT ANY FAVE’S.
TRAMPOLINING’S GOOD FOR A LAUGH, BONKING UP AND DOWN ( I MEAN
BOUNCING, DON’T I ?) ESPECIALLY WHEN THERE’S A GIRL WITH A BODY LIKE
H.NN.H’S, DOING IT AS WELL. HI TO PALS AT CANTERBURY COLLEGE – STEVE,
PAUL, MARK ETC. + ALL THOSE I’VE FORGOTTEN.WHY WERE DELTA AND NEMESIS
SO CRAP, AFTER GOOD REVIEWS ? MAYBE I’M JUST SPOILT BY THE ARCADE
MACHINES. I DUNNO. WHEN DO I GET A PORSCHE ? WHY DID SO MANY PLONKERS
BUY BREAKOUT II? WHO WATCHES MOONLIGHTING ? YES, ITS GOING DOWN THE
DRAIN. TAMING OF THE SHREW, MY BUM CAN CYBIL SHEPHERD ACT ? NOOO. CAN
BRUCEY BOY SING ? NOOO. IS NICK KAMEN A COMPLETE PLONKER,OR DOES HE
JUST ACT LIKE ONE ? WAS CROC DUNDEE GOOD ? BY THE WAY, IF YOU PLAY THE
CASSETTE ON SIDE B YOU SHOULD HEAR SAM FOX’S NEW SINGLE. IT’S CALLED
‘EEEEEEKKK !!! I DIDN’T MEAN DO THAT !’ IF THIS GAME GETS A BAD REVIEW
THEN OCEANS’ TAKE THE EDITOR OUT TO DINNER ISN’T WORKING ANY MORE.
OKAY, I’LL SIGN OFF NOW, BYE *** ZACKER

109
General / Re:Huevos de Pascua en los Juegos
« en: Enero 27, 2016, 19:09:03 »
Muy bueno!

Alguno rápido:

- En el The Last Ninja, cuando pasas a un enemigo con espada y vas a irte de la pantalla, se hace el harakiri (me encanta).
- En el Barbarian, pulsando unas teclas salían un mensaje "why did you press me?"
- En el Army Moves, en la memoria del juego debe haber un texto del programador donde incluso pone su tfno o algo así  para que le llamen chicas

110
Qué gran acierto fue encargar la 1541U2 hace ya unos cuantos años. Para mí es el mejor gadget que he adquirido. Con todos mis respetos para el SD2IEC. Con respecto al EasyFlash, lo increíble es que el 1541U2 es compatible con prácticamente el 95% de los ficheros .CRT que existen por lo que la compra de un EF3 físico deja de tener mucho sentido. Incluso mis cartuchos originales (Robocop 2, Navy Seals) no los pongo ya nunca porque simplemente elijo la imagen CRT equivalente dentro de mi colección almacenada en 1541U2. De ese modo me evito enredar en el puerto de cartuchos (me cargué un SID una vez porque debía estar yo con electricidad estática o algo así).


111
Desarrollo / Re:Técnica de multiplexación Usagi Yojimbo
« en: Diciembre 12, 2015, 21:10:50 »
Los 144 sprites me imagino que es la parte de las letras en toda la pantalla, tremendo.

Los 9 sprites en linea no me doy cuenta en que parte, estas intros hacen tantas cosas increibles que 1 sprite más ni me doy cuenta.

Wow! Esto no lo conocía!

Por lo que leo, se puede hacer el truco con el sprite 0 y sólo en una de cada dos rasterlines. Es el "3" de las letras de abajo

112
Desarrollo / Re:Técnica de multiplexación Usagi Yojimbo
« en: Diciembre 11, 2015, 14:43:04 »
Es físicamente imposible que haya más de 8 sprites en la misma línea.

Lo que se puede hacer es pintar 8 en una línea Y, y más abajo (Y+21 líneas, el tamaño de de un sprite) volverlos a pintar, y de paso cambiar todas sus características: posición X, color, frame, etc.

En un juego tipo Armalyte o Commando, los sprites están "diseminados" por toda la pantalla con diferentes alturas Y. En ese caso, mientras controles que no coincidan más de 8 en la misma Y, es relativamente fácil multiplexarlos. Lo difícil es cuando se amontonan muchos sprites en filas contiguas (Y, Y+21, Y+42).


113
Desarrollo / Re:Técnica de multiplexación Usagi Yojimbo
« en: Diciembre 11, 2015, 11:28:05 »
Es muy complejo pero efectivamente garantiza ausencia total de flicker. Podéis comprobar lo mismo en Double Dragon 3 o Altered Beast.

En el Green Beret, que usa un multiplexer "clásico" pero muy efectivo, prácticamente no hay glitches. Pero si os fijáis, cuando disparas el lanzallamas o hay balas y varios enemigos a la vez (muchos sprites a la misma altura) entonces si se nota.

114
Desarrollo / Re:Técnica de multiplexación Usagi Yojimbo
« en: Diciembre 10, 2015, 20:52:31 »
En el caso de Usagi Yojimbo se usan los timers para hacer interrupciones en posiciones específicas del raster.

Por ejemplo para pintar el sprite A en la posición Y de la pantalla se programan los registros al principio del frame (línea del raster = 0). Luego hay que programar una interrupción en la línea 10 del sprite. Para ello se programa el timer para que interrumpa justo en el momento en el que el raster ha barrido hasta esa línea (desde la 0, hasta la Y+10). Luego lo mismo para la siguiente interrupción, etc.

Los valores del timer se ajustan mediante prueba y error, hasta dar con las constantes adecuadas. Como hay 4 timers, se puede hacer el proceso cuatro veces, usando como parámetro las cuatro posiciones Y de los personajes.

Si hubiera más personajes, este sistema no valdría. Habría que usar las interrupciones de Raster, precalculando cuántas hay que hacer, en qué orden y en qué posición...

115
Desarrollo / Re:Técnica de multiplexación Usagi Yojimbo
« en: Diciembre 10, 2015, 18:48:45 »
Están rippeadas directamente de la memoria del juego ;)

Creo que la confusión es por un detalle importante que se me ha olvidado. Si cambias la posición Y de un sprite mientras se está pintando, ésto no tiene efecto hasta que se ha pintado entero. Pero sí se puede cambiar el "frame" del sprite a mitad.

Si te fijas es coherente con mi "intento de explicación":

El sprite A son las orejas de Usagi.

El sprite A/C tiene la mitad inferior igual que el A, y la mitad superior es "nueva".

Imagina que cuando se ha pintado la mitad del sprite A, cambio al frame A/C y actualizo su posición 21 pixels para abajo. El raster sigue pintando el sprite (faltan 10 líneas de la posición Y original) y durante 10 líneas pinta los datos de A/C, que son lo mismo (esas líneas son iguales que A).

Cuando ya se ha pintado el primer sprite (21 líneas mezcla entre A y A/C) el VIC pinta de nuevo el sprite en su nueva posición Y que es justo la siguiente línea. Durante las 10 primeras líneas, pinta el frame actual (A/C) que tiene la mitad de la cabeza de Usagi.

¿Me sigues?


116
Desarrollo / Re:Técnica de multiplexación Usagi Yojimbo
« en: Diciembre 10, 2015, 17:58:47 »
Maniako, es un puto lío y para escribirlo mismamente me he tenido que estrujar el coco y editarlo 20 veces.

Lo que pasa es que yo en su día pude meter un montón de horas para analizar el código y experimentar para ver qué demonios estaba haciendo... Luego en Lemon hubo algún experto que reconoció la técnica y arrojó algo de luz...

117
Desarrollo / Re:Técnica de multiplexación Usagi Yojimbo
« en: Diciembre 10, 2015, 17:43:16 »
Añado imágenes que espero valgan más que 1000 palabras!

118
Desarrollo / Re:Técnica de multiplexación Usagi Yojimbo
« en: Diciembre 10, 2015, 17:12:14 »
Estoy viendo que mi post ha quedado bastante denso y lioso...

Imagina que quieres pintar a un personaje compuesto por dos sprites contiguos en el eje Y. Uno para torso y otro para piernas (Double Dragon, etc):

A
B

Si queremos usar el mismo sprite hardware multiplexado, tenemos que pintar A y luego programar una interrupción para "bajarlo" 21 pixels y cambiarle el frame a B. Para ello la interrupción tiene que ser super ajustada: Justo cuando el raster acaba de pintar la última línea de A, pero antes de que empiece a pintar la primera de B. Si te retrasas, en lugar de pintar primeras líneas de B serán las de A (saldría "el pelo" del personaje en el pubis). Si te adelantas, saldrían las primeras líneas de B en mitad de A (el pubis a la altura del pecho).

Para que quede "clavado" habría que hacer el cambio en los pocos ciclos de raster que hay entre que se acaba de pintar A y se empieza B. Si tienes un único personaje y nada más cambia, se podría hacer con una interrupción estable. Sin embargo, si por ejemplo estás en una badline (depende del scroll Y de la pantalla) se te retrasaría (al haber menos ciclos). Además, si tienes más sprites en las inmediaciones, te van a quitar ciclos y harán que tu IRQ se adelante o retrase en función de cuando le toque hacer el cambio -> chungo.

Sin embargo si pre-calculo y añado un sprite auxiliar A/B tal y como explicaba antes... Si realizo una interrupción que pase de A a A/B, si la hago durante cualquiera de las 11 últimas líneas de A no voy a notar nada porque los datos gráficos son iguales. Estoy cambiando el sprite pero el resultado en pantalla es el mismo (durante la mitad inferior). Como tengo 10 líneas de margen para hacer la transición, aunque mi IRQ llegue tarde, no va a pasar nada. Si la hago en la línea 11, funciona y me sobra tiempo. Si lo hago en la línea 21 (peor caso) sería equivalente a cuando no ponemos transición (interrupción "abrupta") y habría el mismo riesgo.


Luego se hace lo mismo con A/B->B.






119
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.

 ;)

120
Juegos / Re:Argos
« en: Noviembre 23, 2015, 09:48:28 »
Talos se suponía que era todo de bronce salvo un único punto en el talón con un clavo que protegía su única vena. En la leyenda original, al regresar los Argonautas con el Vellocino de oro y Medea, ésta última le hechiza y aprovecha para quitarle el clavo y desangrarlo.

En la película, se lo encuentran en el viaje de ida.Me encanta la peli y los efectos de stop-motion de Harryhausen.

@Dany Quest, yo encantado de hablar contigo cuando quieras!

Páginas: 1 ... 6 7 [8] 9 10