Preguntas sobre programacion de Hokutoy.

[Rein (K´)ah Al-Ghul]

caramba, aparentemente funciona... no me acordaba de esto, bueno, por lo menos compila.

edit: ahhh, ya veo...

no funciona como supongo supones que funciona...

lo que hace el compilador es resolver la operacion constante y asignarla al case... en el ejemplo que pusiste seria lo mismo que poner:

case 1:

case 1:

el 3ero no funciona, ya que 1 not 7 no es una expresion permitida.

porque 1 and 7 = 1
y 1 or 7 = 1

entonces el switch se puede usar con expresiones...
mientras estas sean verdaderas y el resultado pueda ser "contante"...

[SplinterGU]

no se que quisiste decir... lo que yo digo es que las expresiones se pueden usar y se resuelven en el momento de compilar, no en el momento de ejecutar...

[Hokutoy]

Otra duda mas... esta vez una pregunta de eficiencia.
Que es mas eficiente dentro de un loop:
A:

Code Select Expand


IF(MOUSE.LEFT AND COLLISION(TYPE MOUSE) AND FLAGS==0);

B:

Code Select Expand


IF(COLLISION(TYPE MOUSE) AND MOUSE.LEFT AND FLAGS==0);

C:

Code Select Expand


IF(MOUSE.LEFT) IF(COLLISION(TYPE MOUSE) AND FLAGS==0);


Es decir, en el caso A se comprueba siempre las 3 condiciones o al comprobarse la primera (mouse.left) y ser falsa ya no se comprueba la colision del mouse?
Si siempre se comprueban las 3 condiciones entonces imagino que la mas eficiente será la C.
O a lo mejor no vale la pena comerse la cabeza porque la diferencia de rendimiento es mínima.

Gracias!

[DCelso]

Los "and" funcionan evaluando las expresiones de izquierda a derecha y en el momento de que una no cumpla no sigue con las demás.
Así que lo más rápido es poner a la izquierda las condiciones más rápidas de realizar y las más lentas a la derecha.

Si lo piensas un poco, esto es lo lógico debido a la forma de actuar de un "and", si una no se cumple, ¿para qué seguir comprobando las demás si sé que el resultado final será falso? :D.

Como nota final, en los "or" sí que hay que comprobar todas.

[SplinterGU]

la mas optima no es ninguna de las 3

es esta...

IF( MOUSE.LEFT AND FLAGS==0 AND COLLISION(TYPE MOUSE) );

[Hokutoy]

la mas optima no es ninguna de las 3

es esta...

IF( MOUSE.LEFT AND FLAGS==0 AND COLLISION(TYPE MOUSE) );

Gracias a los 2!

Splinter, no sería aún mas optimo:
IF( FLAGS==0 AND MOUSE.LEFT AND COLLISION(TYPE MOUSE) );

Ques es mas penalizante, comprobar el flag de un proceso o mirar si se pulsa un boton?

Asias!

[DCelso]

a igual coste de tiempo de ejecución (recordemos que tanto ver flag a cero como ver el botón pulsado es comprobar una variable), es más rápida la más restrictiva.
En este caso será más facil que sea false el que esté pulsado el botón del ratón a que esté el flag a cero, que será como más normal.
Entonces si comprobamos primero el flag y casi seguro que está a cero tendrá que comprobar si está pulsado el botón del ratón haciendo así dos comprobaciones.
En cambio si comprobamos primero el ratón y vemos que no está pulsado pues terminamos y vamos a otra cosa con lo que ahorramos una ejecución.

[SplinterGU]

ademas, una tiene la operacion adicional "=="

[Hokutoy]

OK! Gracias a los dos por las respuesta y, sobretodo, por las explicaciones.
Karma++!

[Hokutoy]

Buenas! Mas ayuda please!
Ultimamente ando jugando bastante al spout y al Alert de Wiz así que me ha picado el gusanillo de hacer un matamarcianos jejeje
Tengo un problema... no se como hacer las típicas "chispas de impacto" o "volcan de pixeles" para cuando las balas golpean al enemigo o a la pared... supongo que sabeis a que me refiero. Muy parecido al efecto de spout pero no tan exagerado y sin física.


Al lío... para hacer las típicas chipas de impacto como se hace? Un proceso que cree un pixel y le de una trayectoria semialetoria segun el angulo de impacto y así? No lo acabo de ver claro... alguien conoce de algun ejemplo que pueda estudiar o me quiere indicar el camino correcto?

Asias!

[FreeYourMind]

Usar funciones random, que te desloquen un pixel o gráficos (unos cuantos en la colision) de forma aleatoria en los ejes XX, YY

[DCelso]

yo haría los frames de la animación con un editor de gráficos y luego los animaría en bennugd, esto te da más versatilidad,  puedes poner distintos tamaño de pixeles, puedes poner colores distintos y consume menos tiempo de procesamiento.
A no ser que estés muy limitado de espacio y no tengas espacio para guardar las imágenes.
que podrías hacer lo que dice free.

[Drumpi]

La verdad es que es una pregunta verdaderamente interesante, porque no es la primera vez que me la planteo.
Es que el tema de "partículas" es especialmente complejo en Bennu (en Fenix también lo era), porque el uso de una animación a base de mapas es la versión fácil, pero se pierde la aleatoriedad y requiere de usar muchos gráficos grandes a poco que se separen dichos pixels. Y el uso de un proceso por partícula es muy costoso computacionalmente, e inviable en GP2X y WIZ (y a las pruebas me remito ;)).

Ya se lo planteé hace tiempo a Splinter, pero creo que es un buen momento de volver a hacerlo y en público, ya que la gente se ha animado a crear módulos nuevos: sería muy buena idea tener un módulo que manejase gráficos sin estar ligados a procesos, un poco como se hace con los textos o las primitivas gráficas, se crea una instancia de gráfico que devuelve un ID, que se puede usar para llamar a funciones como move_graph, rotate_graph, delete_graph.
Esto ahorraría el tiempo de generación de procesos, el espacio que ocupa, la gestión del orden de ejecución, estados y demás.

[SplinterGU]

esas instancias que dices se llaman procesos...

vamos que estas haciendo lo mismo solo que estas trasladando la logica de un lado a otro... y si tu problema es la perdida de tiempo en que se ejecutan los procesos... pues nada, los pones en freeze y los manejas como tu quieres desde un proceso controlador...

definitivamente eso que pides no lo hare, porque no tiene sentido, es lo mismo y ahorrarias nada de tiempo.

:)

[Drumpi]

Bueno, no se cómo irá internamente, pero ya congelo los procesos masivos y uso otro controlador para ello, y se que el mayor costo de tiempo no está en el renderizado, porque si uso menos procesos con imágenes más grandes se nota que mejora la velocidad (y es una de las pocas mejoras que me quedan por hacerle al juego para arañar algunos FPS).

Y tampoco he dicho que lo hagas tu, sólo si alguien se anima ;)
De todas maneras, a ver si me libro del sonido de una vez, que quiero empezar el motor de scroll tileado v4, y esta vez voy a bajar a los infiernos ;D (bueno, casi, el ensamblador me da miedo ^^U)