¿"Procesos" sin código?

[Drumpi]

Estaba pensando que uno de los códigos que más uso es el siguiente:

Code Select Expand

process bg_image (x, y, z, file, graph)
begin
    signal(id, s_freeze);
    frame;
end

Un proceso congelado cuya única misión es mostrar una imágen y hacer lo que le mande su padre. Entonces estaría bien crear una especie de objeto, igual que las primitivas gráficas, sin código ni variables locales, sólo una imágen que se pudiera modificar con funciones del estilo "move_image(x,y)", "scale_image(porcentaje)" o "rotate_image(angle)".
No sé si sería viable, o de utilidad para los demás, o si se ganaría algo de rendimiento, pero por ejemplo, en mi motror de scroll tileado en Wiz podría ganar algún FPS (según Splinter, la modificación de tantas variables locales me hacía perder algo de velocidad). ¿Cómo lo veis?

[gecko]

si se gana en rendimiento, me parece una idea buenísima!

puede servir para decorados de los niveles tambien.

[panreyes]

Lo cierto es que para decorados es una muy buena idea, sí que he comprobado en ocasiones que eso recupera bastantes FPS.

Ahora, es exactamente lo contrario al funcionamiento estándar de los lenguajes DIV, pero no es una locura, sobre todo para elementos estáticos.

De todas formas, tal como lo has planteado, Drumpi, es suficiente. No es necesario añadir modificar Bennu o PixTudio para hacerlo funcionar.

[JaViS]

yo suelo usarlo bastante, lo llamo 'dummy_process', aunque bien podria llamarse 'dumbie'

[Drumpi]

Lo mismo no he leido lo suficiente de lenguajes procedurales para saber si hay una forma más eficiente de hacer esto, pero los lenguajes DIV-like me parecen algo bastante diferentes a lo que he visto y leido, hasta el punto que creo que estamos inventando soluciones a problemas de código que no se dan en otros lenguajes.

De todas formas, no serían elementos tan "estáticos" si se pueden mover desde otro proceso... pero sí que eliminaría parte de la carga de la creación de un proceso, y bastantes variables locales (no sé, yo dejaría sólo X, Y, Z, size, angle y region, aparte de las necesarias de control del propio PixTudio). Pero vamos, que con que sean elementos que se puedan usar como las primitivas gráficas, yo me conformaría.

[Drumpi]

Antes de que se me olvide, y para no abrir un hilo nuevo: ¿Habrá alguna función tipo "region_get"? Actualmente podemos definir 10 regiones, pero no podemos saber ni la posición ni el tamaño si no las hemos guardado manualmente en variables propias.