Karoshi MSX Community

Estoy experimentando en hacer una cosilla a la vieja usanza (léase Spectrum) para lo cual en lugar de trabajar con la tabla de nombres, lo hago con la de patrones directamente. En cada iteración estoy volcando 6kb a la VRAM a saco usando la BIOS y el problema es un apreciable parpadeo (además de que el juego no es muy rápido). He probado a volcar 2 tercios de pantalla (el resto para marcadores) y el problema es el mismo. Sé que es el puñetero barrido el que tiene la culpa, pero en una revista que no recuerdo (era una microhobby) se comentaba que se usaban nops y no sé qué historias para evitar los parpadeos. Quería saber si alguno sabe algo, porque había conversiones spectrum que eran muy suaves, a no ser que usaran otra técnica y no volcasen la pantalla completa. Please, any information is uel uelcomed ;D

Otra cosilla es que necesito tela de ram para trabajar con las pantallas, por lo que si saliera un juego ya no cumpliría los requisitos de la dev, ya que necesito RAM en la página 2 :(

¡Gracias!

Vamos a ver, Darth, no nos pongamos nerviosos... 6KB para generar una pantalla!!!, Dios, pero porqué me das tanto miedo?  ;). No me extraña que veas parpadeos!, es que vas completamente desincronizado!, aparte de ir a 8 fps (que eso no es lo peor). Y además estarás volcando cosas a piñón, sin tener aún la música por interrupciones ni controlar a un personaje ni a sus enemigos y sus colisiones!... 6KB es una bañada... si lo dejamos en los dos primeros bancos (eso sí, solo pasando los patrones, nada de colores -monochrome forever-), ahí tenemos 4KB... irá todo ún poco más rápido (13 fps en PAL aprox.), pero el tema de los barridos es impepinable, ya que el propio refresco de la zona de juego te va a pillar entre el barrido de pantalla SIEMPRE...  ::)

...algún experto en el VDP que le pueda dar alguna esperanza a Darth con su propósito (yo no termino de ver la luz por esa vía)?.  :-\

Es que 6Kb son muchos... :P. Está claro que a 50/60 fps no va a ir nunca. Lo que si que es posible que puedas hacer y seguramente a eso te referías cuando comentas lo de los NOPs, es utilizarlos para hacer que el refresco te pille en una zona en la que no estés volcando pantalla, marcadores por ejemplo. El truco podría funcionar bien si tienes muy controlado lo que te tarda el volcado; si ves que el barrido te pilla siempre en una zona determinada, puedes desplazar la interferencia empezando con unos NOPs (o mejor aun, cualquier otro cálculo útil que te lleve un tiempo más o menos fijo); así con suerte podrás quitarte de enmedio la interferencia. :)
De todas formas, unas ideas:

• Sólo se justifica la transferencia de toda la pantalla, si toda la pantalla se está moviendo, un scroll horizontal o vertical (Operation Wolf o Silent Shadow). De no ser así compensa con creces el volcar únicamente los sprites.
• Si la vuelcas completa y es un scroll horizontal, puedes aprovechar y montarte algún chanchullo parallax y así dividir la pantalla en franjas que se desplazarán a diferentes velocidades. Con eso te ahorrarás el tener que volcar toda la pantalla cada fotograma. Cuanto más lentas sean algunas de las franjas, más tiempo podrás destinar a las otras. ;)

Ok, sí, es una borricada total ;D Pero para lo que estoy probando, no veo otra manera clara de hacerlo. Alguna forma habrá, visto la suavidad de juegos como Freddy Hardest, cualquiera de Ultimate, Venom strikes back y tantos otros. Claro, supongo que sólo transferiran las partes de los muñecos con una rutina y borran lo anterior, supongo (salvo en los de Ultimate).

Los movimientos ya están hechos, Jon, pero no es eso lo que más me preocupa, no ralentiza mucho la cosa ;)

Y si no se puede, pues a jodelse ;D Juegos a la antigua usanza... ¡a soportar "olas" en pantalla! ;D

Vaya, he respondido y no he visto tu mensaje :)


Supongo que a eso se referían en la microhobby.


¿Dónde iría el bucle de nops, después de call LDIRVM? Podría intentar ajustarlo a ojímetro. Podría también volcar cada tercio por separado, después del preceptivo HALT, pero entonces me parece que aunque más suave, la acción estaría "desincronizada", ¿verdad?
 :-[



No exactamente un scroll, pero sí, necesito volcar toda la pantalla, no sólo trozos.



¿Parallax? ¿Eso qué es lo que é? ;D ¡Otra cosa para experimentar! :D Mi socio me va a cortar los cataplines de tanto experimento y no centrarme en hacer lo que queda pendiente :D


Jon, respecto al "monocroming", primero volcaría la tabla de colores y así, al menos, ya hay algo... emborrachamiento de color, como los de toda la vida ;D

No, no os asustéis, algún día lo aplicaré en color. No es imitar al Spectrum lo que busco :)

