Soñando despierto

[radastan]

Algunas pruebas rápidas para ver posibilidades de cara al futuro. Ojo, PRUEBAS, nada de esto es real, son simples conversiones a resolución y paleta de colores del QL:



La verdad es que gráficamente no hay problemas para hacer cosas la mar de curiosas.

[mcleod_ideafix]

Ahora hay que mover esos gráficos: el 68008 va a 7.5MHz, sí, pero hay que ver cúanto se come la contención (que en el QL, al haber sólamente un banco, afectará a toda la memoria).

Necesito un poquiiiiito de tiempo para hacer mis pruebas, a ver a qué llego...

Sea como fuere, hay que ver lo que da de sí el mero hecho de poder tener un color distinto en cada pixel, aunque la paleta sea fija e incluso un poco más pobre que la del Spectrum. Por otra parte, un recordatorio: el QL no tiene borde, por lo que a causa del overscan, muchos píxeles cercanos a los bordes no se verán en un QL real con un monitor estándar. Quiero decir, que tienes 256x256, pero que ves aproximadamente, 224x224 (puede que incluso menos).

[radastan]

Tendré en cuenta la limitación del borde Mc Leod, probaré en mi televisor CRT de 14" a ver como se ve.

Y si, son simples conversiones que evidentemente luego hay que mover, pero siendo realistas es que hasta juegos sencillos como los que salen en Spectrum últimamente quedarían la mar de majos...

[na_th_an]

Je, je, qué chulo te ha quedado

[RWAP]

The full screen resolution on the original QL is:

8 colours in 256x256 pixels
4 colours in 512x256 pixels

However, on a standard TV screen, this is reduced to :

8 colours in 200x242 pixels
4 colours in 400x242 pixels

The top left corner in TV mode is 32,16.

There are some interesting tricks to getting more out of the screen.
There is a dithvide method - http://omega.webnode.com/products/product-2/
There is also a program in the Quanta user library http://www.quanta.org.uk/?id=88 which enables the screen to be split between mode 4 and mode 8 (horizontally) - SPLITMODE_ASM. Without getting into any discussion, the Quanta library is only available to its members (and that was expressed by many authors when submitting their software).

Remember that you can use the QL's second screen (at $28000) if you disable interrupts - you lose the system variables however (unless you have Minerva in which case it was written to work with dual screens)

Other things to consider (especially when writing for TV mode) is that instead of using commands such as
move.l (a0)+,(a1)+
dbf d0,loop

You can use the quicker versions of movem.l commands to copy several long words from the screen at a time and use enough repeats of these commands to cover one row of the screen.

The other thing to look at is the little used MOVEP command which is ideal for using mode 8 screens

[radastan]

Tras analizar varios juegos veo que no hay uniformidad en el uso de pantalla, aunque 224x224 centrado parece que sería lo más adecuado para el modo 8 (es decir, dejar un borde de 16 pixels de ancho uniforme).

Para el modo 4 sería el doble en horizontal, 448x224, con un borde de 32 pixels a los lados y 16 pixels arriba.

Eso es si seguismo usando un televisor normal, habría que ver que pasa si conectamos un QL a un televisor LCD o a un monitor CRT. Casi todos los usuarios de QL acaban con un monitor para poder aprovechar el modo 4, por lo que para ellos no hay problema de borde.

De todas formas los primeros juegos los voy a centrar en modo 8 y 224x224.

Un par de pruebecillas con estas limitaciones:



La de Phineas y Ferb la había previsto originalmente a full screen, es una simple prueba para ver como quedan las tramas:



A ver si puedo sacar un hueco para probarlos en un QL real y ver como quedan en un televisor. Ya de paso me hago un conversor de imágenes al formato de QL, que me va a hacer falta.

Una cosita más, si los sprites se quieren ver con la relación de aspecto correcta, un cuadrado en el modo 8 es aproximadamente de 10x8 pixels o de 20x16 pixels (pensando para los sprites). También se puede usar 16x16 pero dejando vacías las columnas de pixels de los lados (que es lo que hago en Groggor).

[mcleod_ideafix]

Other things to consider (especially when writing for TV mode) is that instead of using commands such as
move.l (a0)+,(a1)+
dbf d0,loop

You can use the quicker versions of movem.l commands to copy several long words from the screen at a time and use enough repeats of these commands to cover one row of the screen.

