IMPORTANTE - convocatoria de The Mojon Twins

[na_th_an]

La verdad, ni idea. Creo que nunca he usado ATTR para nada así que no sé por qué está hecho así. Si attr.bas es una de las bibliotecas estándar, que de un warning no mola. Tendrías que comentárselo a Boriel, agradecerá el reporte.

Mientras tanto, puedes usar tu propio ATTR:

Código: Seleccionar todo

Function myAttr (x As uByte, y As uByte) As uByte
   Return Peek (22528 + x + (y << 5))
End Function

Se usa igual:

Código: Seleccionar todo

If myAttr (0, 0) = 7 Then ...

(Lo he escrito de memoria, pero debería ir)

[Alxinho]

Muchas gracias tío! Voy a probar lo que dices urgente (ya había pensado hacerlo así) porque no hay manera que me funcione bien el jodío ATTR, igual es cosa de mi código pero vamos, creo que lo hago bien, un simple si adelante está negro píntame, y lo que me ocurre es que a veces va y otras no

[JBGV]

Hola!

Yo he usado la función ATTR alguna vez y es cierto que daba un Warning fastcall al compilar, pero no recuerdo que me diera problemas al ejecutar luego.

Ahora, si a veces funciona y a veces no, eso si que es un problema que tendríamos que decir a Boriel.

[Alxinho]

Pare ver que no es problema de mi código haré un miniprograma simple de algo que se mueva y punto, a ver si es que tengo algún conflicto con las variables o yo que sé.

He probado lo que me ha dicho Nathan y tampoco me va bien, tiene pinta de ser algo mío.

[Alxinho]

Pregunto ... a ver si puede ser por este motivo ...

Si tu pintas un recuadro de papel lila y tinta lila por ejemplo y tu personaje que es de papel negro tinta verde pasa por encima pintando este cuadro lila en negro ¿la videoram se actualiza automaticamente? esa zona será un valor de atributo 0?

Yo creo que sí se actualiza pero como el muñeco es de tinta verde debe considerar esa posición de la memoria de atributos con una tinta verde aunque no se vea nada ¿no?

No sé si me he liado ... pero me parece que es ésto lo que me está jodiendo ...

Edito: Al final lo he hecho usando los supercaráteres (a lo chapuza claro) detectando la posición en un array aunque me habría sido mucho más cómodo con los atributos, en fin ...

[na_th_an]

Creo que tu problema es con el valor con el que estás comparando. Un cuadro de tinta verde y papel negro tiene atributo 4, no 0. El atributo se calcula como ink + paper*8 + bright*64 + flash*128. Mira a ver si es esto.

O sea, es lo segundo que dices, ahora que leo más despacio.

Hay que tener mucho cuidado, si usas detección por atributos, con las tintas "que no se ven". Aunque haya un espacio, si es un espacio con tinta amarilla, por ejemplo, el atributo leído será 6.

Yo lo que hacía en tiempos era asegurarme de que siempre que desplazaba algo lo borraba usando un espacio con tinta 7 papel 0, con lo que el atributo "vacío" siempre era "7".

Si usas fourspriter, no te tienes que preocupar por esto porque los sprites se borran con lo que hubiera originalmente en la pantalla, así que con asegurarse de que esté controlado el color tienes suficiente.

[na_th_an]

Creo que tu problema es con el valor con el que estás comparando. Un cuadro de tinta verde y papel negro tiene atributo 4, no 0. El atributo se calcula como ink + paper*8 + bright*64 + flash*128. Mira a ver si es esto.

O sea, es lo segundo que dices, ahora que leo más despacio.

Hay que tener mucho cuidado, si usas detección por atributos, con las tintas "que no se ven". Aunque haya un espacio, si es un espacio con tinta amarilla, por ejemplo, el atributo leído será 6.

Yo lo que hacía en tiempos era asegurarme de que siempre que desplazaba algo lo borraba usando un espacio con tinta 7 papel 0, con lo que el atributo "vacío" siempre era "7".

Si usas fourspriter, no te tienes que preocupar por esto porque los sprites se borran con lo que hubiera originalmente en la pantalla, así que con asegurarse de que esté controlado el color tienes suficiente.

[wilco2009]

Insisto en que la función attr funciona bien. El warning es feo pero anecdótico.
Prueba el siguiente código:

