Procesos dedicados a calculo.

[PAMERCO]

yo las funciones las uso asi.
las llamo desde donde sea, un bucle o un proceso, o desde otra función, pero no hago bucle en ellas, es decir, entro en la función, hago el calculo que sea, y salgo de ella, no uso frame, en ninguna función.
para eso utilizo los procesos.
si puedo usar una función para mostrar un gráfico, con draw.
como en cualquier otro lenguaje, es mas, no se me había ocurrido utilizar frame en las funciones, si la función necesita un while, o un for o lo que sea, cuando acaba el bucle, muere y si la necesito la vuelvo a llamar.


para que sirve un FRAME en una funcion??

[erkosone]

para que sirve un FRAME en una funcion??

Para nada XD.. es cosa de Div por simplificar digo yo.

Las funciones en Gemix supongo que son otra Class de C/C++ ampliada con los atributos de los procesos pero no exactamente igual, lo que está claro es que tienen graph, file, visible etc etc.. y todos los métodos implementados, supongo que eso las hace mas lentas que una función clásica, a mi también me gustaría que las funciones en Gemix fueran funciones a palo seco como en C, o si no puede ser.. pues una clase sin ID ni variables predefinidas, que seguro que el core las tiene internamente en las listas de procesos y eso no deja de ser contraproducente para el rendimiento, pero claro.. se perdería la compatibilidad con div.
- Quizá sería interesante crear un nuevo tipo de procedimiento que no estuviera tan atado como las funciones actuales, aunque recuerdo que GINO comentó en alguna ocasión que no es tan fácil, no recuerdo por que.

[CicTec]

para que sirve un FRAME en una funcion??

La explicacion esta en la DOC de DIV2:

Los nuevos bloques FUNCTION se comportan de forma análoga a las funciones de otros lenguajes de programación, se ejecutan de forma secuencial (y no en paralelo como los bloques PROCESS), no retornando hasta que no han terminado.

FUNCTION <nombre> ( <parámetros> )
<Declaración de datos privados>
BEGIN
<sentencia> ;
...
END

Estos bloques seguirán funcionando de forma muy similar a los procesos normales, pero con una importante diferencia: detendrán al proceso llamador hasta finalizar, es decir, que estas funciones dormirán al proceso que las ha llamado, hasta que estas funciones retornen o su proceso finalice.

Si la función no utiliza sentencias FRAME, se comportará igual que un proceso normal, pero si una función ejecuta la sentencia FRAME, no volverá al bloque que la llamó (como lo haría un proceso normal).

Por lo tanto, una función siempre puede devolver un valor con RETURN(<expresión>), incluso después de haber dado uno o varios FRAME.


--------------------------------------------------------------------------------

Programación secuencial.

No se recomienda programar sólo con funciones y de forma secuencial, pero el conocer cómo se puede hacer facilitará el entendimiento de la programación DIV a programadores de otros lenguajes.

Es posible hacer un programa al estilo de la programación tradicional utilizando exclusivamente los bloques FUNCTION, de esta forma únicamente habrá un proceso en ejecución en cada momento.

Al programar de esta forma, la sentencia FRAME se convierte en la orden explícita de volcado a vídeo. Logicamente, si sólo hay un proceso ejecutándose, cuando este ejecute esta orden el sistema mostrará la siguiente imagen del programa.

Pero, programando asi, ¿se podrían mostrar varios gráficos en pantalla?.

La respuesta es sí, ya que se podrían crear una especie de mini-procesos que funcionaran como una instrucción del estilo "pinta un gráfico para la siguiente imagen" (a diferencia de las funciones como put(), que pintan un gráfico para siempre).

Para mostrar un gráfico en la siguiente imagen se debe construir un proceso que reciba los parámetros visuales necesarios y simplemente ejecute una única sentencia FRAME, por ejemplo:

PROCESS pinta_gráfico(x,y,graph)
BEGIN
FRAME;
END


Al llamar a este proceso se crearía un proceso temporal que se pintaría en la siguiente imagen y entonces desaparecería. Podrían contemplarse otros parámetros (además de x, y, z), como file, size, angle, z, ... (ver los datos locales predefinidos).

Claro que, al programar de esta forma, se debería crear (normalmente en una estructura global) una tabla de sprites de forma que el programa pudiera gestionar todos los gráficos. Esto, que puede parecer complicado, es la forma natural de programar los juegos en cualquier otro lenguaje que no sea DIV.


--------------------------------------------------------------------------------

Aplicaciones en el programa principal.

Las sentencias que aparecen entre las palabras BEGIN y END del programa principal (tras las declaraciones de datos), controlan el proceso principal del programa. Este es el encargado de inicializar el programa, realizar las presentaciones, controlar los bucles de menú, los bucles de juego (creando los procesos necesarios), y finalizar el programa.

En el programa principal, puede ser muy útil llamar a bloques FUNCTION. Ya que de esta forma será detenido el programa principal mientras se ejecuta la parte que controla dicha función.

Por ejemplo, la secuencia de presentación podría hacerse en una función, el menú de opciones en otra, etc. Además, se recuerda que las funciones pueden al finalizar, devolver siempre un valor con RETURN(<expresión>), lo cual puede ser también útil para que, por ejemplo el menú, devuelva el número de opción que ha sido seleccionada

Frame se utiliza por 2 razones:
1 - Para permitir la programacion secuencial como en otros lenguajes.
2 - Porque una FUNCTION es un PROCESS con propriedad especial: bloquea el proceso llamante hasta que su ejecucion no termina (para simular las funciones de otros lenguajes).
Por esta razon FUNCION tiene todas las variables locales, etc... porque es como un proceso y tratado como tal, por ende siendo gestionato en el core y archivado en listas, etc... necesita datos para saber donde volver a ejecutarse, quien es el llamante, cual grafico decir al engine2D de renderizar, etc...

