Cosas interesantes...

[Iapetus]

La velocidad no me ha impresionado y lo que preocupa realmente es la memoria disponible para el programa. Este programa es pequeño y cuando MAP genera el mapa de memoria me parece que solo tengo 4.5kb libres? No puede ser digo yo, debo estar interpretando mal ese mapa de memoria.


mapamemoria.jpg (181.1 kB . 1529x1275 - visto 133 veces)

[SingletonJohn]

La velocidad no me ha impresionado y lo que preocupa realmente es la memoria disponible para el programa. Este programa es pequeño y cuando MAP genera el mapa de memoria me parece que solo tengo 4.5kb libres? No puede ser digo yo, debo estar interpretando mal ese mapa de memoria.

Te quedan 4,5k libres teniendo en cuenta que tienes en memoria el Compilador, que son 15872 bytes y el editor, que son 11776 bytes. Eso no va a estar ahí cuando el programa se ejecute en standalone. Si no usas matemáticas de números reales, puedes rascar 2,5 K más. Las versiones standalone de tus programas llevan un kernal del PROMAL y el resto lo tienes para ti (con las puntualizaciones que todos sabemos).  El tamaño del workspace lo puedes modificar con el comando WS <tamaño del workspace>....todo esto viene explicadoen del Developers Guide, pero no termino de entender todo al 100%

En cuanto a la velocidad, no está mal para ser un lenguaje diferente al ensamblador....

[Iapetus]

Si quiero continuar con esto tengo que leer la documentación con atención porque la cuestión de la memoria es muy importante y necesitaré al menos unos 20kb.

Esa velocidad no me sirve en este contexto porque el jugador al pasar de una pantalla a otra y especialmente cuando se dá un salto para una pantalla que está arriba la jugabilidad será muy afectada por el dibujado lento de los padrones. Optimizar el código actual no me parece que haga mucha diferencia, lo mejor será usar rutinas en código máquina para estos casos, lo peor es que no me parece que PROMAL permita código máquina "inline" y así siendo habría que compilar las rutinas fuera del sistema PROMAL y cargarlas después.

[SingletonJohn]

Eso es un fallo si!

De todas formas, qué rutina usas en el dibujado? Me da la impresión que haces un bucle for al tile...o me equivoco y haces un BlockMove??? Hay una diferencia grande....

[Iapetus]

Eso es un fallo si!

De todas formas, qué rutina usas en el dibujado? Me da la impresión que haces un bucle for al tile...o me equivoco y haces un BlockMove??? Hay una diferencia grande....

Cuando programé la rutina no pensé en optimización porque me gustaría saber que velocidad se lograría con algo sencillo. Para dibujar un caracter uso un array para la pantalla y otro para los atributos después hago tipo pantalla[x][y] = caracter cram[x][y]=atributo. la rutina de dibujar el padrón de 2x2 caracteres lee otro array con la información de padrones, y llama la rutina de dibujar caracter 4 x. Para pintar la sala, tengo más uno array con la información de 240 padrones y un bucle lee el padrón y llama pintarpadron.

[josepzin]

Está quedando muy interesante esto del PROMAL, cuando tenga un rato voy a separar esta parte de los comentarios en un hilo dedicado a este lenguaje!

[SingletonJohn]

Cuando programé la rutina no pensé en optimización...

Ya, entiendo. Pero para sacarle jugo hay que optimizar....un bucle for tile a tile es lento.
Y tal como lo tienes montado no hay mucha opción más...igual pintando dos lineas de tiles en un buffer y luego moviendo el buffer a la pantalla con block move se ganaría algo...no lo tengo claro

[SingletonJohn]

Está quedando muy interesante esto del PROMAL, cuando tenga un rato voy a separar esta parte de los comentarios en un hilo dedicado a este lenguaje!

Pues acabo de abrir otro de Durex FORTH....es un proyecto actual y bastante interesante

[Iapetus]

