He decidido dejar el hilo de ''socorrooooooooo'' para pedir ayuda y cambiarlo por este, que lo llevaré paralelo con uno que haré en proyectos para comentar los avances...
-Primer problema:
estoy usando el tile studio para el mapeado del juego, ¿como vá en el juego? importar map o algo de eso???
¿que libreria me hace falta??
otra cosa que me está dando calor es los modulos, pongo el include y no lo reconoce...
por cierto, estoy haciendo un juego al estilo frogger...
INCLUDE tienes que ponerlo después de PROGRAM, prácticamente puedes ponerlo en cualquier sitio siempre que sea después de PROGRAM.
En cuanto al tile studio no tengo idea... Si te genera una imagen puedes meterla en un fpg y cargarla con start_scroll o similar.
Depende de cómo exportes con el tile studio: si exportas en mapa de bits (bmp, png, pcx...) tendrás que manejarlo como si fuera un mapa (o bien lo cargas con LOAD_PNG, o usas la image.dll para cargar otros formatos, o la pasas a MAP o FPG), lo cual, en mi opinión personal, es una tontería, porque para eso te dibujas el mapa a mano, no ahorras memoria ;D
Si lo exportas como mapa de tiles, tendrás que conocerte el fichero de salida, o sea, qué significa cada dato, cargarlo a mano con las funciones de ficheros, y crearte tu propio motor de scroll tileado.
Es por eso que subí el que hice yo, para ahorraros ese trabajo, aunque los formatos que soporta no son compatibles, pero es fácil crearte tu propia función de carga (sólo tienes que rellenar los datos de una variable tipo t_mapa).
Sería muy interesante poder disponer de funciones de carga para los principales formatos del tile studio y del mappy (tambien crear un módulo para bennu de scroll tileado ^^U, si tuviese tiempo...).
en el .prg del juego pongo:
include "carpeta/modulo.prg";
y al ejecutarlo en .bat me dice que me dá error en el punto y coma...
se lo quito y tampoco >:(
corregido, no tenia la ruta correcta...
cachis...
y en el apartado de mapa; analizando el juego, se trata de la rana que se mueve por toda la pantalla pero no llega a salir de los bordes, y cada paso de pantalla es un fondo distinto definido por una variable...
¿que me saldria mas ''rentable''?
-Hacer unas 30 pantallas que dura el juego e ir cambiando el graph correspondiente ??
-O por el contrario hacer una pantalla gigantesca donde se muestre la porcion correspondiente donde se encuentra??
esta ultima me parece absurda ya que el juego carece de scroll, ni siquiera tipo ''zelda'' aunque puede que haga algo parecido mezclado con fade... eso ya se verá con el tiempo
al grano: mejor muchos graph intercambiables en el mismo proceso o un graph inmenso indicando la posicion????
No se, pero este tipo de proyectos es mejor hacerlos usando tiles, no mapas gigantescos.
Por ejemplo, tienes un fpg de 1000 graficos de 32,32 pixeles y un mapa ,(fase 1, fase 2,etc), se construye con una combinación de éstos usando un archivo propietario para relaccionarlos, por ejemplo un archivo de texto que ponga esto:
ANCHO
ALTO
INDICE DEL PRIMER GRAFICO
INDICE DEL SEGUNDO GRAFICO
INDICE DEL TERCER GRAFICO
..
INDICE DEL ULTIMO GRAFICO
por ejemplo
3
2
8
4
4
5
5
8
que sería un mapa de 3 (columnas)x2(filas) tiles (de 32x32 pixeles que dijimos antes) donde los índices de los tiles a dibujar para crear el mapa serían
8,4,4
5,5,8
Pues así crearías dinámicamente un graph que sería tu mapa a pintar en pantalla y podrías cambiar facilmente su diseño con solo cambiar en el notepad los datos de lo índices de los tiles y crear infinidad de fases.
Esta técnica se puede complicar hasta la enésima potencia, por ejemplo puedes añadir varias capas de tiles (como crear el fondo para el suelo y las nuves para el cielo) simplemente poniendo en los índices de los tiles una coma y el nuevo tile para la otra capa.
El ejemplo anterior de 3x2 creándole una capa más podría ser este
3
2
8,10
4,10
4,10
5,0
5,0
8,0
Podrías también insertar por ejemplo al archivo, los datos más relevantes del mapa o fase, como podría ser el título del mapa, quedando
Nivel 1. Carrera por la autopista
3
2
8,10
4,10
4,10
5,0
5,0
8,0
Podrías también insertar la posición inicial de los enemigos de la fase y de la rana.
Hay formatos ya creados para estos menesteres muy avanzados y muy complejos como podría ser mapy.
Yo haría un mapa por cada pantalla (salvo que quieras poner nubes, niebla, lluvia...) siempre que no tengas problemas de RAM.
El usar tiles te ahorra mucha memoria en los FPGs pero el usar mapas te permite que los escenarios no sean "repetitivos", así que elige tú mismo.
En tu caso, hasta podrías prescindir de los mapas de tiles y usar arrays de dos dimensiones para colocar los tiles, pero si quieres que se pueda editar o añadir deberías usar ficheros, aunque sea un formato que consista en x*y bytes con los valores de los tiles, sin cabecera ni nada :)
Por cierto ¿conoceis los formatos de salida del mapy? sería interesante añadirlos a mi motor, porque busqué en su día y no hay información si no lo instalo.
No entendí a que te refieres con maps, drumpi.
Yo quise exponer que en vez de usar una imagen png de fondo con el mapa ya creado para cada fase que usara una composición de imágenes para crear un mapa en tiempo de ejecución, pero que este mapa ya esté definido siempre para cada fase en un fichero de texto.
No me refería en ningún caso a hacer mapas dinámicos como hace diablo.
Lo que me refiero es que, para una pantalla estática, lo más normal sería usar un mapa del tamaño de la pantalla, previamente prediseñado.
Si no, lo que tu dices, componer el fondo a base de tiles, pero para colocar esos tiles necesitas la información de dónde y cual tile colocar, que es lo que se conoce como "mapa de tiles" (al menos, yo lo llamo así). Vamos, un fichero que contiene un array de dos dimensiones con los números de los gráficos a colocar en cada posición.
Pero que en lugar de ficheros, puede usar un array en memoria.
ok
usaré mejor un mapa por pantalla para el mismo proceso...
por otro lado, para la transacion entre pantallas es mejor usar un fade ¿no?
¿como van?
no entiendo a que te refieres con usar un mapa por pantalla para el mismo proceso.
¿A pantalla te refieres a fase? porque un mapa por fase es lo normal en los juegos, a no ser que sea un rpg y tengas el mapa del mundo y varios mapas de ciudades o casas o bosques que juntos formarian la fase 1.
O a mapa te refiera a imagen. es decir una imagen prediseñada y construida de digamos 800x600 por fase.
en cuanto a tu pregunta de usar fade, pues usar fade es mejor que qué otra cosa. Mas que mejor o peor yo diría que si te gusta más o menos hacer una transición gradual desde tu mapa a una pantalla en negro o un cambio brusco o crearte tu propio efecto, por ejemplo un efecto cortina como en la intro de mario bross 3 en el que se ve una pantalla y derrepente aparece una cortina que se va cerrando y tapa la pantalla.
Fade es lo mejor, puedes hacer un fundido a negro (fade(0,0,0,x)), a "encendido" (fade(100,100,100,x)) a rojo (fade(200,100,100,x)), a amarillo (fade(100,200,200,x)) o al color que quieras, incluso efectos muy curiosos con, por ejemplo, fade(100,0,0,x).
Ojo, X es la velocidad, tienes que poner un valor entre 1 y 255. Pero tiene un problemilla, que es lo que comentaba el otro día en otro hilo: la velocidad más lenta de fade te hace el fundido en 64 frames, por lo que si quieres que vaya más lento tienes que cambiar los FPS.
Otros métodos son más lentos y costosos en recursos, y son menos suaves.
el valor (fade(0,0,0,x)) se llega automaticamente o hay que ponerlo con un contador que vaya sumando poco a poco hasta llegar al apropiado...
Quote from: DCelso on February 12, 2010, 04:48:57 PM
no entiendo a que te refieres con usar un mapa por pantalla para el mismo proceso.
¿A pantalla te refieres a fase? porque un mapa por fase es lo normal en los juegos, a no ser que sea un rpg y tengas el mapa del mundo y varios mapas de ciudades o casas o bosques que juntos formarian la fase 1.
O a mapa te refiera a imagen. es decir una imagen prediseñada y construida de digamos 800x600 por fase.
en cuanto a tu pregunta de usar fade, pues usar fade es mejor que qué otra cosa. Mas que mejor o peor yo diría que si te gusta más o menos hacer una transición gradual desde tu mapa a una pantalla en negro o un cambio brusco o crearte tu propio efecto, por ejemplo un efecto cortina como en la intro de mario bross 3 en el que se ve una pantalla y derrepente aparece una cortina que se va cerrando y tapa la pantalla.
muy facil, la rana se vá a mover por la pantalla sin salirse (creo que eso es un motor de movimiento de personaje, o asi lo llamais); osea que para mi juego tengo la opcion de mover al personaje dentro de una ''rejilla'' de 8 x 6, osease que en la pantalla de la wiz (por ejemplo) tengo 48 posiciones posibles de mi personaje...
desliemonos: mi personaje, la rana, solo puede moverse dentro de un area, no puede salir de lo que es la pantalla o zona de juego (320 x 240) y mientras tanto hay que ponerle un fondo, pues ese fondo cambiara segun el nivel del juego o fase, dando como resultado un 'pseudo - zelda' de nintendo 8-bit en cuestion de mapeado.
al final pondré una seccion del mapa total de fondo de cada fase, no haré un mapa grande sino cada fase por separado
'-' tocho post '-' ^^U
con los modulos sigo teniendo problems, pongo un .prg con una variable global que me valga para todos los demas .prg y no me lo reconoce, ¿sera que solo hay una variable???
Solucinado: hay que ponerlas en orden, primero lo importante o variables y despues lo demas...
que lastima que por una pamplina como esa raye tanto
El parámetro 4 indica la velocidad, lo cual debería darte una pista de que si, es automático, y mientras se está ejecutando, se pone la variable global predefinida FADING a true, al acabar vale false (muy útil para hacer un bucle de espera del fade:
while (fading) frame; end
).
Lo de las globales es eso: que si pones el include antes es como si no se hubiera declarado en ese fichero. Pasa lo mismo con las locales y creo que tambien pasa (o al menos pasaba) con procesos y funciones, pero yo no he tenido problemas con eso.
La mejor solución es que si vas a modularizar usando include, crees archivos (por ejemplo ".inc") con el código y otro con las variables globales y locales y tipos que va a declarar (llámalo por ejemplo ".h").
Luego, al escribir el código, escribes la línea PROGRAM, sigues con los tipos generales, incluyes los .h, defines las globales y locales del programa, incluyes los .inc y ya los procesos y funciones del propio prg. Así todas las variables y tipos definidos podrán ser usados en cualquier parte del programa.
gracias por lo pron...
puede un proceso hacer el break en otro???
o tendria que poner una variable en true para ''breakar'' el proceso o procesos...
Break sólo rompe el bucle en el que está escrito, no tiene sentido lo que dices.
Si lo que quieres es que otro proceso salga de un bucle o un estado, tendrás que indicárselo de alguna forma, cambiando su estado (mediante una variable, ya sea global, local o pública), matándolo (on_exit) o congelándolo y haciendo el resto de operaciones desde otro proceso.
También ten en cuenta que cuando A colisiona con B, B colisiona exactamente igual con A en el mismo frame (si no se cambian sus coordenadas), te lo digo a modo de ejemplo.
si, todavia me quedan las colisiones...
pero por lo pront, tengo otros interrogantes entre manos; crear el mismo proceso varias veces en posiciones distintas y con distintos graph, al hacerle un break a los (por ejemplo) cuatro, rompe el loop de los cuatro a la vez?????
seguire indagando...
No, el break sólo funciona de forma "privada", rompe el bucle en el que está, no el de otros procesos, como te he dicho antes.
Y no te tomes lo de colisión textualmente: lo que digo es que si A está a x pixels de B, B también está a x pixels de A, por lo que en lugar de buscar que A actúe sobre B puedes hacer que A actúe y B actúe, cada uno por su cuenta.
pues entonces es lo que tenia entendio, siempre que usaba colisiones mandaba al otro lo que tiene que hacer el uno, para no sobrecargarlo de acciones...
Creo que Splinter se refiere a este,
http://forum.bennugd.org/index.php?topic=1149.msg17259#msg17259
Se usa parecido a signal (http://wiki.bennugd.org/index.php?title=Signal), pero para guardar el estado de todos los procesos implicados.
bueno, no nos olvidemos de lo que queria: crear el mismo proceso en varios lugares y con distintos graph...
segun el tema 17 Parametros, me dice que ponga entre parentesis unos parametros para cuando lo ejecute...
pues entonces probaré con
process cosa(x,y,graph) y con
process cosa(int x,int y,int graph) a ver cual funciona y lo comento
probar y probar y probar y probar y probar y probar y probar y probar y probar y probar y probar
ok, hay que declarar el dato, osea el:
process cosa(int x,int y,int graph)
El INT no es necesario en este caso: los parámetros son tomados como INT por defecto, pero si vas a usar otros tipos (BYTE, WORD, punteros...) sí que es necesario.
A ver si se te ha olvidado meter la mod_video, que es donde están definidas las variables x,y,graph, etc (tal y como me apuntó SplinterGu en otro post :D) y por eso has necesitado poner "int", ya que poniendo "int x" defines una nueva variable x y por eso te va.
La verdad es que para mí, lo mas comodo cuando empiezo un programa nuevo, es usar un include que carga TODOS los modulos existentes. Así me evito problemas de que falta uno u otro modulo.
Cuando he finalizado el proyecto u estoy depurando para conseguir mas RAM o mejor rendimiento si que me dedico a eliminar los modulos que no utilizo.
Imagino que a base de experiencia uno aprende para que sirve cada modulo de memoria.
Saludos!
Quote from: DCelso on February 16, 2010, 03:34:09 PM
A ver si se te ha olvidado meter la mod_video, que es donde están definidas las variables x,y,graph, etc (tal y como me apuntó SplinterGu en otro post :D) y por eso has necesitado poner "int", ya que poniendo "int x" defines una nueva variable x y por eso te va.
pos nol, lo que pasa que para definir otra vez la x, y + graph, le doy unas variables nuevas y la asigno en el proceso
Quote from: Drumpi on February 16, 2010, 01:47:07 PM
El INT no es necesario en este caso: los parámetros son tomados como INT por defecto, pero si vas a usar otros tipos (BYTE, WORD, punteros...) sí que es necesario.
BYTE es de 0 hasta 255 ¿no? insuficiente para el ancho de pantalla pero perfecto para el alto...
¿hay algo mas pequeño que BYTE???
No: byte es la unidad mínima de información que maneja un ordenador (si exceptuamos el bit, pero no tiene nada que ver con lo que estamos tratando). Por encima tienes word (2 bytes) e int (4 bytes). También les puedes añadir prefijos como SIGNED y UNSIGNED: con signed reduces a la mitad el valor máximo a representar, pero ganas los correspondientes negativos.
Otros tipos que conozco son los FLOAT (números con decimales), CHAR (byte que representa un caracter), STRING (cadena de CHARs de tamaño variable) y POINTER (punteros). No sé si me dejo alguno.
hablando de tipos de datos
STRING tiene algun limite en la cantidad de caracteres???
No estoy seguro, pero creo recordar que había una limitación a 256 o 512 caracteres, pero no me hagas mucho caso, lo mismo es una "clase" que maneja un puntero y puede tener tantas letras como quieras.
no tienen limites.
entonces si nombro una variable con byte y empiezo a darle valor...
¿hasta cuanto llegaré???
Quote from: Futublog on February 17, 2010, 07:05:59 PM
entonces si nombro una variable con byte y empiezo a darle valor...
¿hasta cuanto llegaré???
byte es un byte ( q mal que suena eso :P)
entonces va desde 0 a 255...
en el manual de Osk estan los limites de los datos numericos...
pero el de los string kreo q no :P
Si string no tiene límites, entonces la única limitación es que cada letra sólo puede tener un valor entre 0 y 255, se supone (que son los valores ASCII).
El representar caracteres cirílicos y kanjis queda fuera del alcance ;D (tengo curiosidad por saber cómo se representan binariamente en otros sistemas)
Quote from: Drumpi on February 17, 2010, 08:18:24 PM
Si string no tiene límites, entonces la única limitación es que cada letra sólo puede tener un valor entre 0 y 255, se supone (que son los valores ASCII).
El representar caracteres cirílicos y kanjis queda fuera del alcance ;D (tengo curiosidad por saber cómo se representan binariamente en otros sistemas)
todo se representa binariamente de igual manera: o es cero o es uno XD
bueno un conjunto de unos y ceros...
supnogo que la clave esta en al codificacion unicode (UTF-x)
drumpi, el modulo que habia para imprimir en unicode no te dara una pista??
Quote from: Rein (K´)ah Al-Ghul on February 17, 2010, 07:20:39 PM
Quote from: Futublog on February 17, 2010, 07:05:59 PM
entonces si nombro una variable con byte y empiezo a darle valor...
¿hasta cuanto llegaré???
byte es un byte ( q mal que suena eso :P)
entonces va desde 0 a 255...
en el manual de Osk estan los limites de los datos numericos...
pero el de los string kreo q no :P
le eché un vistazo antes de preguntar, porque lo habia visto en algun lado...
tendré que mirar mas a fondo porque no lo vi
Quote from: Rein (K´)ah Al-Ghul on February 17, 2010, 09:40:42 PM
Quote from: Drumpi on February 17, 2010, 08:18:24 PM
Si string no tiene límites, entonces la única limitación es que cada letra sólo puede tener un valor entre 0 y 255, se supone (que son los valores ASCII).
El representar caracteres cirílicos y kanjis queda fuera del alcance ;D (tengo curiosidad por saber cómo se representan binariamente en otros sistemas)
todo se representa binariamente de igual manera: o es cero o es uno XD
bueno un conjunto de unos y ceros...
supnogo que la clave esta en al codificacion unicode (UTF-x)
drumpi, el modulo que habia para imprimir en unicode no te dara una pista??
¿Hay un módulo con unicode? Sólo me suena la iconv para estandarizar el set de caracteres de Bennu (por el tema de que se usan dos set distintos: la fnt interna usa el antiguo y los fnt que se cargan el moderno y suelen salir caracteres raros) y la mod_ttf de sandman para fuentes con suavizado y carga de otros formatos.
Futublog, la tabla con los tipos de datos y limites esta por la pagina 26 de la numeracion de las hojas (34, segun el visor de pdf)
QuoteBYTE Almacenan valores numéricos enteros que pueden valer entre 0 y 255. Estos valores extremos también
se pueden expresar con las constantes MIN_BYTE y MAX_BYTE,respectivamente.
Una variable de este tipo necesita 8 bits de memoria (sin signo y sin coma decimal) para almacenar ese
valor.
Drumpi:
la libreria que permite usar otros caracteres ademas de los ascii:
http://forum.bennugd.org/index.php?topic=690.0 (http://forum.bennugd.org/index.php?topic=690.0)
ok, ya lo he revuelto a recomprobar, las variables bytes no son muy fiables, en especial para x e y o cualquier valor menor de 255...
para los colores vá a tuti plen, pero una cosa que no consigo hacer es que el fade me lo haga a un grafico determinado y no a todo el juego, de todas formas indagaré como darle valor RGB a los procesos para simular el fade
como que los bytes no son fiables para valores menores de 255? los bytes no pueden manejar valores mayores a 255 y tampoco negativos.
No puedes provocar un fade a un proceso en concreto ¿eso cómo sería? ¿se va volviendo cada vez más negro? ¿o quieres que desaparezca poco a poco? para la segunda opción tienes la variable local predefinida ALPHA (lo que se puede llegar a decir con sólo 4 palabras :D).
Si lo que quieres es convertirlos a una escala de color determinada, busca cómo funciona rgb_scale... o algo así se llamaba.
claro, asi oscurezco el fondo y todo lo que no sea la rana, para el cambio de pantalla...
Quote from: SplinterGU on February 20, 2010, 09:14:39 PM
como que los bytes no son fiables para valores menores de 255? los bytes no pueden manejar valores mayores a 255 y tampoco negativos.
para mi no, intenté ponerlos en coordenada de posicion (la equis vamos) y me lo puso donde le pareció, entonces decidí usarlo solo para contadores o demas cositas que no dependa de un numero mu grande
por cierto que los colores RGB van del negro 0,0,0 al blanco 255,255,255 ¿no?
Quote from: Futublog on February 21, 2010, 09:58:55 AM
claro, asi oscurezco el fondo y todo lo que no sea la rana, para el cambio de pantalla...
Quote from: SplinterGU on February 20, 2010, 09:14:39 PM
como que los bytes no son fiables para valores menores de 255? los bytes no pueden manejar valores mayores a 255 y tampoco negativos.
para mi no, intenté ponerlos en coordenada de posicion (la equis vamos) y me lo puso donde le pareció, entonces decidí usarlo solo para contadores o demas cositas que no dependa de un numero mu grande
por cierto que los colores RGB van del negro 0,0,0 al blanco 255,255,255 ¿no?
Depende del modo de pantalla. En 24 bits sería así pero no existe en bennu.
en 8 bits se usa paleta de color así que sería mas lioso explicarlo, pero la paleta guarda los colores como en modo 16 bits.
en 16 bits es 32,64,32 que viene de 5 bits para R,6 bits para G, 5 bits para B = 16 bits
en 32 bits es 255,255,255,255 que viene de 8 bits para 8,8 bits para G, 8 bits para B, 8 bits para alfa = 32 bits
Esto ya se ha explicando unas cuantas de veces, busca posts si quieres más info, o en wiki de bennu y fenix.
Para oscurecer todo lo que no sea la ranita, la única solución es crear un gráfico del tamaño de la zona de juego, usar map_clear con el color 1 con ella, poner la ranita por encima de todo, y este nuevo gráfico+proceso justo por debajo, y hacer que su alpha vaya de 0 a 255.
Creo que RGB se adaptaba al modo gráfico ¿no? es decir, que en modo 8bits devolvía el valor de la paleta más cercano al que se busca, mientras que en 16 busca el equivalente (5,6,5). Al menos, así lo recuerdo.
Quote from: Futublog on February 21, 2010, 09:58:55 AM
claro, asi oscurezco el fondo y todo lo que no sea la rana, para el cambio de pantalla...
Quote from: SplinterGU on February 20, 2010, 09:14:39 PM
como que los bytes no son fiables para valores menores de 255? los bytes no pueden manejar valores mayores a 255 y tampoco negativos.
por cierto que los colores RGB van del negro 0,0,0 al blanco 255,255,255 ¿no?
creo que todo surgio por que habias dicho "las variables bytes no son muy fiables, en especial para x e y o cualquier valor menor de 255...", creo que ahi te confundiste y deberias haber dicho "que no son fiables para cualquier valor MAYOR de 255".
La cosa es que decir que no es fiable no es correcto, porque da a entender que tiene un comportamiento erratico... y la correcto es decir "NO SIRVE PARA...". Creo que vale mencionar que el hecho de que si le seteas a una variable BYTE un valor que va mas alla de sus limites, pone algun valor que en teoria no es correcto, se debe a que solo se setea parte de dicho valor, la parte (a nivel bits) que corresponde al tamaño del mismo... o lo que es lo mismo en el caso de byte a: valor & 0ffh = valor & 255 = valor BAND 255
import "mod_say";
private
byte a;
begin
a = 257;
say ( a ) ;
say ( 257 & 0ffh );
a = 300;
say ( a ) ;
say ( 300 & 0ffh );
end
pero repito, decir que algo no es fiable, es dar a entender que no se comporta como debe.
solo queria aclarar eso, para no crear futuras confusiones... por favor disculpame si no fui claro desde el inicio...
DCelso, los rgb van de 0 a 255 indistintamente al modo de video, lo que si es cierto es que segun el modo de video se pierde precision... con esto que quiero decir? quiero decir que por ejemplo (atencion que los valores que mencionare son a modo de ejemplo, puede que no sean exactamente esos) si tu haces un set a un rgb( 1, 1, 1 ) en modo 16 bits, lo mas probable es que eso realmente se convierta en un rgb(4,4,4) o un rgb(0,0,1); o un set a un rgb(253,253,253) realmente se traduzca en un rgb(255,255,255). No se si logro explicarlo, se pierde precision... pero el comportamiento de las funciones RGB es trabajar con valores 0 a 255, con mas o menos precision.
todo cierto, splinter, gracias por la aclaración, yo no me expliqué bien.
Quote from: SplinterGU on February 21, 2010, 08:26:57 PM
creo que todo surgio por que habias dicho "las variables bytes no son muy fiables, en especial para x e y o cualquier valor menor de 255...", creo que ahi te confundiste y deberias haber dicho "que no son fiables para cualquier valor MAYOR de 255".
La cosa es que decir que no es fiable no es correcto, porque da a entender que tiene un comportamiento erratico... y la correcto es decir "NO SIRVE PARA...". Creo que vale mencionar que el hecho de que si le seteas a una variable BYTE un valor que va mas alla de sus limites, pone algun valor que en teoria no es correcto, se debe a que solo se setea parte de dicho valor, la parte (a nivel bits) que corresponde al tamaño del mismo... o lo que es lo mismo en el caso de byte a: valor & 0ffh = valor & 255 = valor BAND 255
pero repito, decir que algo no es fiable, es dar a entender que no se comporta como debe.
solo queria aclarar eso, para no crear futuras confusiones... por favor disculpame si no fui claro desde el inicio...
el que no fuí claro fuí yo, queria decir que solo las usaré para cosas pequeñitas, ya que la fiabilidad no es muy fiable, je je je
edito: solucionado, je je
te quedo la respuesta quoteada...
umm, oh, bonito palabro. ;D
se dice asi...
bueno bueno bueno, despues de dejar esto un poquito abandonao y querer crear un juego de una tarde...
Un tal señor Drumpi (al que admiro por cierto) me ha incentivado a seguir con el juego de los caracoles (tambien ha contado las opiniones del susodicho juego llevado a concurso... ^^U je je) y he decidido ampliarlo, terminarlo y, o complementarlo. Para ello tambien pongo una serie de dudas que practicamente son totalmente compatible con el juego de la ranita que llevaré paralelamente...
El primer problema es el tema 2x scale o full screen famoso, no se como tengo que ''sentenciarlo''
el 2º y no por ello mas facil, la declaracion de las funciones y sus funciones, valgan la rebundancia, donde pueden ser declaradas y si pueden ir en un modulo a parte o dentro de cualquier otro, si son publicas o no o si esto ultimo no tiene nada que ver mas que confundirme
gracias