Proposición de gráfica externa para ZX Spectrum

[radastan]

Pues dime entonces que debo hacer para activar la ULAPlus y este modo de vídeo. Por lo que me comentas los pixels están intercambiados en cada byte, ¿no? quiero decir que el primero es el segundo y así sucesivamente. No pasa nada porque yo moveré todo byte a byte (no estoy con tiempo como para currarme esto en condiciones). Quiere decir que horizontalmente los sprites se moverán de dos en dos pixels (cada 4 pixels del ZX Spectrum original). No está mal.

Edición especial de Misco Jones en marcha... "Misco Jones en el Templo Mojino".

[Zardoz]

El modo "radastaniano" tiene las siguientes características:
- Resolución de 128x96 píxeles cuadrados, aspect ratio de la pantalla: 4:3
- Dentro de cada byte, los bits 4 a 7 contienen el color del pixel más a la izquierda, y 0 a 3, el color del pixel de más a la derecha
- Los colores se toman de las 16 primeras entradas (0 a 15) de la paleta de ULAplus

Pues puede que "exporte" el modo "radastaniano" a la computadora de Trillek, ahora que veo que queda bastante bien y tiene un layout en la memoria bastante sencillo. PD: Ahora mismo se esta planteando seriamente poder usar también un Z80 como cpu...

[mcleod_ideafix]

Pues dime entonces que debo hacer para activar la ULAPlus y este modo de vídeo.

ULAplus usa dos puertos: el 48955 y el 65339 (en decimal, en hexadecimal son $BF3B y $FF3B). Para activar ULAplus + modo radastaniano haces:

Código: Seleccionar todo

OUT 48955,64: OUT 65339,3

Para volver al modo estándar,

Código: Seleccionar todo

OUT 48955,64: OUT 65339,0

Para establecer los colores en la paleta, mírate la documentación de la ULAplus. Pero vamos, es coger y hacer:

Código: Seleccionar todo

OUT 48955,indice: OUT 65339,color

Donde "indice" es un valor de 0 a 63 (0 a 15 para el modo radastaniano ya que el resto de entradas no se usan) y color es un color codificado en formato GGGRRRBB

El color del borde se toma de los 8 primeros índices, del 0 al 7, según el valor que pongas en el puerto de siempre, el $FE.

Por lo que me comentas los pixels están intercambiados en cada byte, ¿no? quiero decir que el primero es el segundo y así sucesivamente.

El primer pixel está en las posiciones 7 a 4 del primer byte, y el segundo pixel en las posiciones 3 a 0 de ese mismo primer byte. Es el orden lógico, ¿no? En el modo original, el primer pixel no está en el bit 0 del primer byte, sino en el bit 7 del primer byte, el segundo en el bit 6 y así sucesivamente.

[radastan]

Por lo que me comentas los pixels están intercambiados en cada byte, ¿no? quiero decir que el primero es el segundo y así sucesivamente.

El primer pixel está en las posiciones 7 a 4 del primer byte, y el segundo pixel en las posiciones 3 a 0 de ese mismo primer byte. Es el orden lógico, ¿no? En el modo original, el primer pixel no está en el bit 0 del primer byte, sino en el bit 7 del primer byte, el segundo en el bit 6 y así sucesivamente.

Efectivamente, pero es debido a que generalmente el bit de menor peso siempre se pone a la derecha en un byte a la hora de representarlo.

Pero vamos, que no lo cambies porque no va a suponer ningún cambio para mi ponerlo en un lado u otro, yo voy a trabajar con bytes y me da lo mismo. Lo único es que quede claro para no volverme loco al hacer conversiones de PC a ZX Uno.

Para empezar voy a adaptar una rutina sencilla de tiles de 8x8 pixels (equivalente a la de 16x16 del ZX Spectrum) y otra de sprites de 8x12 (creo que es el tamaño adecuado).

[mcleod_ideafix]

Lo único es que quede claro para no volverme loco al hacer conversiones de PC a ZX Uno.

Fíjate que de esta forma, los BMP que se guardan con 4bpp coinciden en formato con como se representan en el ZX-Uno (salvando el pequeño detalle de que los BMP se guardan desde la última línea a la primera), así que si guardas tus sprite sheets como BMP's con paleta de 16 colores, son directablemente usables en el ZX-Uno.

