Ya está to mono y empaquetao.
Ejemplo botón. Principal: botones.prg.
Ejemplo barra. Principal: barra.prg.
Ejmeplo caja de texto. Principal: cajas.prg
Ya me contareis.
Guauuu, ya se attachear.
Buen trabajo, se ve muy bien, mejor a 60 fps, cuando hay ratón 30 fps es poco.
Karma up, si haces algún tipo de documentación sobre cómo usar esa historia seguro que más de uno te lo agradece.
Es lo malo de poner algo, QUE TE PIDEN MÁS. Jua, jua, jua.
Gracias compañero.
Lo que pasa es que creo que está muy verde, de todas formas me ententedré un ratejo.
excelente :),
sería interesante que en la caja de texto la rueda del ratón funcionara (quien sabe como se llama?... ustedes!)
tambien cuando das click en el espacio de movimiento en de la barra deslizante pero no sobre la barra deslizante la barra se mueve (eso está correcto), pero debería pararse hasta llegar al ratón y no hasta llegar el tope de máximo|mínimo texto.
son tonterías, pero es interesante que se agregara, saludos
karma++
¡Oido cocina!
Gracias compañero.
Lo que dices del mouse también me fijé, cuestión de añadir mouse.wheelup y mouse.wheeldown como control.
No preocuparse. Lo que pasa es que mi ratón no tiene rueda (¿O si?) Bueno, que no se me ocurrió probarlo. ;D
Es de esos de los chinos de 6 euros con forma de pinguino de linux. Mu shulo. ;D (Otro motivo más para entrar a los chinos). ;D
Pues para eso entras en una tienda de informática y te compras un ratón por 8€ como dios manda, que encima te durará más y será de marca conocida y con garantías :D
Quote from: Drumpi on May 10, 2010, 01:00:50 PM
Pues para eso entras en una tienda de informática y te compras un ratón por 8€ como dios manda, que encima te durará más y será de marca conocida y con garantías :D
dices 8€ como si fueran nada, recuerda que algunos tienen un presupuesto semanal de 7€... ;)
Ya, pero puestos a gastarse 6€ en los chinos, mejor 8€ en algo que tenga un mínimo de fiabilidad, que 2€ no son tanta diferencia :D :D :D
Pero no tienen la forma del pingüino, na, na, na. :P
Quote from: Drumpi on May 10, 2010, 01:43:39 PM
Ya, pero puestos a gastarse 6€ en los chinos, mejor 8€ en algo que tenga un mínimo de fiabilidad, que 2€ no son tanta diferencia :D :D :D
era un chiste... :)
jo jo... yo nunca me fijo en eso.. ni se que marca es mi ratón..
lo bueno es que en bennu tenemos otra opción para gui (me refiero a esta opción de Fede), y se ve muy bien :).
oye Fede, haces uso de locales o de publics?
lo que pasa es que, como ya debes saber las locales se asignan a todos los procesos aunque no sean cajas de texto, mientras que las public no, y pues puede ser un graaaaaaan! ahorro usar publics...
nuevamente gracias y felicidades por la gui, se ve muy bien :)
pfuuu, menuda pregunta.
Me parece que lo hago bien, locales si necesito que cada proceso tenga la suya independiente y publicas si es la misma para todos los procesos.
La idea es que lo mismo que llamas a un proceso en el juego para ir creando diferentes unidades independientes, bien sean amigas o enemigas, he hecho lo mismo con los botones, barras, etc.
La barra, está compuesta de 3 llamadas al proceso boton, por lo tanto la mayoría de las variables de botón son locales. Y es el proceso barra quien le dice a los procesos botones como comportarse, a traves de la modificación de sus variables locales, independientemente de la vida propia que tiene el proceso botón. Hay variables locales que el proceso botón sólo las usa para consulta.
Hace tiempo busqué la programación orientada a objetos en bennu, y Splinter ha echo un simil buenisimo y a mi parecer más encapsulado y más facil de comprender. Los procesos.
Un proceso es un objeto todo lo complicado que quieras, con subprocesos o con lo que te de la gana.
Para colmo las funciones paran el proceso hasta que no termina. Lo cual es estupendo y te sirve para puntos de control o subrutinas que deben de ejecutarse antes de que el proceso siga.
Total, que cuanto más programo, más pillo la filosofía de bennu y más me gusta y me sorprende.
De todas formas tengo que optimizar y limpiar el código, sobre todo cuando lo pruebe en la wiz. ;D
Saludos.
(Espero no haberme enrollado mucho).
El uso de LOCAL en algún módulo que pretende ser reutilizado hay que hacerlo con muuuuuucho cuidado. Además de PUBLIC están los punteros para esas cosas.
En el único sitio donde he metido LOCAL es en el 3Dit, porque pretende mantener la "filosofía Bennu" y permitir hacer father.x y todas esas cositas pero en 3D.
Para lo demás cuidado con LOCAL que es muy útil y muy fácil pero se empieza a sobrecargar innecesariamente el programa y eso a largo plazo no es bueno.
A ver si lo voy pillando.
Cuando defino una variable como local ¿afecta sólo a ese proceso y a sus descendientes, o a todos los procesos del programa?
¿Sobrecargar? ¿Cuanto? ¿Cómo? Si esiste LOCAL es para utilizarlo ¿No? ¿Tanto sobrecarga?
Y por último, y visto que me habeis preocupado, ¿Donde me informo/aprendo sobre el uso conveniente de las variables locales?
Saludos.
es al reves, local es para todos los procesos, public solo para el que la define.
me alegra que te guste bennu.
Definición básica: una variable LOCAL es una variable que se declara una sóla vez, pero se crea una por proceso (como lo son GRAPH, X, Y, ALPHA...) y son legibles desde cualquier punto del programa mediante el ID del proceso al que queremos acceder, un punto, y el nombre de su variable (FATHER.X, SON.GRAPH, id_proceso.ALPHA...).
Su ventaja es esa, que se puede leer desde fuera de los procesos, y que hay una por cada uno de ellos (lo cual es interesante por si no sabemos cuantos procesos "enemigo" vamos a tener para consultar su "energía").
Su problema es que TODOS los procesos tienen dicha variable. Podemos crear una que se llame "puntos" para que cada jugador vea los que ha conseguido pero ¿qué utilidad tiene eso en los enemigos, el control del teclado o los procesos del menú? ellos también tendran su propia variable "puntos", lo que es un gasto inútil de memoria.
Espero que haya quedado un poco más claro.
Gracias compañeros, me lo apunto.
Las locales hacen justamente lo que pensaba, sólo que no había tenido en cuenta su uso masivo.
Tendré que tener más en cuenta los recursos.
En su día hice unas pruebas de eficiencia invocando 32K procesos sin usar LOCAL y luego usando unas 16 variables LOCAL de tipo int.
El juego era en 3D y ya de por sí consumía mucha memoria y CPU, así que el hecho de usar LOCAL o no usarlas era inapreciable, no noté ni tan si quiera un 1% de diferencia de rendimiento.
En cualquier caso, para juegos 2D, por ejemplo para Wiz donde los recursos del sistema hay que cuidarlos sí que puede llegar a influir, te recomiendo hacer alguna prueba de ejecución con y sin LOCAL, y comprobar la memoria y CPU consumida y máximo FPS que obtienes.
Hombre, ten en cuenta que una variable tipo INT ocupa 4bytes por cada proceso, suponiendo una cosa muy bestia (como hago yo de vez en cuando), por ejemplo, 1000 procesos, sería un total de 4KB de RAM, no me lo compares con 32MB que puedes gastar fácilmente con un par de FPGs con fondos y una canción en OGG con varios WAVs.
Pero claro, en máquinas limitadas, el uso de locales se nota más.
Tambien creo que huelga decir que aquí la CPU no pinta nada, lo mismo se tarda en acceder a un tipo de variable que a otra.