Bueno este es un detalle que ya habia visto en Fenix y que como otras cosas no se si es intencionado.
Se trata de las regiones. En un principio me imaginaba que si un proceso esta en una region determinada sus coordenadas estarian en funcion de dicha region, osea el punto 0,0 seria la esquina superior izquierda de la region, sin embargo las coordenadas responden a la pantalla ya este el proceso en una region determinada o no:
[code language="bennu"]IMPORT "mod_draw"
BEGIN
graph = new_map(32, 32, 8);
drawing_map(0, graph);
drawing_color(15);
draw_box(0, 0, 32, 32);
set_center(0, 1, 0, 0);
define_region(1, 100, 50, 220, 150);
region = 1;
//x = 100;
//y = 50;
REPEAT frame; UNTIL (key(_esc))
END[/code]
En ese ejemplo queda claro, si descomentamos las lineas donde se asigna x e y el proceso se situa en la esquina superior izquierda de la region 1, pero claro no es 0,0.
Yo creo que las coordenadas deberian atender a la region, es decir, que el origen de coordenadas de una region este en su esquina superior izquierda.
No entiendo que decis... pero las regiones son solo visualizacion... las coordenas siempre actuan en base a la pantalla, no en base a la region... la region es solo la region de visualizacion... hacerlo de otra forma seria absurdo e ilogico...
Veamos mejor la definicion del help de DIV:
Quotedefine_region()
define_region(<número de región>, <x>, <y>,<ancho> ,<alto> )
Descripción:
Define una nueva región de visualización dentro de la pantalla (algo así como una ventana). Las regiones son zonas rectangulares de la pantalla dentro de las cuales se visualizarán unos determinados procesos, ventanas de scroll o de modo 7.
El número de región debe ser entre 1 y 31. Se pueden definir hasta 31 regiones diferentes de pantalla que después podrán asignarse a diferentes procesos (fijando su variable local region al nuevo número) como su ventana de visualización, o bien utilizarse como marco para una ventana de scroll o de modo 7 indicándolo en el parámetro correspondiente de las funciones start_scroll() o start_mode7().
La región número 0 no se debe redefinir, pues será siempre la pantalla completa, una ventana en las coordenadas (0, 0) y del ancho y alto de la pantalla. Esta es la región en la que se visualizarán por defecto todos los procesos, ya que su variable local region siempre vale 0 por defecto.
QuoteLOCAL region
region=0; // Región de pantalla asignada al proceso
--------------------------------------------------------------------------------
Esta variable predefinida es LOCAL, lo que significa que cada proceso tendrá su propio valor en su variable region.
La variable local region define en qué zona de pantalla debe ser visible el gráfico del proceso, indicando el número de región.
Una región es una zona rectangular de pantalla, como una ventana, que está asociada a un número.
Por defecto, esta variable valdrá 0 en todos los procesos haciendo referencia a la región número 0 que es la pantalla entera.
Es decir, que por defecto los gráficos de los procesos serán visibles en toda la pantalla (en cualquier punto de la misma en el que estén).
En un principio, únicamente está definida la región numero 0. Para definir nuevas regiones de pantalla se debe utilizar la función define_region().
--------------------------------------------------------------------------------
Por ejemplo, para que el gráfico de un proceso fuera visible sólo dentro de una caja de 100 por 100 puntos situada en la esquina superior izquierda de la pantalla (en las coordenadas 0, 0), primero se debería definir la nueva región la siguiente forma, suponiendo que se defina la región número 1:
define_region(1, 0, 0, 100, 100);
y, después, se debería asignar el número de región (1) a la variable local region del proceso con la siguiente sentencia:
region=1;
Las regiones pueden redefinirse en cualquier momento dentro de un programa; esto es, se pueden cambiar de posición o de tamaño siempre que sea necesario.
--------------------------------------------------------------------------------
Nota: El gráfico de un proceso se debe indicar asignando un código de gráfico a la variable local graph.
El comportamiento actual es el correcto.
Eso es abrir un agujero (region) donde poder observar el mundo...
Al asignarle region a un proceso, lo que haces es decirle que este solo se va a ver en el "agujero" especificado, por defecto los procesos se ven en todos los "agujeros", el valor de region es 0.
Ya, me lo suponia. Una especie de clipping. Aun asi, y esto es a modo de sugerencia, no estaria mal que los procesos con una determinada region pudiesen situarse tanto en funcion de la pantalla como de dicha region, para no tener que andar sumandole un offset. Por ejemplo, digamos que tengo mi propio personaje en una region q no sea como la pantalla y que baso los calculos en funcion del borde de la region. Tendre que andar sumandole todo el rato el offset de dicha region para que se muestre correcto.
Bueno igual no se ve muy bien asi contandolo, pero creo que hay casos en los que seria bastante util.
No le veo mucho sentido... y porque no lo pones directamente sobre la pantalla?
Pues precisamente porque usando region tienes la capacidad de clipping. Y sentido yo creo que tiene, para mi incluso mas que el hecho de que las coordenadas sigan siendo las de pantalla. Pero bueno, tampoco he hecho muchas pruebas.
Bueno, si usas scrolls asignados a regiones no tienes ese problema con tal de que asignes los procesos a ese scroll, otra cosa ya sería sin scrolls o con scroll tileado...No me parece mal la sugerencia, siempre y cuando sea opcional, ya que como esta el tema ahora lo veo mucho más útil XD
Lo que si que no se es si hay algun motivo para el límite en el nº de regiones (Pensaba que solo podías usar 9, pero veo en el texto que puso Splinter que son 31 :P, la verdad es que son mas que suficientes, pero aun asi tampoco veo porque están limitadas)
En fenix/bennu, son 10 scrolls, ese es el help de DIV...
Esta limitado, por la sencilla razon de que existe una estructura global llamada scroll para tal fin.
La verdad yo sí que le veo sentido a lo que dice GINO, siempre y cuando se pueda elegir usarlo o no usarlo. Por ejemplo, en un juego tienes en la parte de arriba una barra donde te aparecen los recursos(por ejemplo), y eso ocupa un espacio. Si separas la región del mapa como región aparte y quieres colocar algo justo en la esquina superior izquierda de la pantalla, tienes que andar sumándole el grosor de la barra de arriba. Eso diréis, vaya chorrada, pero luego imagínate que decides cambiar esa barra por otra que te parece más bonita pero que es más gruesa, ya tienes que andar tocándo todas las coordenadas que habías puesto antes y eso es un incordio. Lo que propone GINO a mi se me ocurriría resolverlo utilizando una local que sea como... region_origin_x y region_origin_y (no se si existe algo parecido ya que nunca uso regiones). En ese caso solo tendrías que poner: x = 0+region_origin_x ; y = 0+region_origin_y. Claro que esto también lo podrías hacer tú dentro de tu programa...
no, no tienes que sumarle nada...
le pones a ese proceso como usar scroll y c_type = c_scroll. Aunque esa area no tenga scroll ya tienes lo que quieres.
Por otro lado, hacer esos cambios...
1) agregar variables para tal fin
2) meter logica en el binario
3) meter una complicacion a todo el uso de esto
es mas complicado que hacer un simple x + inicio_areax e y + inicio_areay
Bueno basicamente lo proponia por comodidad.
Por cierto hay alguna forma de saber las coordenadas y dimensiones de una region una vez definida?
Creo, que directamente no. Como en todo se deben usar caminos indirectos. Por ejemplo:
int reg_1_x0, reg_1_y0, reg_1_x1, reg_1_y1;
(..)
define_region(1, reg_1_x0, reg_1_y0, reg_1_x1, reg_1_y1);
(...)
Aunque no estaría mal poder tomar las coordenadas de una región sin tener que usar caminos alternativos y en muchos casos sería útil. Como por ejemplo, cuando debes posicionar procesos/gráficos según las coordenadas-frontera de una región.
Una cosa más ya que estamos con regiones y peticiones. Sería interesante y con muchos usos diferentes tener funciones gráficas aplicadas a regiones; que sólo se vean sus efectos en la/s region/es que se quiera aplicar. Esas funciones gráficas podrían ser fade, fade_on, fade_off, roll_palette (estas se me ocurren de momento) y en sus versiones para región:
- Fade() -> Fade_region(num_region, valor1, valor2, valor3, velocidad)
- fade_off() -> fade_off_region(num_region)
- fade_on() -> fade_on_region(num_region)
- ...
Con estas funciones efectos de relámpagos, oscuridad, fade parciales de pantalla (no se ocultaría el interfaz), cambios de tonalidad en la región (tales como: simular noche, amanecer, ...) serían posible.
Quote from: izubiaurre on October 24, 2007, 07:41:55 AM
Una cosa más ya que estamos con regiones y peticiones. Sería interesante y con muchos usos diferentes tener funciones gráficas aplicadas a regiones; que sólo se vean sus efectos en la/s region/es que se quiera aplicar. Esas funciones gráficas podrían ser fade, fade_on, fade_off, roll_palette (estas se me ocurren de momento) y en sus versiones para región:
- Fade() -> Fade_region(num_region, valor1, valor2, valor3, velocidad)
- fade_off() -> fade_off_region(num_region)
- fade_on() -> fade_on_region(num_region)
- ...
Con estas funciones efectos de relámpagos, oscuridad, fade parciales de pantalla (no se ocultaría el interfaz), cambios de tonalidad en la región (tales como: simular noche, amanecer, ...) serían posible.
interesante y util
Pero las regiones no se crean solas, uno sabe cuando crea una region su tamaño...
Jua... pero fade trabaja sobre la paleta no tiene sentido lo que se pide, si, es interesante, pero la paleta es la paleta...
Si bien en 16 bits quizas se podria simular algo, en 8 bits seria imposible.
La idea del fade es apagar la pantalla entera, creo que ahi hay que hacer otra cosa...
Temía esa respuesta, pero, recuerdo que en juegos de 8 bits se hacían fades de regiones. Ahora mismo e acuerdo de "Indiana Jones and The fate of Atlantis" y "Simon the Sorcerer". Había zonas en el que al pulsar un interruptor la región del juego (no la interfaz) se oscurecía paulatinamente y si pulsabas de nuevo se encendía. Eso ocurría en las excavaciones de Argel y a la entrada de la Atlántida [mode añoranza on] ¡Juegazo! [/mode añoranza off].
El fade zonal, se podria hacer con un proceso que tubiera un grafico en negro tan grande como la region a la que se quiere hacer el fade, al empezar ese proceso tendria la maxima transparencia, y progresivamente su transparencia se disminuyendo hasta que este se volviera totalmente opaco, la z de este tendria que se lo sufientemente alta para que tapara todo lo que hubiera debajo de el, creo que seria una buena opcion.
ya, como muchas otras cosas... el problema es por ejemplo:
1 - permitimos la redefinicion de las regiones a los usuarios por medio de un input.
2 - tenemos muchas regiones.
Habria que tener datos auxiliares que almacenen las posiciones de las regiones. Con alguna funcion que nos devuelva esos datos se ahorraria ese paso intermedio. Yo creo que es indispensable alguna forma de detectar esos datos sin tener que estar pendientes de ellos seguido.
Por ejemplo una struct Region
Quote from: izubiaurre on October 24, 2007, 01:47:26 PM
Temía esa respuesta...
Jejeje, me hiciste reir...
Como bien dice kim-elet-o eso se hace con un grafico negro que cubra la region y tenga una Z inferior a todas asi se dibuja ultimo... y con alpha para hacerlo oscurecer o no... asi es como se debe hacer... lo otro es demasiado complejo...
Estamos hablando de cosas que hay metodos alternativos para hacerlo y de forma muy simple...
Ademas mi metodo tiene una ventaja, es que podemos hacer fades de zonas con cualquier tipo de forma, con lo cual imaginaros hacer fades en los monitores de naves alienigenas, o hacer un fade en una zona triangular o circular. Imaginacion al poder.
jojojo! sublime... un grande!!!
Quote from: kim-elet-o on October 25, 2007, 11:03:44 AM
(...) imaginaros hacer fades en los monitores de naves alienigenas, (...)
Tienen monitores los aliens? Seguro que aun usan CRTs...
Quote from: kim-elet-o on October 25, 2007, 11:03:44 AM
(...)Imaginacion al poder.
Y tanto que lo tienes! ;D
Si bien los LCD tambien son monitores, haz dado con la tecla.
Si, lo que sucede es que comprendieron que los LCD son demasiado fragiles, los monitores CRT resisten mejor los impactos, es mas le podes dar un buen golpe con palo y no pasa nada... un amigo me conto que donde trabajaba cuando se tuvieron que deshacer de viejos monitores, lo tiraba desde varios pisos de altura a un volquete (como una caja grande de metal donde se tira basura, que luego viene un camion y se lo lleva)... y le daban contra otras cosas, como impresoras, otros monitores, cosas de metal muy duras, y ni se rajaban, se rompian todo el armazon de plastico, pero los tubos intactos... me conto que le tuvieron que dar con un pico de esos para picar piedras, para solamente hacerle una pequeña rajadura...
Ademas los aliens las prefieron por las emisiones radioactivas (o de rayos catodicos) que estos emiten, que como todos sabemos, los alines gustan de ellas... de hecho cada vez que vienen dejan toda la zona con radioactividad...
Lo que digo, imaginacion al poder, jejejejejejejejejejejejeje, ;D ;D.
¿Como unos seres con una tecnología tan sofisticada para viajar millones de años luz a velocidades hiperestelares aun van a conservar una tecnología tan obsoleta como la emisión de iones controlados por un tubo catódico? es como si aun jugasen al pong :P
Como poco ya usan pantallas holográficas en 3d, y hacen fades de regiones tridimensionales, haciendo que quede un cubo negro en mitad del aire, y los personajes se tiran al cuello del jugador cuando pierden todas las vidas (suponiendo que los señores visitantes de otra galaxia tengan cuello o no sean Fernando Alonso)
Yo quiero unaaaa.
Esos que vos decis son los del cuadrante ZL93-z(otro caracter que no existe en el alfabeto nuestro)#27b(otro caracter inexistente mas) hasta los del quadrante que empiezan con MK(otro caracter inexistente mas)z...
Los que yo digo son los del quadrante GAM3#.(otro caracter inexistente mas)e8x(otro caracter inexistente mas y otro), que son los que suelen visitar el quadrante donde habitamos, estos usan CRT... es un CRT especial, con perforaciones microscopicas en la pantalla, que hace que los rayos catodicos pasen facilmente atraves de la misma. Demas esta destacar que estos aliens son un poco torpes y suelen chocar sus naves, por eso prefieren cosas resistentes (prueba de esto, Caso Roswell).
Esto no debería ir en la sección "Cosas que digo cuando me he fumado 5 porros, tomado 10 pastillas, 3 lsds y metido 3 chutes de cocaína" ???
Jua! eso por donde vivo yo se le dice "calentura" (estas cabronado por lo que puse en el thread del Motor de gravedad...? :D :D :D ;) fue con cariño...)
No creo que haya que cambiarlo. Es triste pero es cierto: no necesito chutarme ni nada para decir esas burradas :(
¿Incluirá Bennu un sistema de caracteres para añadir todos esos que faltan en los alfabetos terrestres? XD
Es cierto que esto tampoco es necesario... se podria implementar eso facilmente haciendo un font que mapee caracteres innecesarios a los que a nosotros nos interesan... como hacian antes los juegos de DOS... y creo que todavia algunos juegos lo hacen...
La pregunta del millon, podes contarnos un poco sobre el proyecto que estas haciendo actualmente que necesitas un caracter de algun alfabeto extraterreste? me intriga mucho saber...
Puedes echarle un ojo a la librería que cree para trabajar con iconv. Con ella puedes utilizar (y convertir) caracteres entre charsets que Fenix/Bennu no soporta. Tiene el inconveniente de que por la forma de trabajar de Bennu. Si estás interesado, te puedo pasar más información (que tampoco es que sea mucha). Luego, como dice Splinter, puedes tener juegos de fuentes (o incluso de bitmaps) con los caracteres que desees tener y con los que escribirás en pantalla los caracteres "extraños". La verdad es que no sé si UTF-8 soporta klingon :)
Jua... creo que ibas a decir algo y te quedo por la mitad...
"Tiene el inconveniente de que por la forma de trabajar de Bennu."
Me quede con la duda, estaba interesante la lectura...