"The Great Escape" ¿iba así de rápido en spectrum?

[Randomize]

Es que no salgo de mi asombro. Yo tenía un CPC y recuerdo que se movia tan lento como lo hace en cualquier emulador de CPC. Pero me pongo un emulador de spectrum (Spectaculator) y... ¡joroba! da gusto a que velocidad se mueve. Si, por supuesto el emulador está en Speed/Normal.


S2.

[Neville]

Por norma los juegos que tienen versiones Spectrum y Amstrad se suelen mover algo mejor en Spectrum.

[DaDMaN]

Esto ocurria más concretamente en las conversiones directas SPECTRUM - AMSTRAD, como es el caso.

Yo también jugué muchísimo a este juego en CPC y realmente al caminar se ve como se "redibuja" la pantalla entera.

Seguramente si se hubiesen entretenido en emplear las carácteristicas de CPC en lugar de "simular" la pantalla de Spectrum, el resultado en cuanto a velocidad hubiese sido satisfactorio.

Salu2.

[Davae]

Los usuarios de C64 también estamos acostumbrados a que algunas conversiones de Spectrum eran especialmente lentas debido a que no sacaban provecho del hardware del Commodore. Especialmente recuerdo la conversión del Fairlight, que era insubriblemente lenta, sobretodo a la que aparecía un enemigo en la pantalla.

[na_th_an]

De todos modos es que el Fairlight es un juego isométrico y por mucho sprite hardware que haya poco se puede hacer al respecto. Estos juegos siempre irán mejor en máquinas con más potencia de procesador, ya que toda la escena hay que pintarla por software. Lo mismo ocurre con juegos vectoriales o que empleen técnicas como freescape.

[Metalbrain]

Hay que tener en cuenta otro detalle. En Amstrad una pantalla ocupa casi 16Kb, mientras que en Spectrum ocupa 6,75Kb, así que aunque la potencia del procesador sea parecida (el Amstrad va a 4MHz, pero como toda la memoria está en contienda, no se aprovecha toda la velocidad), siempre va a tardar más tiempo en actualizar los gráficos. Eso sí, si se usa una pantalla secundaria, por hardware se puede cambiar de una a otra sin perder tiempo, mientras que Spectrum hay que hacer la copia de datos que tarda bastante (a menos que lo hagamos solo para 128k, en cuyo caso también podemos usar un cambio rápido). Y por hardware en Amstrad también se pueden hacer ciertos tipos de scroll de forma rápida. Hasta donde yo se, el Amstrad tampoco tenía sprites.

Así pues, dependiendo del tipo de juego y de si se puede usar o no la pantalla secundaria (que ocuparía otros 16K), la versión de Amstrad puede ser o irremediablemente más lenta o parecida en velocidad o incluso más rápida.

Ya si se convierte o no directamente de Spectrum intentando simular su pantalla, pues no se cuanto puede llegar a influir, pero desde luego no parece que vaya precisamente a ayudar.

[DaDMaN]

En Amstrad una pantalla ocupa casi 16Kb

Eso no es del todo correcto... Puede ocupar, desde 0Kbytes hasta 32Kbytes (25920 bytes realmente, pero se dice que son 32Kbytes porque necesita 2 bloques de 16kbytes del primer banco de RAM) Más concretamente (hablando de ports de spectrum), la memoria de video del cpc es directamente proporcional a los parámetros de ancho y alto de pantalla con los que configuremos el crtc, que en este último caso era en Mode 1 - 4 colores -256x192 (la misma resolución que en speccy).

En el Amstrad CPC, tenemos 3 modos de pantalla "predefinidos" en el BASIC (al arrancar la máquina).

Mode 0 : 160x200 píxeles 16 colores
Mode 1 : 320x200 píxeles 4 colores
Mode 2 : 640x200 píxeles 2 colores

Los 3 modos de pantalla ocupan exactamente lo mismo, 16Kbytes (bueno, realmente 16000 bytes exactos). ¿Cómo es posible? El hardware de video del CPC determina que:

En Mode 0, 1 byte en la memoria de video representa 2 pixeles (160x200 = 32000 pixeles / 2 = 16000 bytes)
En Mode 1, 1 byte en la memoria de video representa 4 pixeles (320x200 = 64000 pixeles / 4 = 16000 bytes)
En Mode 2, 1 byte en la memoria de video representa 8 píxeles (640x200 = 128000 pixeles / 8 = 16000 bytes)

El CRTC del CPC permite ser configurado para cualquier resolución comprendida entre 0x0 píxeles y "384x270 (Mode 1), 768x270 (Mode 2), 192x270 (Mode 0)", empleando la cantidad de RAM necesaria para la configuración elegida.