Tranquilo, tus genitales están a salvo. Eres un brainstroming en potencia... luchar contra eso es absurdo, asi que te dejo hacer, don´t worry  ;)  cmptr:) <Darth  :wallball: < RC

En el MSX es más difícil ajustar con precisión los ciclos del código que se ejecuta que en el spectrum, lo más fácil es hacerlo a ojo. Los NOPs o lo que sea, es más sencillo que vayan inmediatamente despues del HALT, así lo que consigues es desplazar en el tiempo el comienzo del volcado y por tanto la posición de la interferencia en la pantalla. Como esto ya comienza a ser magia negra te recomiendo que le eches un vistazo a este snippet de Sapphire (http://www.msxgamesbox.com/karoshi/index.php?topic=212.0) en el que se comentan unas cosas muy interesantes acerca del HALT y de como darle por saco a la BIOS (mucho ojito que como ya digo, esto es juju).


Me pregunto que se estará cociendo en el lado oscuro de la fuerza... ;D


Imagínate que la pantalla se divide en tres franjas horizontales, cada una de 64 píxeles de alto, la franja inferior contiene un suelo lunar con rocalla y demás (estilo Freddy Hardest) que se desplaza 1 píxel cada fotograma, la franja central contiene unas montañas y detalles lejanos, esta se desplazará a 1 píxel cada dos fotogramas y por último la franja superior que contendra un cielo tachonado de estrellas y algún planeta, su velocidad será de 1 píxel cada tres (o cuatro) fotogramas. De esta forma consigues un bonito efecto de profundidad y además ganas un montón en velocidad ya que rara vez transfieres más de dos franjas en un mismo fotograma (de hecho lo ideal es buscar una relación de velocidades que minimice estas coincidencias).
¡Ah! y por supuesto no uses LDIRVM, hazte una rutinilla que use OUTIs a saco para exprimir al máximo el Z80.


:cindylauper:
Hacía tiempo que no ponía el smiley por aquí...

La ventaja que tenían los spectrum con respecto a los MSX era que la cpu podía acceder directamente a la memoria de vídeo, con lo cual es muy sencillo realizar modificaciones en ésta.

Tiene que ser MUY bestia lo que estás haciendo para tener que volcar 6k de vídeo en cada frame. Además tienes que calcular qué valor debe ir en cada posición, lo cual también consume lo suyo. ¿Seguro que no hay otra forma de hacerlo? ¿Seguro seguro? Quizá combinando un volcado sobre la tabla de nombres y la de patrones conseguirías el mismo efecto con muchísimo menor coste.

Piensatelo :D

Lo de combinar la tabla de nombres y patrones me viene bien pero para otra ocasión, en este caso lo estoy haciendo de otra manera. Sobre si hay otra forma de hacerlo, seguro que la hay, pero bueno, si llegáis a verlo funcionando ya me daréis collejas. Otra cosa que no mencioné es que al trabajar en un buffer, tengo una copia de los 6kbs de la pantalla en RAM y otra copia donde trabajo que es la que se vuelca en pantalla. Vamos, otros 12kbs de RAM también gastados a lo cafre ;D Antes de trabajar con la pantalla, vuelco la copia original a la copia de trabajo con un ldir lo que supongo que también tardará lo suyo (mover los 6kbs). Voy a echar un vistazo a un artículo sobre un ldir rápido publicado por Guyver a ver si saco algo de provecho.

Respecto a volcados rápidos con OUTI, lo único que he visto en el MRC es esta rutina publicada por Robsy (no sé si con copyrights y esas cosas) :)

¡¿Pero en que leshes estás trabajando?! :o


Está perfecta; pero si quieres ejecutarla en los MSX1 necesitarás meter un NOP (o incluso dos) entre cada uno de los 6 primeros OUTI. De no hacerlo así la rutina sólo funcionaría en los MSX2.
Y si tan pillado vas con la velocidad, en vez de hacer 8 OUTIs de un tirón, puedes expandirla un poco y usar 16 o 32 OUTIs seguidos.

Si solo vas a trabajar con formas y los colores van a ser fijos (o en Blanco y negro como si fuera un spectrum) la solución para evitar parpadeo y hacerlo de una forma elegante es usar un "doble buffer" de VRAM  y cambiar la direccion de la tabla de formas en cada frame. El numero de frames por segundo será exactamente el mismo que si vuelcas a VRAM de la forma que explicas porque la transferencia de datos es la misma, solo que en este caso no ves lo que escribes. El problema es que creo que tendrías que desactivar sprites o buscartelos de alguna forma.

La secuencia sería esta:

1-desactivar VRAM y organizarla:(por ejemplo)

 6 kb para buffer 1 de formas en $0000
 6 kb para buffer 2 de formas en $2000
 tabla de color en $3800 

2- Volcado a buffer 1
3- Activar VRAM

4- Activar tabla de formas en $0000
5- Volcado a buffer 2
6- Activar tabla de formas en $2000
7- Volcado a buffer 1
8- ir a 4

Espero que te sirva.  cmptr:)

y..

Lo evitas de esta forma.

