BASIC Standard: Acelerar carga de matrices

[elfoscuro]

Yo también aconsejo usar la memoria, pasar de los DATAS (sobre todo pasar de los DATA), y funcionar con POKE-PEEK. Si no puedes cargar nada de bytes, y sólo puedes hacer BASIC, pon muchos pokes seguidos. Incluso así, será más rápido que recorrer las líneas DATA.

También, como consejo, las DATA, DEF FN, y demás cosas necesarias para inicializar el juego... al principio del todo. Es costumbre poner las DATA al final del listado... ponlas al principio, y usar RESTORE.

Y, aun a malas... medio BASIC medio CM... deja una línea 1, con REM y tantos carácteres (espacio, 0, o lo que sea), como el tamaño de los datos. Luego "POKEas" esa línea con los valores de tu mapa. Luego, repites con otra línea también llena de ceros, y usando las variables del sistema para saber en que dirección empieza el programa...

Mapa de trabajo: VALOR de las variables del sistema de inicio BASIC+5 (creo que eran 5 bytes el principio de línea incluido el REM)
Mapa de reserva: VALOR de las variables del sistema de inicio BASIC+5 (creo que eran 5 bytes)+tamaño del mapa+5 (de la segunda línea).

Esas dos líneas, al principio, tendrían toda la info que necesitas, te ahorras POKES y demás... pero no podrás listarla. Siempre tendrás que hacer LIST a la siguiente línea, lo que es ya el programa en si (por ejemplo, línea 30), y hacer SAVE "programa" LINE 30

Esto es lo que se hacía en el ZX81, porque este equipo no tiene LOAD ""CODE, sólo LOAD"" y había que programar el código máquina así

Espero que ayude. Estoy un poco oxidado con esto, pero vamos, en las MH se comentaba mucho, junto con lo de convertir las primeras líneas en 0 para que no se pudieran editar ni borrar.

Un saludo.

[elfoscuro]

Bueno, en este enlace está como poner una línea cero:

http://microhobby.speccy.cz/mhf/010/MH010_05.jpg

Básicamente consiste en encontrar donde empieza el BASIC con las variables del sistema, y luego poner:

POKE PEEK 23635+256*PEEK 23636,0
POKE PEEK 23635+256*PEEK 23636+1,0

A continuación, siguiendo el manual, vendrían dos bytes que indican la longitud de la línea, y luego vendría un byte para el REM. A partir de ahí, vendría tu mapa "de trabajo", seguido del caracter 13 (ENTER).

Justo entonces, empieza la segunda línea. Se POKEa con cero los dos primeros bytes, los siguientes 3 (2 + REM) se ignoran, y a partir de ahí, el mapa "de reserva".