Usando un buffer sería aún más lento, porque tendríamos que dibujar y después copiar. Yo he cambiado la rutina de pintar metabloques — esos bloques de 4 caracteres — y ahora ya no llama 4 veces a la rutina que pinta un carácter a la vez; ahora ella sola dibuja los 4 caracteres. Está más rápido, pero no mucho.
Lo que puedo hacer para que no se vea el dibujado de la pantalla es ocultarla mientras se dibuja y mostrarla una vez terminado. Visualmente esto es lo mejor, y es lo que hago en algunos juegos que he programado. Pero el problema es que cada vez que pasamos de una pantalla a otra habrá un hiato que afectará la jugabilidad cuanto más largo sea.

[SingletonJohn]

Depende de cómo montes el buffer y de la naturaleza del juego.
Un buffer se puede ir rellenando en los "ratos libres" del procesador. Y si es un juego de "pantalla a pantalla" tienes MUUCHO tiempo.

Con un scroll hardware tienes menos tiempo, pero usando una shadow screen/doble buffer/como lo quieras llamar, también merece la pena usarlos

Si es simplemente hacer un buffer para inmediatamente después copiarlo....pues tiene menos sentido

Lo de ocultar la pantalla entiendo que hablas de poner en off el bit 4 de $D011?

[Iapetus]

Depende de cómo montes el buffer y de la naturaleza del juego.
Un buffer se puede ir rellenando en los "ratos libres" del procesador. Y si es un juego de "pantalla a pantalla" tienes MUUCHO tiempo.

Con un scroll hardware tienes menos tiempo, pero usando una shadow screen/doble buffer/como lo quieras llamar, también merece la pena usarlos

Si es simplemente hacer un buffer para inmediatamente después copiarlo....pues tiene menos sentido

Habías dicho :

...pintando dos lineas de tiles en un buffer y luego moviendo el buffer a la pantalla con block...

Por eso no había entendido bien tu intención.

El mapeado de este juego no es lineal, así que habría que tener unos cuatro buffers de pantalla para las cuatro posibles direcciones.

Hoy, cuando tenga un rato, intentaré optimizar el dibujado de pantalla.

(nota:He hecho una prueba en Pascal TRSE y traduje la rutina de Promal a Pascal, y el dibujado es prácticamente instantáneo.)

Lo de ocultar la pantalla entiendo que hablas de poner en off el bit 4 de $D011?

Sí eso es.

[Iapetus]

Versión final de la rutina, no hay grande diferencia de velocidad entre esta y otras versiones. PROMAL es un lenguaje que me parece interesante y no lo tengo descartado, pero por ahora voy a volver a mis otros proyectos.

Código: [Seleccionar]

PROC PINTASALA
WORD I
WORD J
WORD P
WORD SP
WORD CP
WORD TP
WORD SP2
WORD CP2
BYTE C

BEGIN
P = #SALA0
SP = #SCREEN[0,1]     
CP = #CRAM[0,1]       
FOR J = 0 TO 11
  SP2 = SP+40         
  CP2 = CP+40
  FOR I = 0 TO 19
    TP = #TILES[M[P]<<2]
    C = M[TP]
    M[SP] = C
    M[CP] = ATRB[C]
    C = M[TP+1]       
    M[SP+1] = C
    M[CP+1] = ATRB[C]
    C = M[TP+2]
    M[SP2] = C
    M[CP2] = ATRB[C]
    C = M[TP+3]
    M[SP2+1] = C
    M[CP2+1] = ATRB[C]
    P = P+1
    SP = SP+2         
    CP = CP+2
    SP2 = SP2+2
    CP2 = CP2+2
  SP = SP+40
  CP = CP+40
END

[Bieno]

https://youtu.be/qTnmDlRaePI?si=b30dVPjHZ0oMWcHu

Sebastián "Gavilan" Gurvitsch de la escena argentina nos presenta este teaser de lo que parece será un documental muy interesante sobre como estaba el panorama en su país al que titula "Fabricantes, ensambladores, clones, truchos y piratas. La verdadera historia de las computadoras hogareñas con sello nacional."
Estaremos atentos.

[josepzin]

Todos los chanchullos al descubierto! aunque ya se saben unos cuantos, a ver cuáles otros hubo.

[josepzin]

"Clientes Mastodon para tu computadora retro" incluyendo la 64
https://www.fabio.com.ar/9908-clientes-mastodon-para-tu-computadora-retro