Código: Seleccionar todo

prueba de attr
#include once <attr.bas>
#include once <input.bas>

dim x,y,a as ubyte

a = 0
for y = 0 to 22
   for x = 0 to 31
      poke 22528+CAST(integer,y)*32+x,a
      print at 20,10;Attr(y,x);"     ";a; "       "
      t=Input(10)
      if a = 255 Then 
         a = 0
      else 
         a=a+1
      end if
   next x
next y

@na_th_an: Por cierto, la función de na_th_an tiene un problema de desbordamiento en la operación (y << 5) para y mayor que 8, ya que el compilador considera esa parte del cálculo como un número de tipo ubyte. Me ha costado un ratillo hasta averiguar porque no me funcionaba.
Igual es otro el problema pero es la única manera que me ha funcionado.

[Alxinho]

Gracias chicos, pero al final he usado arrays calculando la posición del muñeco. Me daba palo hacerlo así pero en el fondo es mejor. Gracias de todos modos

[anjuel]

Gracias chicos, pero al final he usado arrays calculando la posición del muñeco. Me daba palo hacerlo así pero en el fondo es mejor. Gracias de todos modos

No sabes las ganas que tengo de ver qué estás perpretando! miner'o'man?

[na_th_an]

@na_th_an: Por cierto, la función de na_th_an tiene un problema de desbordamiento en la operación (y << 5) para y mayor que 8, ya que el compilador considera esa parte del cálculo como un número de tipo ubyte. Me ha costado un ratillo hasta averiguar porque no me funcionaba.

Cierto, y esto no debería ser así. Algún día lograré convencer a Boriel de que cambie este comportamiento. En ningún otro de los compiladores para cualquier lenguaje y para cualquier plataforma el comportamiento es el mismo, y por eso siempre meto la gamba. En todos sitios se hace type promotion para que los operandos tengan, al menos, el tamaño del tipo resultado. Si Peek espera un entero de 16 bits, lo que haya entre paréntesis debería ser automáticamente promocionado a 16 bits.

Para que funcione hay que sustituir por Peek (22528 + x + (Cast(uInteger, y) << 5)).

[Alxinho]

Gracias chicos, pero al final he usado arrays calculando la posición del muñeco. Me daba palo hacerlo así pero en el fondo es mejor. Gracias de todos modos

No sabes las ganas que tengo de ver qué estás perpretando! miner'o'man?

Jejejeje ... Tío! Cómo me alegro de escribirte!

Pues la verdad es que no, del Mineroman tengo poco hecho, nada más que el muñeco moviéndose, dando cuchillás y unos pocos de sprites de enemigos y eso, pero poco. Preferí meterme con el que estoy haciendo que es más bien un juego de "practicas", un compendio de cosas que me obligan a practicarlo todo, los charsets, sprites, animaciones, mapeado, texto, etc, etc ... todas esas cosas de tutoriales de Nathan, Microbasic y de donde alla pillado. Es que sino el Mineroman iba a ser inviable. Este es muy fácil y me hace familiarizarme con el maravilloso compilador éste cruzado.

El juego de "practicas" se llama (al menos de momento) Simulador de guerra mundial o World war simulator jajaja ... es una mezcla de cosas ... arcade, quiz, aventura conversacional (rollo Cobra's Arc y libro elije tu propia aventura), etc ... el problema más gordo que estoy teniendo es que joder! le metes tres líneas de código y ya te sube 1 puto kilobyte! No sé si me cabrá todo lo que pienso hacer ... sino tendre que cortar huevos



Un abrazo enorme!

[Ivanzx]

Joder, pues menuda pinta para ser tu primer proyecto!!

[Alxinho]

Coño ... gracias nen ...

[wilco2009]

La verdad es que tiene muy pinta el juego.
Esperamos ver pronto el fruto de tu esfuerzo.

Yo estoy intentando hacer una aventura gráfica basada en el Hobbit, mezcla entre Saimazoom y aventura tipo SpaceQuest o Monkey Island. No estoy seguro que llegue a buen puerto, porque estas cosas requieren dedicarles bastante tiempo y yo no ando muy sobrado de esto, pero bueno, mientras tanto me entretengo llevando a la práctica los tutoriales de na_th_an mediante la programación de dicho juego.