Para saber exactamente los valores, ve PEEKeando hasta que encuentres 32( (si has puesto espacios después de los REM). Ten en cuenta que si hay un interface 1 conectado, este añade variables del sistema, y el BASIC se desplaza hacia arriba unos bytes.

Madre mía, cuanto tiempo sin meterme con las variables del sistema El juego que daban!!! Como molaba cambiar el juego de carácteres [modo "me pierdo en la nostalgia ON"]

Un saludo.

[Hark0]

Muchas gracias por la info... yo también recordaba todo el tema de las líneas REM para meter datos...

Bendito MH-Google, llevo dos días recorriendolo..

Al final estoy haciendo lo siguiente:

Para almacenar los datos del mapa/graficos/enemigos/etc, voy a olvidarme de los DIM y los DATA.

Voy a cargar directamente a partir de la dirección de memoria 40000 (de momento apuntaré aquí, luego ya veremos) los bytes correspondientes a los datos.

A la hora de iniciar una partida, voy a copiar toda la ristra de bytes a otra posición de memoria (pongamos la 50000), por medio de PEEK y POKE, con los que tendré los datos "originales" a disposición del programa en la nueva ubicación.

TODOS los cambios y o lecturas de datos los realizaré en la dirección 50000, y para el render igual, consultando las posiciones.

En el momento de gameover, mientras muestro alguna pantalla resumen ó similar, VUELVO a restaurar los datos del mapa...


Esta es la teoría, ahora a escribir...

Muchas gracias por los consejos...

[elfoscuro]

Bueno, es que lo que te estaba comentando es para no usar el LOAD "" CODE. Si lo puedes usar, todo es más sencillo

¿Puedes usar pequeñas rutinas en CM? Te lo digo porque para copiar bloques de datos, puedes usar LDIR:

http://microhobby.speccy.cz/mhf/048/MH048_28.jpg

En esta página se usa para mover pantallas, pero se puede usar para cualquier cosa. Lo que hace es mover (comprueba si es copiar, en lugar de mover, porque me parece que no borra los datos originales) los datos desde HL a DE con BC bytes.

Ocupa 12 bytes sólo.

Un saludo.

[na_th_an]

Muchas gracias por la info... yo también recordaba todo el tema de las líneas REM para meter datos...

Bendito MH-Google, llevo dos días recorriendolo..

Al final estoy haciendo lo siguiente:

Para almacenar los datos del mapa/graficos/enemigos/etc, voy a olvidarme de los DIM y los DATA.

Voy a cargar directamente a partir de la dirección de memoria 40000 (de momento apuntaré aquí, luego ya veremos) los bytes correspondientes a los datos.

A la hora de iniciar una partida, voy a copiar toda la ristra de bytes a otra posición de memoria (pongamos la 50000), por medio de PEEK y POKE, con los que tendré los datos "originales" a disposición del programa en la nueva ubicación.

TODOS los cambios y o lecturas de datos los realizaré en la dirección 50000, y para el render igual, consultando las posiciones.

En el momento de gameover, mientras muestro alguna pantalla resumen ó similar, VUELVO a restaurar los datos del mapa...


Esta es la teoría, ahora a escribir...

Muchas gracias por los consejos...

Para quitarte de problemas, empieza a tirar de UDG hacia abajo en RAM, y luego no tienes que andar cambiando cosas de sitio si el BASIC ocupa más y más. Pon el original en 65368-1125 y la otra justo debajo.

De todos modos, insisto en que puedes hacer que el programa vaya mucho más rápido almacenando los cambios cuando los hagas y restaurando sólo lo que hayas cambiado.

[Hark0]

Bueno, es que lo que te estaba comentando es para no usar el LOAD "" CODE. Si lo puedes usar, todo es más sencillo

¿Puedes usar pequeñas rutinas en CM? Te lo digo porque para copiar bloques de datos, puedes usar LDIR:

http://microhobby.speccy.cz/mhf/048/MH048_28.jpg

En esta página se usa para mover pantallas, pero se puede usar para cualquier cosa. Lo que hace es mover (comprueba si es copiar, en lugar de mover, porque me parece que no borra los datos originales) los datos desde HL a DE con BC bytes.

Ocupa 12 bytes sólo.

Un saludo.

NO! Que yo sepa SOLO Basic... ya tenia en mente algo así, pero NO se permite.

Normas concurso "reducidas":

- Ser de nuevo desarrollo
– Estar programados integramente en lenguaje BASIC, sin rutinas en ensamblador
– Usar exclusivamente los recursos de la máquina original
– Estar realizados para ZX Spectrum en cualquiera de sus variantes (16K, +3, etc)

[Hark0]

Para quitarte de problemas, empieza a tirar de UDG hacia abajo en RAM, y luego no tienes que andar cambiando cosas de sitio si el BASIC ocupa más y más. Pon el original en 65368-1125 y la otra justo debajo.

De todos modos, insisto en que puedes hacer que el programa vaya mucho más rápido almacenando los cambios cuando los hagas y restaurando sólo lo que hayas cambiado.

hmmm te refieres a restaurar SOLO lo que se modifica... esto requeriria alguna especie de "log" para que el programa sepa que se ha cambiado... hmmm interesante opción.

[na_th_an]

A eso me refería desde el principio Básicamente tienes que almacenar qué posiciones cambian y qué valor tenían, usando alguna codificación. Si tu mapa va a cambiar "poco", esto es lo ideal porque la restauración es cuestión de un par de segundos.

Para facilitarte las cosas, puedes centralizar las escrituras al mapa en una rutina que se encargue de todo. Por ejemplo:

Código: Seleccionar todo

100 LET backup = PEEK direccion
110 LET msb = INT (direccion/256): LET lsb = direccion - msb * 256
120 POKE res, lsb: POKE res+1, msb: POKE res+2, backup
130 LET res = res + 3
140 POKE direccion, valor: RETURN

Se llama con las variables "direccion" y "valor" con la dirección que vas a cambiar y el valor. Se supone definida la variable "res", que es donde estará ubicado tu backup. La rutina lée qué había en la dirección original que vas a cambiar, y almacena la dirección que cambia (lsb y luego msb) y dicho valor en el backup, incrementando luego el índice.

Cuando termine el juego, sólo tendrás que volver a recorrer desde el inicio del backup hasta res y restaurar:

Código: Seleccionar todo

500 FOR n=res0 TO res-1 STEP 3
510 LET lsb = PEEK res: LET msb = PEEK (res+1): LET valor = PEEK (res+2)
520 POKE lsb + 256*msb, valor
530 NEXT n

[Hark0]

A eso me refería desde el principio Básicamente tienes que almacenar qué posiciones cambian y qué valor tenían, usando alguna codificación. Si tu mapa va a cambiar "poco", esto es lo ideal porque la restauración es cuestión de un par de segundos.

Para facilitarte las cosas, puedes centralizar las escrituras al mapa en una rutina que se encargue de todo. Por ejemplo:

Código: Seleccionar todo

100 LET backup = PEEK direccion
110 LET msb = INT (direccion/256): LET lsb = direccion - msb * 256
120 POKE res, lsb: POKE res+1, msb: POKE res+2, backup
130 LET res = res + 3
140 POKE direccion, valor: RETURN

Se llama con las variables "direccion" y "valor" con la dirección que vas a cambiar y el valor. Se supone definida la variable "res", que es donde estará ubicado tu backup. La rutina lée qué había en la dirección original que vas a cambiar, y almacena la dirección que cambia (lsb y luego msb) y dicho valor en el backup, incrementando luego el índice.

Cuando termine el juego, sólo tendrás que volver a recorrer desde el inicio del backup hasta res y restaurar:

Código: Seleccionar todo

500 FOR n=res0 TO res-1 STEP 3
510 LET lsb = PEEK res: LET msb = PEEK (res+1): LET valor = PEEK (res+2)
520 POKE lsb + 256*msb, valor
530 NEXT n

Capicci!!!

Probaré tu técnica (o no), en función de ver cuanto cambian los valores del mapa.

[elfoscuro]

No me parece aconsejable (aunque, por supuesto, depende del volumen de información) usar un log. Eso obliga a perder un tiempo del bucle principal del juego, que habría que medir.

No creo que copiar con POKE y PEEK sea tan lento. Una vez abandonadas las matrices, trabajar con la memoria es hipervelocidad!!!

No me parece tan descabellado que el jugador tenga que esperar un par de segundos o tres para empezar una nueva partida. Incluso puedes "esconder" ese tiempo, haciendo una especie de animación o fanfarria de GAME OVER, y entre medias, vas copiando datos. Si metes un retardo debido a la copia de datos, entre acciones que aparezcan en el fin de partida, ni se nota

Pero vamos, que recorrer un bucle de POKE XXXXX,PEEK XXXXX+500, no debe ser tan lento como una copia de matrices. Haz un cálculo de este bucle:

10 FOR f=0 to LEN_DATOS-1
20 POKE 30000+f,PEEK 35000+f
30 NEXT f

Siendo 30000 la dirección del mapa de trabajo, y 35000 la del mapa de respaldo, y LEN_DATOS el tamaño del mapa en bytes.

Si el tiempo es exagerado, quizá te valga la opción del log, aunque el LOG gasta RAM (al menos 3 bytes por cambio), y tendría un tamaño máximo... ¿puedes asegurar que los cambios no excederán ese tamaño? Quizá si, quizá no. En otro tipo de máquina puedes concederte según que licencias, pero en un Spectrum cada bit (no byte, bit) cuenta.

Un saludo.

[elfoscuro]

Y una cosa... ¿realmente estás cambiando la pantalla? Quiero decir, que si los cambios son de tener o no tener un objeto en cierta pantalla, o algún tipo de plataforma movil subida o bajada... no es necesario hacer tanto lío.

Normalmente habría que crear los "objetos" del juego, con sus variables PANTALLA, X, Y y los objetos móviles sólo con ACTIVADO si/no o X,Y si se pueden mover en varias posiciones. De esta manera, sólo tendrías que inicializar los móviles, no el total. Con eso reduces el tiempo del bucle de juego mucho, porque el tiempo de inicializar los objetos sería nulo. Incluso podrías usar la habitación 0 para "llevado por el jugador" al estilo de las conversacionales...

Es que, ahora que pienso, ni siquiera has dicho la temática del juego!!! (o no la he visto).

Un saludo.

[Hark0]

No me parece aconsejable (aunque, por supuesto, depende del volumen de información) usar un log. Eso obliga a perder un tiempo del bucle principal del juego, que habría que medir.

Yo he pensado lo mismo, por eso he puesto como respuesta que dependerá de todo lo que se vaya a restaurar. Personalmente creo que el log retrasaría todo...

No creo que copiar con POKE y PEEK sea tan lento. Una vez abandonadas las matrices, trabajar con la memoria es hipervelocidad!!!

Eso espero!!! Me he cepillado todos los DIM y todas las DATA

No me parece tan descabellado que el jugador tenga que esperar un par de segundos o tres para empezar una nueva partida. Incluso puedes "esconder" ese tiempo, haciendo una especie de animación o fanfarria de GAME OVER, y entre medias, vas copiando datos. Si metes un retardo debido a la copia de datos, entre acciones que aparezcan en el fin de partida, ni se nota

OJO! Por tres segundos ni me comería la cabeza, pero me temo que será más tiempo... creo que unos 18-20 sec...

Se me ha ocurrido RESTAURAR por bloques... tal como termina la partida, voy empezando a restaurar, presento pantalla de resultados o lo que sea, restauro otro bloque, etc etc

Pero vamos, que recorrer un bucle de POKE XXXXX,PEEK XXXXX+500, no debe ser tan lento como una copia de matrices. Haz un cálculo de este bucle:

10 FOR f=0 to LEN_DATOS-1
20 POKE 30000+f,PEEK 35000+f
30 NEXT f

Siendo 30000 la dirección del mapa de trabajo, y 35000 la del mapa de respaldo, y LEN_DATOS el tamaño del mapa en bytes.

Si el tiempo es exagerado, quizá te valga la opción del log, aunque el LOG gasta RAM (al menos 3 bytes por cambio), y tendría un tamaño máximo... ¿puedes asegurar que los cambios no excederán ese tamaño? Quizá si, quizá no. En otro tipo de máquina puedes concederte según que licencias, pero en un Spectrum cada bit (no byte, bit) cuenta.

Un saludo.

Probaré esto que comentas, de momento estaba limpiando el listado (ya no recordaba los engorros de los números de lineas y lo CERRADO del sistema en sí (me refiero a sintaxis, modo del listado/editor, etc).

[Hark0]

Y una cosa... ¿realmente estás cambiando la pantalla? Quiero decir, que si los cambios son de tener o no tener un objeto en cierta pantalla, o algún tipo de plataforma movil subida o bajada... no es necesario hacer tanto lío.

Normalmente habría que crear los "objetos" del juego, con sus variables PANTALLA, X, Y y los objetos móviles sólo con ACTIVADO si/no o X,Y si se pueden mover en varias posiciones. De esta manera, sólo tendrías que inicializar los móviles, no el total. Con eso reduces el tiempo del bucle de juego mucho, porque el tiempo de inicializar los objetos sería nulo. Incluso podrías usar la habitación 0 para "llevado por el jugador" al estilo de las conversacionales...

Es que, ahora que pienso, ni siquiera has dicho la temática del juego!!! (o no la he visto).

Un saludo.

La idea inicial era tener una matriz para los gráficos, otra matriz para tipo de tile (atravesable, bloqueada, foso, muerte subita, etc, etc), otra matriz para los objetos y finalmente una para enemigos...

Vistas las limitaciones del asunto (ya he comentado que se acomoda uno muy pronto a las ventajas del hard actual), voy a tener que reducir (y bastante) todo lo que tenía intención de meter...

Evidentemente, TODO el mapa no se modifica; se puede hacer que el mapa SIEMPRE sea igual, INMODIFICABLE, luego diseñar / añadir los objetos (que se pueden recoger) e incluso aprovechando los "objetos" objeto, crear algunos que sean destruibles pero con tile de mapa (por ejemplo un muro). No se si me he explicado.

Creo que el tema del log NO me interesa, estamos en BASIC "pelao", sin potencia... así que a arremangarse tocan...


Sobre la temática del juego, como ya comenté en el primer post, es un juego RPG para el concurso Bytemaniacos...

[Ivanzx]

La verdad que no te puedo ayudar mucho aqui, ya que los juegos que hice en su momento en Basic no es que exprimieran la maquina

http://www.worldofspectrum.org/infoseekpub.cgi?regexp=^Pepsi+Soft$&loadpics=3

pero a ver si el tuyo llega a buen puerto, y ademas anima a mas gente a participar , asi que animo

[Hark0]

GRACIAS!!!! (Habrá que catar eso tuyo.... )