En el caso de los Ports de Spectrum, se configuraba el CRTC a 256x192 en Mode 1.
Calculando: 256x192 = 49152 píxeles. Como 1 byte en la memoria de video representa 4 pixeles, tenemos que 49152 / 4 = 12288 bytes.

Ese es realmente el tamaño de pantalla ocupado en los ports directos speccy / amstrad. Realmente, es el doble que la pantalla de spectrum (en tamaño), pero 4 kbytes menos que los 16Kbytes preestablecidos por el BASIC.

Una resolución de pantalla en Mode 1(pixel cuadrado - 4c colores) en Amstrad CPC que ocuparía exactamente 6912 bytes (como la pantalla del spectrum) sería de 192x144 píxeles (24x18 caracteres).
Calculemos: 192x144 = 27648 pixeles / 4 (pixeles por byte en mode 1) = 6912 bytes.

El tema de la "memoria contenida" (o en contienda, o como narices se diga), el CPC también difiere del Speccy y si no estoy equivocado, carece de ella. El CPC emplea como memoria de video la RAM (comparte) del sistema, permitiendo alojar el inicio de la memoria de video en el inicio de cualquier bloque de 16kbytes del primer banco de 64Kbytes (&0000,&4000,&8000 e &c000) a gusto del consumidor. Esto permite, entre otras cosas, tener 2 pantallas que se van alternando en distintos bloques de memoria e ir cambiando el puntero de la memoria de video de una a otra (nos ahorramos el volcar el buffer a la pantalla).

Resumiendo: El The Great Escape, PODRIA haber corrido bastante más, sin ninguna duda.

Salu2!

[na_th_an]

Sobre lo de la memoria en contienda (contended ), es precísamente la capacidad de que el CTRC pueda usar cualquier banco de memoria lo que hace que toda la memoria esté, en potencia, en contienda. Sea como fuere, si el CTRC está accediendo al banco X para pintar la imagen, éste banco pasará a estar automáticamente en contienda. Cualquier acceso del Z80 a ese banco se verá parado siempre que el CTRC quiera acceder a él. ¿Qué ocurre? Que aunque usemos sólo 12K para la pantalla, los 4K restantes o bien no se usan o bien su acceso es más lento (es lo mismo que ocurre con los casi 9Kb restantes del primer banco de RAM del Spectrum. No son VRAM, pero al estar en el mismo banco que ésta, se ven igualmente afectados).

¿Qué ocurre? Que al ser un port directo, todo el rendering se hace por software. De entrada hay que mover casi el doble de los datos, y precísamente a la zona de memoria en contienda. Y si el origen de alguno de estos datos (que no lo sé), está además en esos 4Kb restantes de ese banco... Entonces apaga y vámonos.

Claro que podría haber dado mucho más de si: sólo con haber reprogramado todo el rasterizador podrían haberse ganado ciclos. Estoy seguro de que, además, se emula el modo gráfico de Spectrum hasta el más mínimo detalle. En un juego de estas características, además, los gráficos están prerrotados. Si estamos emulando el Spectrum, esas prerrotaciones no funcionan del todo bien en un CPC, y estoy seguro que incluso la conversión se hace al vuelo para ahorrar memoria.

Vamos, que estoy totalmente de acuerdo contigo: podrían haberlo hecho mucho mejor con algo de esfuerzo. Hemos visto juegos isométricos (y hasta filmation, que implican aún más cálculo tanto por detrás como para el display) en CPC que corren muchísimo más.

[Metalbrain]

Coño DaD, muchísimas gracias por la información.

El CRTC del CPC permite ser configurado para cualquier resolución comprendida entre 0x0 píxeles y "384x270 (Mode 1), 768x270 (Mode 2), 192x270 (Mode 0)", empleando la cantidad de RAM necesaria para la configuración elegida.

¿Entonces si lo pones a una resolución ridículamente baja (por ejemplo, 320x2 en modo 1), obtienes líneas como si fueran de 100 píxeles de altura? Eso vendría de coña para hacer efectos de Zoom Out y Zoom In.

El tema de la "memoria contenida" (o en contienda, o como narices se diga), el CPC también difiere del Speccy y si no estoy equivocado, carece de ella. El CPC emplea como memoria de video la RAM (comparte) del sistema, permitiendo alojar el inicio de la memoria de video en el inicio de cualquier bloque de 16kbytes del primer banco de 64Kbytes (&0000,&4000,&8000 e &c000) a gusto del consumidor. Esto permite, entre otras cosas, tener 2 pantallas que se van alternando en distintos bloques de memoria e ir cambiando el puntero de la memoria de video de una a otra (nos ahorramos el volcar el buffer a la pantalla).