PS: sobre el codigo que has pegado ahi arriba.... que recuerdos ;D

La idea es buena; pero creo que no hay VRAM suficiente... :(

Formas 1 : 6144
Formas 2 : 6144
Colores   : 6144
Nombres : 768

Total : 19200

Y eso sin contar con que en screen 2, cada una de las tablas de formas y de colores sólo pueden estar en $0000 o en $2000, por lo que no se podría tampoco definir ninguna tabla de patrones extra :'(. Me temo que en este caso la superioridad del VDP de los MSX2 es realmente humillante (y frustrante).

Respecto a los sprites, en un MSX2 los podrías desactivar del todo, en un MSX1 la única solución es meter 208 en la ordenada del sprite 0 y quitarlos de enmedio, de esta forma en la tabla de patrones de sprites puede haber toda la basura que se quiera, que no se verá nada; pero claro, de poco sirve.....

Por cierto, ¿pasará como con los MSX2?, que cuando no hay sprites el VDP va un pelín más rápido, o sea, ¿si el VDP no tiene sprites que dibujar en pantalla se ganará algo de velocidad en el acceso al VDP?......supongo que no, después de todo el VDP de los MSX1 no tiene la capacidad de procesar instrucciones como el 9938 o 9958.

Segun lo que comenta Darth no es necesaria una tabla de colores de 6kb. Quien ha dicho SC2?  ;)

 ;D Conociendo a Darth seguro que está metiéndose a fondo con SC2. Además si que creo que comentó algo de que iba a hacer nosequé con la tabla de colores... ;)

Yap, pero en screen 1 tan solo dispones de 256 caracteres para definir (un tercio de la pantalla)... ¿o estás hablando de alguna especie de modo mixto que acepte 768 caracteres sin tabla de color?. ???

Jon, teoricamente hay dos maneras de hacer un modo bitmap con una tabla de colores (o sin ella) reducida.

- Una modo mixto SC1 con $40 bytes de tabla de color (creo recordar, porque la use en alguna prueba extraña y funcionó. Ademas pregunté por ello en MRC para cambiar muy rapidamente el color del bitmap a pantalla completa muy rapidamente)

- Un modo Bitmap en modo texto, con lo que seguro que tienes dos bancos de formas en $0000 y $2000 y te olvidas de la tabal de color porque en este modo (seria algo asi como un screen 0) el color se toma directamente del registro 7. No lo he probado nunca, pero es posible que solo se vean los 6 bits mas altos de cada byte en pantalla por cada tile, ya que tenemos 40 caracteres por linea o no se si seria visible una resolucion de 320 pixeles de ancho.(?) a ver si alguien se atreve!  ;D

Os agradezco de veras vuestra ayuda, aquí nunca se espera menos, mil gracias de nuevo :)

Me estoy liando un poco con tanto cambio de "páginas" si se le puede llamar así, así que permitidme replantear la pregunta:

¿Cómo hacen esas conversiones de Spectrum para que, habiendo acción por toda la pantalla, o 2 tercios como era habitual, vaya la cosa medio fina? Podría pintar sólo los sprites, pero hay varios y grandes y situados por planos y me parece que volcarlos directamente a VRAM me tardaría un egg de pato :) Por eso por ahora los vuelco a un buffer y de ahí a la VRAM a saco.

 :)

¡Menudo engendro :)!, ¿cuantos carácteres entran en un byte de color?, con 64 bytes disponibles, ¿son cada 4 en lugar de cada 8?


De ese me suena haber leido algo; pero creo recordar que decían que luego no podías acceder a la VRAM y te quedabas sin poder hacer nada... :(
¿No se fastidiará el VDP con tanto experimento, verdad? >:D


Pues eso, que no podemos comparar. El spectrum utilizaba doble buffer para pantalla completa y accesos directos cuando no había demasiadas cosas que mover. La ventaja era que no había VRAM; ya sabes, accedías a la pantalla (si no recuerdo mal) mediante el rango de direcciones 16384-17152 de la RAM. Si querías hacer un scroll suave pues le hacías una rotación directamente a los bytes en esas posiciones, si querías transferir bloques a toda leche, pues un mogollón de LDI y arreglado.

El sistema que estás utilizando ahora creo que es el único viable. Para optimizar un poco el asunto y sin pasarte de complejidad lo que puedes hacer es, una vez volcados al buffer, calcular el rectángulo (o rectángulos a gusto del consumidor) más pequeño que los engloba a todos y volcar únicamente ese fragmento a la VRAM. Como poco seguro que te ahorras 1/3 del total.

¿No estarás preparando un "After the Darth"?. ¿O un "Fistro Moves?. :D

Jejejeje, nada de eso, Jon  ;)

De todas formas entonces parece que las conversiones o bien hacían un volcado a lo bruto o bien sólo volcaban los sprites a la pantalla directamente, que la verdad, no sé si la diferencia entre ambos métodos es mucha sobre todo si los sprites son grandes  ???

Bueno, intentaré lo de los nops y si no, pues a fastidiarse con "olas"  :D