Karoshi MSX Community

Pues he probado el JAIL BREAK de Spectrum y lo cierto es que no hay por donde cogerlo. Es malo con ganas, de verdad. No creo que el MSX se merezca que le hagamos algo así.

Por otra parte, haciendo un poco de arqueología comparada, he dado con sutiles diferencias que explican bastantes cosas. Por ejemplo, ¿porque los usuarios de MSX piensan que el juego JOE BLADE es malo y los usuarios de Spectrum dicen que está bien? Pues bien sencillo, porque hay bastantes cambios entre uno y otro, y sale perdiendo con diferencia la versión de MSX. Es decir, las animaciones tienen la mitad de frames (4 pasos en ZX, sólo 2 en MSX), la velocidad se reduce a la mitad de FPS, el sonido PSG brilla por su ausencia (sólo efectos, como en la versión ZX48) y el salto en MSX no es suave, sino que tiene dos posiciones, al más puro estilo barrio sésamo, arriba y abajo.

Lo cierto es que he estado jugando a la versión de Spectrum y es un juego muy curiosón. Y la versión de MSX no está a la altura, la verdad. Técnicamente es mucho más pobre y aparece "podada" respecto a la de ZX. Por cierto, que el que está todavía mejor es el JOE BLADE 2, que desgraciadamente no vio la luz para MSX. La versión de ZX tiene unos gráficos estupendos.

Por cierto, ya que me aburría he hecho una versión ROM (16 KB) para MSX con el juego original de cassette. La tenéis aquí: Joe Blade (ROM) (http://www.robsy.net/joeblade.rom). A disfrutar :)

Muchas gracias, Robsy  :D Por cierto, ya que te aburrías, ¿por qué no estabas con el Final Lap? (ah, sí, es que no hay MSXtremo, jejeje)  ;D

Bueno, te paso el pedazo de código fuente de la conversión de CAS a ROM:

Previo: PACK JOEBLADE.CAS

Programa:

Creo que tampoco es difícil, ¿o sí? ;)

Molón  ;) (vaya, yo me entretengo en quitarles la cabecera a los archivos y todo)  :D

Pues al final sí que he hecho algo más... Os dejo una mini-demo técnica a la que le falta mucha optimización: mini-demo malévola (http://www.robsy.net/joemove.rom).

Moviendo arriba/abajo el cursor cambiaréis el número. Os adelanto los resultados para MSX1 a 50 Hz:

De uno a tres: funciona a 50 Hz
De cuatro a seis: funciona a 25 Hz
De seis a nueve: 12,5 Hz

En cualquier caso, no funciona demasiado bien a partir de 7/8, debido a que no se ha incluido el NOP adicional para los OUTI fuera de V-blank. Además, el código no está optimizado en absoluto, va todo muy a saco. :P

Muy curioso el invento  ;D

Muy interesante el thread y muy guapa la demo!!... ya sería acojonante unir esta rutina solapando sprites sobre el protagonista (solo 1 por linea) para colorearlo. Hasta tres muñecos, la cosa va super fina (3 personajes 16x32 o 6 personajes 16x16, supongo). Si esto fuera aplicable a 6 "sprites" 16x16, ya solo pensar en las posibles aplicaciones me produce terror y pavor :D :D.

¡Pedazo sprites! y menudo movimiento que tiene (hasta tres o cuatro es aceptable).

Pues para ordenadores a 50 Hz, debería moverse a 50 FPS para 1, 2 y 3 personajes. De 4 a 6 personajes, funcionará a 25 FPS, que era el objetivo original. Si estamos en una máquina a 60 Hz, el límite lo tendremos en unos 5 personajes en movimiento. Eso sí, si lo probáis en un Turbo-R, puede mover hasta 10 personajes a 50 FPS (qué gusto!).

Los sprites, aunque no lo parezca, funcionan como 32x32. El tema de overlay de sprites por hardware es factible y consumiría poco. El problema es que el "gasto" en sprites sería muy elevado para animaciones tan grandes y con tantos frames. Pero bueno, lo que quería demostrar es que el JOE BLADE de MSX podría haber sido idéntico al de ZX. Y eso parece bastante claro. En la versión de Speccy, hay un máximo de 3 personajes en pantalla y funciona a 25 FPS, pero aprovecha también para tener un scroller en la parte superior de la pantalla. En máquinas a 50 Hz sería totalmente factible para MSX.

Wow!!!  :o

Malévolos, con OUTis, NOPs y demases no hay quien se entere de nada ;D

Si eso es lo máximo a conseguir en sprites soft, mejor tiro a la basura los proyectos que tengo ;)

Una preguntilla, Edu, ¿qué porción de la pantalla de juego vuelcas en cada frame? ¿O utilizas la técnica de transferencia secreta y haces trampillas?  ;)

Utilizo 2 buffers: FONDO, TRABAJO y VRAM.

Lo que hago es copiar para cada caja de 32x32 píxeles de FONDO a TRABAJO. En trabajo copio con ANDs la máscara negra y con ORs el cuerpo del sprite. Después vuelco cada rectángulo de 32x32 por separado de TRABAJO a VRAM. Y repetimos. No es difícil, la verdad, pero el tema es que el rendimiento tampoco es fantástico. Ten en cuenta que para cada sprite copias 128 bytes 3 veces (restauración del fondo, máscara, sprite) además de hacer operaciones con ello (ANDs, ORs) y luego vuelcas esos 128 bytes a VRAM.

