Regiones y posicionamiento

[GINO]

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.

[SplinterGU]

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:

define_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.

LOCAL 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.

[SplinterGU]

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.

[GINO]

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.

[SplinterGU]

No le veo mucho sentido... y porque no lo pones directamente sobre la pantalla?

[GINO]

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.

[La momia que fuma]

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)

[SplinterGU]

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.

[HaCkZJuaNN]

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...

[SplinterGU]

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

[GINO]

Bueno basicamente lo proponia por comodidad.

Por cierto hay alguna forma de saber las coordenadas y dimensiones de una region una vez definida?

[izubiaurre]

Creo, que directamente no. Como en todo se deben usar caminos indirectos. Por ejemplo:

Code Select Expand


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.

[izubiaurre]

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.

[syous]

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

[SplinterGU]

Pero las regiones no se crean solas, uno sabe cuando crea una region su tamaño...