Sobre lo de la memoria en contienda (contended ), es precísamente la capacidad de que el CTRC pueda usar cualquier banco de memoria lo que hace que toda la memoria esté, en potencia, en contienda. Sea como fuere, si el CTRC está accediendo al banco X para pintar la imagen, éste banco pasará a estar automáticamente en contienda. Cualquier acceso del Z80 a ese banco se verá parado siempre que el CTRC quiera acceder a él. ¿Qué ocurre? Que aunque usemos sólo 12K para la pantalla, los 4K restantes o bien no se usan o bien su acceso es más lento (es lo mismo que ocurre con los casi 9Kb restantes del primer banco de RAM del Spectrum. No son VRAM, pero al estar en el mismo banco que ésta, se ven igualmente afectados).

Según yo lo entendí de la página esta,
http://www.kjthacker.f2s.com/docs/instrtim.html

el diseño del Amstrad es tal que se accede a la memoria de video de manera sincronizada en determinados momentos fijos, independientemente de que banco de memoria esté siendo utilizado, con lo cual las temporizaciones son uniformes (y más lentas que en un Z80 normal), y la velocidad de 4MHz del Amstrad queda reducida a una velocidad efectiva aproximada de 3.3MHz. Osea, que aunque usemos 12K para la pantalla, no son los 4K restantes del banco los que van más lentos, los 64Ks van todos igual de lentos.

[DaDMaN]

Efectivamente, toda la RAM del CPC funciona a la misma velocidad, independientemente de si se usa para video o no. La velocidad resultante del Z80 efectivamente es inferior a los 4Mhz por eso mismo que comentas, Metalbrain.

El tema de definir el ancho y alto de la pantalla, tiene una pequeña limitación. No se define por pixeles, sino por caracteres de 8x8. 320x2 pixeles no es valido, pero si lo es 320x8 (40x1 caracteres). La definicion de alto y ancho se envia en caracteres.

El CRTC también permite desplazar (scrollear) la pantalla en cualquier dirección con 2 simples "OUTS" desde el propio BASIC. Tiene también otros modos de funcionamiento, como el modo "interlaced" (lo pongo en ingles, asi seguro que no me equivoco, xD), que duplica la pantalla en 2 secciones, una con las lineas pares y otra con las impares.

La verdad es que la versatibilidad del CRTC es impresionante.

@Nath: Gracias por la explicación Era una de las cosas que dudaba al respecto

Salu2!

[Randomize]

Joer!, que interesante. Mi voto para un "The Great Escape v2.0"

S2.

[Metalbrain]

El tema de definir el ancho y alto de la pantalla, tiene una pequeña limitación. No se define por pixeles, sino por caracteres de 8x8. 320x2 pixeles no es valido, pero si lo es 320x8 (40x1 caracteres). La definicion de alto y ancho se envia en caracteres.

Aún con resolución de caracteres, puede seguir siendo útil para hacer efectos. Y estoy pensando en algunas máquinas recreativas de tipo Street Fighter que cuando los luchadores se alejaban se hacía un zoom out y cuando se acercaban se hacía un zoom in, pero claro está a la misma resolución y escalando los sprites. En Amstrad se podría hacer que se vieran los mismos gráficos, pero con pixeles más grandes si están más juntos. Sería una pesadilla para programar, pero podría molar. ¿Existe algo así que ya esté hecho?

[EightBiter]

No le déis más vueltas: si en Spectrum se movía más rápido, era porque tenía más prisa

[Kendroock]

No le déis más vueltas: si en Spectrum se movía más rápido, era porque tenía más prisa

Sabias palabras...

[AugustoRuiz]

El tema de definir el ancho y alto de la pantalla, tiene una pequeña limitación. No se define por pixeles, sino por caracteres de 8x8. 320x2 pixeles no es valido, pero si lo es 320x8 (40x1 caracteres). La definicion de alto y ancho se envia en caracteres.

Aún con resolución de caracteres, puede seguir siendo útil para hacer efectos. Y estoy pensando en algunas máquinas recreativas de tipo Street Fighter que cuando los luchadores se alejaban se hacía un zoom out y cuando se acercaban se hacía un zoom in, pero claro está a la misma resolución y escalando los sprites. En Amstrad se podría hacer que se vieran los mismos gráficos, pero con pixeles más grandes si están más juntos. Sería una pesadilla para programar, pero podría molar. ¿Existe algo así que ya esté hecho?

A ver.. El hecho de que pintes sólo un caracter en la pantalla no afecta al tamaño del mismo en el CPC. Simplemente es que de todo el recorrido del cañón, sólo va a pintar una línea...

Eso te puede valer para preparar un scroll por hard, pero no un zoom, ya que el tamaño de los pixels es siempre el mismo en función del modo en el que trabajes (0,1 o 2). La cosa es que si defines que la pantalla sea de 160x100 en vez de 320x200, no se van a ver los pixels el doble de gordos... :S