Que narices, revolucionemos size

[La momia que fuma]

Esto es algo que me lleva dando vueltas por la cabeza desde hace años y nunca me acuerdo de comentarlo...creo que lo propuse una vez para Fenix pero no se aceptó (Cosa normal, como veréis XD)

A ver como me explico: Opino que size es bastante inexacto por ser porcentual, por ejemplo, con size=120 un gráfico pequeño crece menos "píxeles" que uno grande, cosa que no deja de ser lógica con el funcionamiento actual, pero yo creo que estaría bien poder controlar con exactitud, practicamente al píxel, cuanto aumenta una imagen.

Lo que propongo es que size y derivados (size_x, size_y) valgan por defecto 0 en tamaño normal e indiquen cuantos pixeles debe crecer la imagen (size=2, la imagen crece 2 pixels; size_x=10, la imagen crece a lo ancho 10 pixels) con esto se podrían hacer aumentos graduales de tamaño lineales (con el funcionamiento clásico por ejemplo, si metes un size+=20 en un bucle, el gráfico ira creciendo menos a cada paso), o por ejemplo, con size_x o size_y esto sería muy util para hacer cuerdas o lianas en los juegos de tamaño variable controlado al milimetro por el jugador o para un millón de cosas más.

Ahora, antes de que el sector conservador se me eche al cuello por proponer semejante sacrilegio y cambiarles los esquemas XD (Por eso supongo que no se tomo en cuenta en fenix, y me parece lo más correcto, a decir verdad), recordaré que Bennu es modular, se podrían poner estas funciones en un modulo aparte, o hacer un modulo alternativo al que contiene size (que ahora mismo no se cual es, la verdad) que se diferenciase solo en eso, así cuada cual podría elegir entre el funcionamiento clásico o este según gustos

O incluso hacer que venga "de serie" y se pueda elegir modo resucitando las compiler options de DIV (No tengo muy claro esto, pero creo recordar que en DIV había una variable compiler_options o algo así que permitía cambiar el estilo de interpretar algunas cosas por el compilador, no se si a dia de hoy esto existe en fenix o bennu). El fucionamiento por defecto en este caso seria el clásico, para mantener compatibilidad y no liar a la gente acostumbrada al funcionamiento de toda la vida.

No se, también podría crearse una variable local aparte para esto (Sería mas "lingüisticamente" correcto XD, a esto que propongo le pegaría mas algo tipo size_inc o algo asi)

[SplinterGU]

ummm... entiendo lo que decis, pero lo veo un poco problematico... primero que al estar trabajando con enteros seria impreciso (algunos valores imposibles de obtener)... y para que sea un poco mas preciso (casi) necesitariamos mantener variables tipo float, adicionales a las que estan... y hay que tocar unos cuantos modulos para lograrlo...

[HaCkZJuaNN]

splinter, los pixeles son enteros, no? tú no puedes aumentar aumentar una imagen de tamaño 2,5 pixeles, o sí?? así que no veo problema con los enteros, el mismo que hay ahora, que cuando aumentas 1 pixel una imagen de 100, tienes que mezclar colores para que la imagen "aparezca" igual.

Sin embargo, momia eso que tú dices se puede hacer relativamente fácil. Sólo aplica esto, si quieres aumentar n pixeles el tamaño de la imagen, haz: size_x = 100+100*n/ancho. Si lo que quieres es reducirlo, pues entonces n tendrá que ser un número negativo, o lo que es lo mismo, lo restas, size_x = 100-100*n/ancho.

y el ancho lo puedes obtener con graphic_info().

EDIT: ancho es el ancho ORIGINAL de la imagen, no el nuevo ancho que tú quieres conseguir. También puedes hacer esto(que es lo mismo), para conseguir un nuevo ancho, en vez de aumentar n pixeles:

size = 100*ancho_nuevo/ancho_original

[SplinterGU]

pense que no iba a ser necesario explicar esto, y menos a vos... te voy a demostrar que estas equivocado y cuanto...

por ese mismo motivo que mencionas no se pueden usar enteros...

para aumentar un grafico en X pixels es necesario saber que porcentaje (u otro factor) del grafico debe ser aumentado, y X pixels pueden dar un porcentaje con decimales... pero se usan enteros...

podes usar reglas de 3 simples desde el mismo prg (como vos decis), pero al no ser precisos los valores de size que puede retornar, no lo mencione...

EDIT: por ejemplo, si yo tengo un grafico de 300, el 1% de eso es 3... y si yo quiero incrementos de 1 o 2 pixel, lo minimo que podre hacerlo es por 3 pixels. El size para aumentar 1 pixel deberia ser de 100,33~, lo cual es imposible...

[HaCkZJuaNN]

Ahhhh, ahora te entiendo. Pero como lo que no sé es cómo se hace el aumento de size internamente en bennu, sólo se pueden hacer aumentos de tamaño de un gráfico de mínimo 1% de tamaño??? No hay ninguna razón para que ese sea el valor mínimo(al menos que yo vea). Si tu doblas una imagen de tamaño, está claro lo que hay que hacer, cada pixel transformarlo en 2x2 pixeles, pero si tú una imagen la transformas al 101%, para que la imagen siga pareciendo igual, tienes que hacer mezclas de distintos colores cambiando totalmente la configuración de la imagen, o no???