Asumiendo fondo negro se podría ahorrar mucho. O no utilizando máscara. Se conseguiría doblar aproximadamente el rendimiento. Pero lo pagarías en cuanto al detalle obtenido.

En cualquier caso, me sigue maravillando que pudieran hacerse cosas como un Filmation 2 en MSX. Algún día averiguaré un poco más. De momento, hasta aquí he llegado. Y lo que venga después, habrá que verlo.

Gracias, son ideas que sirven para afrontar nuevas rutinas  ;) A mí lo que me trae por la calle de la amargura (devanándome los sesos) es la rutina de ocultación/redefinición en tiempo real de sprites del Final Lap. Pasmao me quedo. Algo así funcionando a tope daría lugar a juegos isométricos en MSX a todo color :o ¡Animo con eso!   :D

Por mi parte sigo un estilo más tradicional.

Cargo el sprite en un buffer, lo paso a una rutina con parámetros que definen su altura, etc. Luego lo roto a derecha y hacia abajo hasta dar con su posición x,y correcta. Hago AND con su máscara y OR con el fondo (en otro buffer). Y luego todo a la VRAM a saco.

Eso para sprites en plan Spectrum :) Como ves, el proceso es muy mejorable, pero un clásico. Por ahora no uso sprites precalculados porque chuparían mucha memoria.

Para el Filmation (Fistration, en este caso ;)) covierto el mapa de la pantalla donde se desarrolla el juego de fondo (que en realidad está en 2D -gracias, Jon ;)) a coordenadas isométricas, asignando a cada posición un sprite soft. Se ordena esa lista de menor a mayor y se vuelcan todos los sprites en ese orden.

Muchas cosas a mejorar: la rutina de tratamiento de los sprites, la rutina de ordenación, la de volcado a VRAM...

Menuda lástima que la VRAM en los MSX no esté mapeada en la RAM. Se perderían 16kb de memoria, pero... ¡qué juegos saldrían!  :D

¿Quién dice que se perderían 16kb de memoria? Para algo existen los slots y subslots :P

¡Está muy divertido el asunto!, creo que si de lo que se trataba de demostrar es que bien hecho, en el MSX se puede sacar tanta velocidad como en el Spectrum, lo has conseguido ;)


Puedes transigir un poco y utilizar únicamente un XOR, con eso ahorras el guardarte el fondo para recuperarlo y el enmascaramiento del mismo. Queda un poco "rarillo"; pero era muy típico en los juegos de Spectrum ;)

jeje, esa experiencia con el Caverns hace maravillas, ¿verdad?  ;)

Quia, ahí ni me guardaba el fondo, ni hacía XOR, literalmente me lo cargaba al pasar por encima....como era negro (no pretendía hacer un chiste racista :P)

Permiteme corregir tu cita por una más políticamente correcta:

Pues he hecho hoy un poco de optimización para velocidad, y algo sí que ha mejorado el tema, la verdad.

En el original, teníamos que:

Y con la nueva versión, mini-demo v4 malévola (http://www.robsy.net/joemove4.rom), los resultados para MSX1 a 50 Hz:

De uno a cuatro: funciona a 50 FPS
De cuatro a nueve: funciona a 25 FPS
De diez a trece/catorce: funciona a 12,5 FPS

Eso sí, ahora no creo que quede mucho ciclo por rascar :P
He hecho cosas muy malévolas, pero creo que algo he aprendido en cuanto a optimización de velocidad ;)

Pues ir a 50fps ya me parece una pasada  :o

Vamos a ver, ¿qué resulta más lento, volcar el rectángulo correspondiente al área de juego o una rutina para volcar cada sprite directamente?

La respuesta depende de lo que estés haciendo: será más rápida la rutina que trate menos memoria y vuelque menos datos a VRAM. Ten en cuenta que para dibujar cada personaje hay que hacer un porrón de transferencias: leer máscara negra y pintarla en el fondo, leer sprite blanco y pintarlo en el fondo, copiar el recuadro a la VRAM para que se "vea", copiar el fondo al buffer de trabajo para que el sprite no deje rastro al desplazarse. En cada caso se mueven 128 bytes por paso y personaje, así que hazte cargo. Es un GÜEVO de tráfico!

Jeje, hay que ver como te lo estás pasando Robsy ;D, está la mar de bien.
Por curiosidad morbosa, quedamos en que no tenías sprites precalculados, ahora mismo todo son rotaciones, ¿verdad?.

Por eso te lo comentaba, no sé si en este caso es mejor escribirlo todo en un buffer y luego volcarlo.

La diferencia entre hacer el volcado de una vez o en varias veces no es mucha, únicamente hay que volver a preparar para escritura al VDP cada bloque. Tal como dice Robsy lo que realmente es incómodo es enviar muchos datos al VDP, si por hacerlo en una sola operación envías, que te diría yo, un 20% de datos innecesarios ya estás perdiendo tiempo seguro.

Así voy yo ahora, a lo cafre. Que tengo que mandar 3 tercios de pantalla, pues los mando. Que son dos, pues dos  :) Imagina qué carnicería  :D Ya pensaré cómo hacerlo más eficiente más adelante, igual vuelco sólo el rectángulo mayor que contenga cambios o algo así.

Pues después de este ejercicio, creo que el Filmation I es factible a una buena velocidad. Pensemos en los obstáculos como "sprites" fijos que se redibujan en cada frame. Y piensa que no hace falta dibujar de atrás hacia delante TODO. Sólo los obstáculos más cercanos en el sprite en movimiento y el observador. Si me veo con coraje, haré otra mini demo, pero aquí hay que meterle mucha más carga gráfica.  :-\