Página 2 de 2

Re: Concurso Demoscene BASIC

Publicado: Lun Abr 09, 2012 2:51 pm
por radastan
marce escribió:A mi me parece una idea cojonuda. Se me acaba de ocurrir proponer para la celebración del 30 aniversario que hacemos en Mallorca (http://www.retromallorca.com/es/30-aniversario-spectrum/) hacer algo entre los que se presenten voluntarios (dado que no creo que haya suficiente gente para que tengamos nuestra propia competición). Pero claro, para eso habría que ampliar el plazo hasta el 21....


Ya no hay plazo, el concurso es todo lo que de el hilo de si hasta el infinito y más allá.

Yo trataré de hacer algunas cosillas más y creo que indagaré como sacarle provecho a lo comentado por Na_th_an respecto a la copia rápida de pantalla, podría salir un scroll chulo y todo.

Re: Concurso Demoscene BASIC

Publicado: Dom Abr 15, 2012 9:45 am
por josepzin
Agregado a la Retroinvaders agenda, aunque le puse fecha de vencimiento a final del año.
http://retroinvaders.com/es/concurso-de ... um/cal:114

Re: Concurso Demoscene BASIC

Publicado: Mar Abr 17, 2012 7:42 pm
por marce
¿Hay que programar con el BASIC de la ROM o se puede usar un compilador como el de Boriel?

Jeje, de momento ya he visto una demo hecha por un amigo. Muy divertida. La presentaremos el sábado, a ver si nos sale algo más...

Re: Concurso Demoscene BASIC (LDIR en Basic)

Publicado: Jue Feb 27, 2014 6:40 pm
por Hark0
na_th_an escribió:Pues la verdad es que eso me parece una idea genial... En plan "rey de la colina". El que entra se parte la boca con el que gana, y si es mejor, se cambia.

Sobre lo otro, todo en este hilo de WOS. La verdad es que la sección de BASIC del WOS está últimamente llena de cosillas curiosas.

http://worldofspectrum.org/forums/showt ... hp?t=33911

Traduzco patatalmente:
Battle Bunny escribió:Blablabla me pareció que debería ser posible, con un poco de trucaje, copiar un SCREEN$ (o cualquier segmento de memoria) en ZX BASIC sin tener que recurrir a un tedioso bucle de POKEs.

Tras unos cuantos inicios en falso determiné que de hecho era posible, y aquí tenéis una demo de la solución. Cargad una pantalla cuando se os pregunte, y entonces pulsad "j". La pantalla se borrará y después se restaurará casi tan rápido como haciendo un LDIR en código máquina, pero usando sólamente Sinclair BASIC estándar. Y no es una inocentada.

¿Cómo es que LET s$=a$ funciona isn que a$ esté definida? La explicación, más abajo, en el caso de que quieras averiguarlo por tí mismo...

Código: Seleccionar todo

  10 DIM s$(6912): DEF FN p(a)=PEEK a+256*PEEK (a+1):
     DEF FN l(v)=v-256*FN h(v): DEF FN h(v)=INT (v/256):
     LET udg=FN p(23675)
  20 LET df=16384: LET dl=6912: LET defadd=23563
  30 FOR a=udg TO udg+8: READ v: POKE a,v: NEXT a:
     DATA 65,36,14,0,FN l(df),FN h(df),FN l(dl),FN h(dl),41
  35 PRINT #0;"load a SCREEN$ then press ""j"""
  36 IF INKEY$<>"j" THEN PAUSE 0: GO TO 36
  40 POKE defadd,FN l(udg): POKE defadd+1,FN h(udg):
     LET s$=a$:
     POKE defadd,0: POKE defadd+1,0
  50 CLS : PRINT #0;"press ""j"" again"
  51 IF INKEY$<>"j" THEN PAUSE 0: GO TO 51
  60 POKE defadd,FN l(udg): POKE defadd+1,FN h(udg):
     LET a$=s$:
     POKE defadd,0: POKE defadd+1,0: PAUSE 0


Funciona porque LOOK-VARS (la función de la ROM que busca una variable en la memoria mientras se ejecuta un programa BASIC) busca en el área DEFADD (donde las funciones FN están definidas) antes de buscar en VARS. Así que lo que se hace es crear un área DEFADD en el espacio de los UDG para definir a$ como si empezase en 16384 y ocupase 6912 bytes. Entonces se pokea la viariable de sistema DEFADD para que apunte a nuestro área, y así a$ se convierte en "la pantalla".


Usa cualquier otra dirección en vez de la de UDG si lo necesitas et voie la. En realidad lo que hace es engañar a BASIC para que se crea que la memoria de pantalla es la variable a$. Luego, copiando esta variable, copias la pantalla. Puedes hasta copiar un trozo usando string slicing: a$ (2048 TO 4095) es el segundo tercio, por ejemplo.


He preguntado en WOS acerca de esta rutina, que es impresionante, y me han respondido, pero me empano... nontiendo naa...

¿alguien me ilumina para copiar 200 bytes de la posición A a la posición B de la RAM? ¿una rutina más simple?

Estoy muy confundido la verdad... :?

La idea de mi programa es que sea puro basic, pero me tarda un pelín en cargar el mapa... y no es plan... he probado un LDIR y claro, es instantáneo... contra el basic que se me come 8 secs... y me temo que no tengo espacio para pantallas "de entretenimiento" mientras cargo el nivel de turno... :(

Re: Concurso Demoscene BASIC

Publicado: Dom Mar 02, 2014 4:08 pm
por mcleod_ideafix
Guarda tus pantallas en variables de cadena. En ellas puedes incluso poner códigos AT para dibujar donde quieras, o códigos de color. Cada pantalla de hecho podría ser un elemento de un array de cadenas, tal que así: DIM p$(10,700) (he puesto 700 de longitud por poner un valor; habría que ajustarlo a la mayor de tus pantallas).

Para volcar la pantalla N, tan sólo tienes que hacer: CLS: PRINT AT 0,0;p$(N);

Lo mejor del asunto es que puedes tener las pantallas pre-generadas y grabadas a cinta, de forma que no gasten memoria de código BASIC en el listado. Las puedes cargar con tu juego con algo como: LOAD "pantallas" DATA p$()

Re: Concurso Demoscene BASIC

Publicado: Lun Mar 03, 2014 7:21 am
por Hark0
Vale, esta parte si la entiendo... y de hecho, es lo que estoy usando en mi codigo...

Actualmente tengo una variable v$(32,20) que seria el "buffer de video"...
Luego tengo en ram la ristra de bytes que corresponden a los codigos de cada tile (16x10: 160 bytes).

Cuando cargo un nivel, leo la "rsitra de bytes", y en función del contenido, "relleno/machaco" la posición correspondiente de v$() con los 4 caracteres que forman el tile. Con este metodo tengo la variable "buffer video" con la pantalla completa del mapa. Perfecto porque pinto v$ de un golpe y no tarda nada.

Tras dibujar la pantalla, pinto encima el personaje que controlamos... y cada vez que pulso para que se mueva (QAOP), lo que hago es comprobar los bytes de la ristra... dependiendo del byte obtenido, dejo pasar, bloqueo, recoge item ,etc...

Si el personaje se puede mover, pinto en posición del personaje los caracteres v$(x,y) e v$(x,y+32)... usando print v$(posicion TO posicion+1) con el tile correpondiente (que se obtiene de la ristra de bytes)...

Lo que me resulta más lento es cargar los mapas desde la zona de la ram original (cargado desde cinta), hasta la zona ram que utilizo para examinar. He probado diferentes trucos como reemplazar en v$ el tile SOLO si es diferente, o en lugar de leer todo el mapa completo, leer solo los nuevos tiles, reseteando el resto...

Lo haga como lo haga, minimo me tarda unos buenos 8 segundos (en emuladores, máquina real desconozco)... si, ya, podria añadir un texto y/o imagen para entretener mientras cargo el mapa... pero me estoy quedando sin ram... por no contar que no me gusta nada hacer esperar 8 segundos a nadie...

Probando la rutina que se comenta aqui, se copian los 768 caracteres+atributos de un tiron, de una zona de la ram a la otra, lo que me iria de perlas para cargar el nivel, ya que solo tendria que reconstruir v$...

Viene a ser un LDIR en basic... (he probado montando una rutinilla CM LDIR... y no hay color, zas, lo hace del tiron y rapido rapido), pero como soy un capullo... y quiero solo basic, pues nada, a ir lenticos...


Hoy quiero probar a usar solo pokes, en lugar de: v$(pos to pos+1)=s$(codigotile, 1 to 2), etc... para pokear directamente en la zona donde v$ esta ubicada... tengo la rutina a medias, v$ localizada en ram, etc...hoy si tengo tiempo la termino...

Re: Concurso Demoscene BASIC

Publicado: Lun Mar 03, 2014 2:48 pm
por radastan
Lo que viene de perlas es usar el espacio de atributos con esta técnica, puedes meter muchos frames de animación en memoria a todo color.

Re: Concurso Demoscene BASIC

Publicado: Mar Mar 04, 2014 8:17 am
por Hark0
Bueno, he estado probando cosas...

En el bucle que empleo para "crear" mi buffer de video v$...

utilice POKE o bien LET v$(posicion TO posicion+1), no bajo del tiempo comentado... he llegado a dejarlo en 8,5 segundos, pero no me doy por satisfecho...

¿alguna alternativa para construir la variable v$(32*10)?

:cry:

Tengo otra opción, que consistiría en leer de la RAM original no los 160 bytes de la pantalla, sino solo los que voy a ocupar... pero se me presenta el problema de que al no ser posiciones secuenciales, tendre que calcular la posicion exacta en la memoria de v$, con lo que me temo que tendré un bucle lento también... por no hablar que en mapas más completos el tiempo se alargará...

Estoy meditando en escribir una rutina CM para esta rutina de carga de mapa, pero esto CHOCARIA DE FRENTE con mi objetivo de emplear unicamente Basic...

En un lado del ring la velocidad... en el otro el empleo exclusivo de basic... hmmm SOCORROOOOO