Todo esto comporta que la ejecucion es mas lenta, debito especialmente al tiempo requerido para su llamada y retorno.
Para mejorar la eficiencia, debe evitar alocar todos los datos, ser tratado como un proceso y por ende no puede llamar FRAME.

[PAMERCO]

Para mostrar un gráfico en la siguiente imagen se debe construir un proceso que reciba los parámetros visuales necesarios y simplemente ejecute una única sentencia FRAME, por ejemplo:

PROCESS pinta_gráfico(x,y,graph)
BEGIN
FRAME;
END


Al llamar a este proceso se crearía un proceso temporal que se pintaría en la siguiente imagen y entonces desaparecería. Podrían contemplarse otros parámetros (además de x, y, z), como file, size, angle, z, ... (ver los datos locales predefinidos).

yo para eso utilizo los nuevos draw, que es mas o menos lo mismo, y me pinta la imagen en el frame del proceso principal o que llama a la funcion.
pues mira por donde..... y el sentido de los frame en las funciones, es lo que sigue sin quedarme claro.... porque si no devuelve la llamada, sino que sigue ejecutandose la funcion, que es, para evitar el bloqueo del programa, si la funcion tarda mucho tiempo en ejecutarse???

por cierto, aprovecho la ocasion para volver a decir que el programa, si no encuentra un frame, cuelga el pc, no sale como antes, la ventanita diciendo que el programa parece bloqueado esperando frame, sino que directamente, se queda bloqueado y yo por lo menos tengo que abrir el administrador de tareas y cerrarlo desde aqui.

recuerdo que ya se dijo, y no recuerdo porque quedo asi, pero por si acaso es un bug o lo que sea, aprovecho

[shao]

Yo sí utilizo frame en funciones, me gusta, por ejemplo, tengo un proceso que ejecuta varias tareas:

Begin
var = Menu();

If(var == 1)
Exit();

Else
EmpezarJuego();

end

end

Es un ejemplo, Menu sería una función mostrando gráficos de un menu, por lo tanto hasta que no escoges una opción la ejecución del programa no continua.
Las opciones en el Menu serian:
1 salir o 2 empezar juego.

Elegirías una opción, la función muere y se continua ahora dependiendo de la opción que elegiste.

[CicTec]

Para mostrar un gráfico en la siguiente imagen se debe construir un proceso que reciba los parámetros visuales necesarios y simplemente ejecute una única sentencia FRAME, por ejemplo:

PROCESS pinta_gráfico(x,y,graph)
BEGIN
FRAME;
END


Al llamar a este proceso se crearía un proceso temporal que se pintaría en la siguiente imagen y entonces desaparecería. Podrían contemplarse otros parámetros (además de x, y, z), como file, size, angle, z, ... (ver los datos locales predefinidos).

yo para eso utilizo los nuevos draw, que es mas o menos lo mismo, y me pinta la imagen en el frame del proceso principal o que llama a la funcion.
pues mira por donde..... y el sentido de los frame en las funciones, es lo que sigue sin quedarme claro.... porque si no devuelve la llamada, sino que sigue ejecutandose la funcion, que es, para evitar el bloqueo del programa, si la funcion tarda mucho tiempo en ejecutarse???

Al ejecutar FRAME la funcion no acaba, "pausa" su ejecucion para permitir a otros procesos de ejecutarse, solo cuando llega al RETURN o END acaba.

Un ejemplo lo tienes aqui:

Source Code (Gemix) [ Download ] [ Hide ]

Source Code (Gemix) [ Download ] [ Show ]

• program T;
• begin
•   A();
•   B();
•   C();
•   D();
•   E();
•  
•   loop
•     frame;
•   end
• end
•  
• process A()
• begin
•   loop
•     frame;
•   end
• end
•  
• process B()
• begin
•   loop
•     frame;
•   end
• end
•  
• process C()
• begin
•   FUNC();
•  
•   loop
•     frame;
•   end
• end
•  
• process D()
• begin
•   loop
•     frame;
•   end
• end
•  
• process E()
• begin
•   loop
•     frame;
•   end
• end
•  
• function FUNC()
• begin
•   from x = 0 to 2; // ejecuta 3 frames
•     frame;
•   end
• end
•  

En el siguiente programa habra una ejecucion asi:
- frame #1 = T -> A -> B -> C -> FUNC -> D -> E
- frame #2 = T -> A -> B -> FUNC -> D -> E
- frame #3 = T -> A -> B -> FUNC -> D -> E // aqui FUNC ejecuta su ultimo FRAME
- frame #4 = T -> A -> B -> FUNC -> D -> E // aqui FUNC llega al END y acaba
- frame #5 = T -> A -> B -> C -> D -> E
- frame #6 = T -> A -> B -> C -> D -> E
- frame #7 = T -> A -> B -> C -> D -> E
...
- frame #N = T -> A -> B -> C -> D -> E

por cierto, aprovecho la ocasion para volver a decir que el programa, si no encuentra un frame, cuelga el pc, no sale como antes, la ventanita diciendo que el programa parece bloqueado esperando frame, sino que directamente, se queda bloqueado y yo por lo menos tengo que abrir el administrador de tareas y cerrarlo desde aqui.

recuerdo que ya se dijo, y no recuerdo porque quedo asi, pero por si acaso es un bug o lo que sea, aprovecho

Se ha desactivado el control porque es costoso y quita bastante velocidad de ejecucion del codigo, se volvera a reactivar en cuanto haya debugger, que es donde realmiente sirve.