[antoniovillena]

Es posible hacer una conversión de FASE para este modo gráfico. Eso sí, tendrías que currarte la parte no gráfica del código (colisiones, inercia, gravedad, movimiento de enemigos, etc...). Los tiles y sprites serían de 4x4 y la velocidad sería la misma, es decir, 50fps y 8 sprites simultáneos con bus flotante, o sin límite de sprites simultáneos con video shadow.

-- Actualizado 03 Mar 2014, 21:29 --

Es más, podría usar coordenadas ficticias de 256x192 y de esta forma sacar el mismo juego para ambas plataformas tan sólo haciendo tiles y sprites alternativos.

[radastan]

Es que esa es la idea, que el modo de vídeo sea fácilmente aprovechable desde Z88DK y similares, reaprovechando todo el código sin problemas.

Pero vamos, que si me parpadean un poco los sprites no pasa nada, es una prueba para ver como queda un juego en este modo.

[antoniovillena]

Precisamente la parte no aprovechable del código de FASE es la que está escrita.

[ZX-81]

Cuidado con los valores de activación del ULA+ porque, aunque no conozco implementación alguna que lo cumpla, ya está asignado el valor 3 como comando de selección:

https://github.com/cheveron/sebasic4/wiki/ULAplus-Support

Ando intentando encontrar la especificación de algo así como la ULA++ que permite el uso de 80 columnas de texto con el Basic de Andrew Owen porque me va por la cabeza que algo afecta a lo que estáis pensando.

Por otro lado, una irregularidad del ULA+ es que, aunque no está en puertos susceptibles de entrar en contienda con la ULA estándar, tienen la misma contención que el puerto $FE. La otra cuestión que encuentro peliaguda, si me permitís la observación, es el cambio de la organización de pantalla, que pasa del modo "tradicional" al modo lineal. Se supone que ULA+ tiene la ventaja de que se pueden recolorear los juegos ya existentes simplemente cambiando la paleta de colores y activando el modo correspondiente. Pero el modo radastaniano obliga a escribir el código de forma específica para él, sin posibilidad de compatibilidad inmediata (y sencilla) con el modo tradicional.

[mcleod_ideafix]

Por partes:

- El bit 1 efectivamente está asignado para un supuesto modo HLS, que no está implementado en ninguno de los clones que actualmente soportan ULAplus que yo sepa. Dado que esto es un experimento restringido al prototipo de ZXUno y a un solo juego, y que no hay soft que use este modo HLS, las probabilidades de colisión con el software existente son 0.

- No es en absoluto irregular que los puertos de ULAplus tengan la misma contienda que el puerto $FE. De hecho, si no fuera así, no podría implementarse en una ULA física (para Spectrum 48K).

- El modo de 80 columnas de texto viene de usar el modo de resolucion de 512x192 pixels, que existe en el Timex desde mucho antes de hablarse decla ULAplus. Para activar ese modo, OUT 255,6 en un clon que soporte estos modos.

- La ULAplus es una cosa y el modo radastaniano, otra distinta. El hecho de que compartan puerto de E/S es por una simple cuestión de comodidad (los puertos propios de ZXUno aun no estaban implementados), y porque he aprovechado parte del flujo de datos de ULAplus para implementar este modo (ver esquema publicado un poco antes en este hilo). Así, el que sea un modo completamente aparte de los demás, con su layout propio, no afecta a la ULAplus, porque de hecho, no forma parte de su especificación. Terminado el experimento, y si el modo radastaniano puede quedarse en el core final, no tengo problema en mover su esquema de activación a uno de los registros del ZXUno y aquí no ha pasado nada . Como ves, el modo radastaniano no es más que otro modo añadido, como lo son también los modos HiRes y HiColour que están presentes en el core de ZXUno y que no tienen nada que ver con ULAplus (aunque puedan usar sus... "servicios"). Es más, Andrew Owen ya me habló hace tiempo de ofrecer una activación alternativa de los modos Timex usando también los registros de la ULAplus.