Seis colores por carácter. ¡ CONSEGUIDO !

[mcleod_ideafix]

Moooooooola!!!! Gracias por el aporte

[marce]

Moooooooola!!!! Gracias por el aporte

A ti, que no habría sido posible sin tu rutina

[Rinconete]

Impresionante, no parece un Spectrum

[mcleod_ideafix]

Aquí tenéis un cutre-dibujo que he realizado usando Colorator (http://colorator.sourceforge.net):


Y el fichero TZX:
http://mesxes.es/colorator/demo-colorator.tzx
//.arce

Escribo este post para reflotar este hilo. El autor de Colorator ha hecho su última actualización en Febrero de este año, es decir, que no ha dejado el proyecto y ha seguido haciendo cosillas. Humildemente creo que merece la pena echarle un ojo al editor para hacer alguna cosilla chula en color de alta resolución, cosa que daría a un juego una nueva "visión" (aunque sólo fuera para una pantalla de presentación, un menú de juego, la pantalla de records, cosas así...).

Os recuerdo que tenéis el Colorator y el código fuente de la rutina de alta resolución en color para que los que estáis haciendo nuevos juegos la uséis si tenéis ocasión y os merece la pena (y para mejorarla, que tiene para mejorar).

Hala! Pues eso!

[na_th_an]

Si pudiésemos emplear esto en conjunción con un compresor como exomizer o aapack sería ideal, si no, ocupa demasiado para usarlo en un juego.

[mcleod_ideafix]

Si pudiésemos emplear esto en conjunción con un compresor como exomizer o aapack sería ideal, si no, ocupa demasiado para usarlo en un juego.

O sencillamente poner la rutina y todos sus datos en una página sin contienda, en un 128K, y cuando se quiera mostrar algo, paginar esa parte de la RAM y usar la rutina. Que es que esto de ceñirse "sí o sí" a los 48K de la primera versión me parece demasiado radical.

[Z80user]

He mirado el codigo de la rutina de impresion de pantalla que hay en el test de Natalie Portman,veo que para imprimir en la pantalla se usa
LD SP,#----
LD HL,#----
PUSH HL
repitiendose 7 veces
los repistros DE y BC se podrian utilizar para quizas poder imprimir una linea mas en la pantalla,
osea cargar 3 juegos de registros en lugar de solo 1, cargar DE y BC se puede sustituir por algunos retardos, no he mirado lo que tardaria en encontrarse el retrazo con el numero de T-States que duraria hasta dicha zona, por lo que no se si con intercambiar colores con LD r,r en lugar de cargar los valores en HL directamente, podrian obtenerse algunos T-States.

No me he documentado mucho acerca del uso de IN (#FF) para la sincronizacion con la lectura de la pantalla, pero en referencia al retardo de T-States desde que se produce la INT, hasta que se empieza a volver a pintar la pantalla, se puede contar el numero de T-States, que deberia ser identico para un determinado tipo de maquina +/- algunos T-States que pueden variar al detectar la INT en segun que momento

Lo de usar la CPU el 100% del tiempo parece que no es del 100%, hay NOPs y LD A,#00 (que seria mejor que usar el registro A), asi que si se podria intercalar alguna rutina entre medias de la de pintar la pantalla, aunque son pocos T-States los que hay, y encima hay que ajustar cada bloque para que siga siendo de 224/228 T-States lo que durase cada retrazo con la incrustacion de la rutina, y cambiar HL por BC, ya que los bucles no daria tiempo a usarlos y DE se puede usar para hacer sumas, o directametne perder 8 T-States usando EXX y teniendo el juego de registros alternativos completo.

Una optimizacion que se podria hacer, es usar JR $+1 (12 T-States con 2 bytes)
[3] LD B,#FF
[8] NOP

LD HL,#FFFF
LD L,#FF
[3]JR $+1

21+32=53 (14 bytes)
10+7+12*3=17+36=53 (11 bytes)
Ahorramos 3 bytes por cada linea en alta resolucion

En maquinas de 128K usando el intercambio de pantalla, supongo que se podria aumentar aun mas la resolucion, teniendo 2 zonas para intercambiar la ejecucion segun la pantalla, y se podria incluso aumentar la resolucion de la imagen, pues se podria no usar retardos y enviar un out para el intercambio de pantalla, y el resto del tiempo mandar a saco todos los cambios de color que se pudiesen realizar, que como seria en una pantalla que no es visible, habria mas tiempo para poder cambiar mas numero de colores.

[Z80user]

Aquí tenéis un cutre-dibujo que he realizado usando Colorator (http://colorator.sourceforge.net):
//.arce

Marce: Podrias hacer que el editor grafico generase ficheros con resolucion de pantalla completa, es decir 256*384 (el doble de resolucion vertical)
La formula para obtener las pantallas en screen$ seria tomar las lineas pares para una y las impares para la segunda pantalla.
Con los atributos no me he enterado muy bien como estan, pero creo que en formato crudo segun se direcciona, con las mismas restricciones que el screen$ estaria bien.

[marce]

A ver que dice mi hermano Juanjo... Él hizo Colorator, yo solo pintarrajee aquello.

Lo que dices de tener más colores tiene la desventaja del parapadeo, no? Aquí pasa, por ejemplo:
http://programbytes48k.wordpress.com/20 ... l-spectrum

[na_th_an]

Si pudiésemos emplear esto en conjunción con un compresor como exomizer o aapack sería ideal, si no, ocupa demasiado para usarlo en un juego.

O sencillamente poner la rutina y todos sus datos en una página sin contienda, en un 128K, y cuando se quiera mostrar algo, paginar esa parte de la RAM y usar la rutina. Que es que esto de ceñirse "sí o sí" a los 48K de la primera versión me parece demasiado radical.

Muchas veces, cuando programas en C, ejecutar rutinas en otras páginas de RAM puede ser bastante problemático.

[Z80user]

A ver que dice mi hermano Juanjo... Él hizo Colorator, yo solo pintarrajee aquello.

Lo que dices de tener más colores tiene la desventaja del parapadeo, no? Aquí pasa, por ejemplo:
http://programbytes48k.wordpress.com/20 ... l-spectrum

No habia visto la imagen esa, la he probado con el ZX-Spin y es lo que tenia pensado hacer, pero parece que hasta sobra tiempo, si hay que hacer imprimir con el push varios colores de forma identica, asique aun con toda la CPU que consume, aun quedan algunos ciclos de CPU, pero hay que aprobecharlos muy bien, yo cambiaria alguna cosa, para consumir menos memoria, y es que las lineas saltasen con JP (HL) de unas a otras, pero para hacer algo con una rutina asi, tiene que sobrar mucha memoria para meterla en un videojuego

[marce]

mcleod_ideafix, ¿te costaría mucho hacer la rutina compatible con los +2A y +3? Me gustaría hacer un slideshow de pantallas de estas para el +3.

Saludos,
//.arce

[marce]

Ahí va una pantalla modificada de mi cosecha...



Saludos,
//.arce

[zxbruno]

Más, por favor, ¡más¡

[tkmaniac]

Que bueno pinta ese slideshow, espero que lo hagas para poder verlo en mi +3, ¡felicitaciones!