The other thing to look at is the little used MOVEP command which is ideal for using mode 8 screens

You mean that these instructions are more suitable for TV than Monitor mode? What's the difference? Are QL timmings different when working in Monitor vs TV mode?

[radastan]

Ya he probado un QL real y la verdad es que peca de conservador.

El modo TV no ocupa toda la pantalla, sobra un poco, y este modo trabaja a 224x224. Es decir, se podrían llegar a emplear un área de pantalla de 240x240 sin que perdiéramos mucho (a lo sumo un pixel o dos). Puede parecer una chorrada, pero en algunos juegos puede llegar a ser necesario exprimir un poco.

Lo he probado tanto en un televisor por RGB (que por cierto se ve sobresaturado de brillo) y en un televisor LCD por RF.

[RWAP]

You mean that these instructions are more suitable for TV than Monitor mode? What's the difference? Are QL timmings different when working in Monitor vs TV mode?

MOVEP is more suitable for mode 8 (as it takes a word and extends it into a long word, by zeroing every other bit).

MOVEM.l is what is used by tools such as Lightning to squeeze the timings for handling the QL display as much as possible - the movem.l commands are useful for speeding both mode 4 and mode 8 displays - I used it extensively to get the high speed scrolling routines for D-Day MKII

Just one more thought - can you please ensure that you do not just assume the screen dimensions! If you want the game to run on more recent QL hardware and emulators such as QPC2, then you need to store the start address of the screen (from the system variables), the bytes per line (normally 128 but can be more on high resolution displays) and the maximum screen resolution - have a look at the display_cde toolkit for information - http://www.dilwyn.me.uk/tk/display2.zip

[jzx]

You mean that these instructions are more suitable for TV than Monitor mode? What's the difference? Are QL timmings different when working in Monitor vs TV mode?

No creo que diferencie, porque no conozco el ql, pero supongo que lo que pasa es que los televisores tienen mucho overscan, el barrido del tubo es bastante más grande que la pantalla y se pierde bastante imagen por los bordes. Esto es una de esas cosas que como "son estandar" se conservan por los siglos de los siglos. Cuando empezó la tv era muy dificil que el barrido fuera correcto por los bordes, había distorsiones y cosas raras, mucha tolerancia de los componentes, poca estabilidad etc, por lo que lo más fácil era aumentar el tamaño de la imagen hasta que los defectos se salieran por el borde ... Y los televisores de hoy siguen manteniendo eso "por compatibilidad". Si miras un tv y la misma imagen en un ordenador, con una capturadora verás que en el tv se pierde bastante, aunque sea un tv moderno que no debería tener problemas. (a no ser que lo conectes a un video de cinta, que siempre sacan una zona defectuosa por la parte de abajo).
Los monitores se supone que eran de mejor calidad y por eso podían aprovechar más la pantalla.

Como curiosidad, aunque no tiene mucho que ver, la CGA de los pcs estaba pensada para usarse con un televisor y con el comando MODE de msdos se podía centrar la pantalla, porque normalmente se salía por izquierda o derecha a pesar de que también tenía borde, pero más pequeño que el spectrum. Y sis se salía por la izquierda te quedabas sin el A:>

[afx]

Radastan, todo esto tiene ¡muy buena pinta!

Ánimo con esos proyectos.

Saludos.

[nitrofurano]

just a question: on a crt tv, does 256x256 takes this resolution from 270x288 ( 270=720/8*3 ), just like NES takes 256x240 from there, or Colecovision/MasterSystem takes 256x192 from there?

[nitrofurano]

Algunas pruebas rápidas para ver posibilidades de cara al futuro. Ojo, PRUEBAS, nada de esto es real, son simples conversiones a resolución y paleta de colores del QL:
(...)
La verdad es que gráficamente no hay problemas para hacer cosas la mar de curiosas.

@radastan, you didn't ask for that, but anyway, here is the Lua script for GrafX2 providing similar results on what i posted as comment at that blog post at bytemaniacos.com (the earlier one i used were on sdlBasic)

http://pastebin.com/44uFaKUs

(well, i'm assuming you're comfortable with GrafX2, and how to run Lua scripts from there...)

here is some result of this script:

[radastan]

This script is amazing, great job. I take note to implement it on a image converter program focused on QL.

Thanks.

[na_th_an]

Tritone dithering always works great