[SplinterGU]

lo que decia del minimo de 1%, me referia a tu calculo...
por otro lado, internamente se usan enteros y flotantes, pero tampoco es preciso, pero es logico que cuando hablamos de porcentuales enteros, es todo mas simple que porcentuales con decimales, mas si tenemos en cuenta que no puedo tener 1/2 pixel. y no nos olvidemos de centros y todas esas cosas... todo se afecta... y al no tener precision de decimales, la cosas puede quedar muy desarticulada...
por otro lado, no hay mezcla de colores en los size.

[Drumpi]

Hombre, creo que el tema de los enteros viene a que el programador-usuario invoca a size pasándole el tamaño de pixels que quiere que tenga la imagen final. Aunque claro, luego, internamente, necesita el uso de decimales para hacer los cálculos.

Si alguien se anima a hacer un módulo nuevo de "resizes", tambien podría plantearse la posibilidad de añadir algunos algoritmos más avanzados de escalado/filtrado que los que usan Bennu y Fenix, que, en ocasiones, al menos segun he comprobado con una imagen con texto, vuelven la imagen demasiado "difusa" como para interpretarla correctamente (vamos, que al reescalar un texto de 640x400 a 320x200 ya no se leia un piojo) :D

[La momia que fuma]

La verdad es que ahora que lo pienso si que es cierto que muy exacto no es XD, no puedes tener un gráfico de por ejemplo 300x300 y aumentarle así porque si un pixel por cada lado de tamaño e ir de exacto por la vida jejeje, nunca lo pense muy a fondo...

De todos modos en lo que estoy haciendo ahora llevo tiempo usando una especie de regla de 3 como dice HaCkZJuaNN para una especie de cuerdas y da buenos resultados (Unos pocos del foro que lo han visto saben de que hablo :P)

[HaCkZJuaNN]

Splinter, sigo sin entender lo que dices de los enteros. El hecho de que midamos en porcentaje(por 100), es una arbitrariedad, es así porque nos da la gana, si tú una imagen la pones a un 101% de tamaño, se convierte en 1,01 x el tamaño de la imagen original, que no es un número entero. Estaríamos hablando de números enteros cuando lo MULTIPLICAMOS(que no dividir) por un número entero, esto es, un 200%, 300%, 400%, etc... Pero size = 150, es multiplicar el tamaño de la imagen a 1,5x, que no es entero, y lo mismo para reducir a la mitad(0,5x).

Ahora, lo que quiero decir con esto es que para tú aumentar una imagen un 5%, a 105%, imaginando que la imagen tenga 100 pixeles de ancho, sería convertirla en una imagen de 105 pixeles de ancho, lo cual es imposible expandiendo cada pixel, por eso decía lo de la mezcla de colores. No sé si habrá mezcla de colores o qué, pero algo hay que hacer para que la imagen siga teniendo el mismo aspecto que tenía al principio. Como he dicho, los únicos tamaños que se podrían obtener simplemente expandiendo algunos pixeles serían 200%, 300%, etc...

Ahora bien, lo que digo es que esto mismo que se hace, sea lo que sea, se puede hacer para aumentar 1 pixel, que dependiendo del tamaño de la imagen será un porcentaje u otro, pero no me digas que sí que puedes aumentarla un 1% y un 0,5% no; porque son exactamente el mismo proceso(multiplicar por 1,01 o por 1,005. Obviamente habrá algún límite de precisión, pero no porque se trate de números decimales, porque 1% ES un número decimal, sino por alguna otra razón, y dudo de que este límite esté precisamente en el 1%.

[panreyes]

De todos modos en lo que estoy haciendo ahora llevo tiempo usando una especie de regla de 3 como dice HaCkZJuaNN para una especie de cuerdas y da buenos resultados (Unos pocos del foro que lo han visto saben de que hablo :P)

guiño guiño xD

Mi opinión: size está genial tal como está, al igual que size_x y size_y. Lo único que añadiría es variables locales (pixel_size_x,pixel_size_y ?) para establecer el tamaño indicándole los píxeles de alto y ancho, aunque fácilmente se puede hacer en el programa. Aunque bueno, esto se puede hacer fácilmente con la función ya comentada.

[SplinterGU]

HaCkZJuaNN, resumiendo, digo que si tengo una imagen de 300, no puedo aumentar de a 1 pixel, ni de a 2...

[HaCkZJuaNN]

HaCkZJuaNN, resumiendo, digo que si tengo una imagen de 300, no puedo aumentar de a 1 pixel, ni de a 2...

Ya, pero sigo sin entender exactamente por qué. En realidad es igual de difícil aumentar una imagen de 300 2 pixeles que 3, teóricamente. Es porque la función de SDL o de C que tú utilizas también funciona con porcentajes??? En ese caso lo entendería.

[SplinterGU]

en base a la formula que propones.