Arrastra la bola (Experimento/proyecto módulo independiente ratón)

MephistoII666 · October 25, 2009, 06:20:40 PM

Salu (dos) a to (dos)
Este es un pequeño proyecto que empecé bastaaaante tiempo atrás pero por vagancia se quedó bastante congelado, con un par de minutos de trabajo eventual cada mes o así (a cuantos les suena esto? :P) hasta que hace un par de noches decidí cogerlo y acabarlo de una maldita vez xD

Lo cierto es que no es nada ni mucho menos grandioso o grande, pero empezó como una idea para un módulo reutilizable de ese amigÜito incomprendido nuestro que los anglosajones llaman "mouse" y nosotros los viles hispanohablantes calificamos de ratón para permitir el "arrastrar" un proceso al pulsar sobre el.

Lamentablemente al poco tiempo de empezar con el desarrollo del mismo traicioné la idea de hacer unas funciones 100% reutilizables para facilitar la programación del proyecto a corto plazo, aunque la idea de hacerlo completamente en un módulo independiente aun no la he olvidado y si la acogida de la idea se muestra cálida no dudo completarla para el aprovechamiento de aquel que pueda :D.

Por si no ha resultado obvio ya, este "juego" trata de una "esfera" que puedes arrastrar con el ratón... ¡Y lanzar!
Al soltar conserva la velocidad y angulo de movimiento que llevaba durante el ultimo fotograma y se va frenando hasta detenerse, y muestra la distancia alcanzada en el último lanzamiento desde el punto en que se ha soltado hasta el punto en que se ha parado (o vuelto a coger con el ratón, mi record está en unos 45000 ;)).

Un surrealista problema que detectamos ayer patonsky1 y yo es que siempre, en todos los lanzamientos, la distancia a la que se detiene es múltiplo de 100 (o acaba en 00, a saber). Aparentemente al modificar las constantes "friccion" y/o "min_speed" en "TAD\cojon.prg" cambia el valor en que ACABA, pero siempre es el mismo. Sí, parece ser que normalmente ACABA en y no es múltiplo de, pues una vez parecía acabar siempre en 5 pero nunca en 0 descartando la opción de ser múltiplo de 5. Otra vez también vimos un caso en que efectivamente eran múltiplos, de 2 en este caso. Si alguien tiene una pista que pueda aclarar este surrealista evento me facilitaria bastante el sueño, no porque me importe mucho pero coño me tiene mosca ???.

DESCARGA : http://www.mediafire.com/file/d2y5ywfmj1m/dragball.rar

Por cierto, a modo de "disclaimer" he de decir que como lo empecé tiempo atrás tiene un conjunto de dll probablemente ya viejas, aunque no debería dar problema con las nuevas pues las únicas funciones importantes que usa son "advance" "fget_angle" y "fget_dist"

Windgate · October 25, 2009, 07:05:42 PM

Funciona bien con las últimas DLL.

QuoteUn surrealista problema que detectamos ayer patonsky1 y yo es que siempre, en todos los lanzamientos, la distancia a la que se detiene es múltiplo de 100 (o acaba en 00, a saber). Aparentemente al modificar las constantes "friccion" y/o "min_speed" en "TAD\cojon.prg" cambia el valor en que ACABA, pero siempre es el mismo. Sí, parece ser que normalmente ACABA en y no es múltiplo de, pues una vez parecía acabar siempre en 5 pero nunca en 0 descartando la opción de ser múltiplo de 5. Otra vez también vimos un caso en que efectivamente eran múltiplos, de 2 en este caso. Si alguien tiene una pista que pueda aclarar este surrealista evento me facilitaria bastante el sueño, no porque me importe mucho pero coño me tiene mosca .

¿No será una mera cuestión matemática debido al valor que le das a la fricción?

Quote...en "TAD\cojon.prg" cambia el valor en que ACABA...

Ja ja ja, cojon.prg, es el nombre de módulo Bennu más gracioso que había oído jamás ;D

MephistoII666 · October 25, 2009, 08:56:52 PM

Quote from: windgate¿No será una mera cuestión matemática debido al valor que le das a la fricción?

probablemente y ya lo pensamos pero sigue haciéndoseme extraño que eso haga que los últimos dígitos correspondan a unos valores absolutos invariables...

La momia que fuma · October 26, 2009, 02:39:22 PM

Jeje, en lo que me traigo entre manos yo también puedes lanzar cosas con el ratón (aunque mi código es mucho más simple), ahora se va a pensar la gente que te lo copié XD

De momento tampoco lo implementé en el juego y lo tengo aparte en plan experimento, mueves el ratón y pulsas el botón izquierdo para soltar el coche, espacio para volver a empezar y asignar el chisme otra vez al ratón. Tiene gravedad y rebotes, pero de momento funcionan como el culo, como se puede ver XD (debe de hacer como 6 meses que no lo toco XD)

Quote from: MephistoII666 on October 25, 2009, 06:20:40 PM
pero por vagancia se quedó bastante congelado, con un par de minutos de trabajo eventual cada mes o así (a cuantos les suena esto? :P)

Es de los mios!! :)

DCelso · October 26, 2009, 06:00:42 PM

Ostras Mephisto,está wapa, esta técnica podría valer para hacer un juego de bolos.

Momia, con el coche ese no se hacer nada na mas que tirarlo al suelo.

La momia que fuma · October 26, 2009, 06:55:58 PM

Quote from: DCelso on October 26, 2009, 06:00:42 PM
Momia, con el coche ese no se hacer nada na mas que tirarlo al suelo.

Quizá es que intentas arrastrar con el botón pulsado como en el ejemplo de mephisto, en el mio mueves el raton para pillar inercia y pulsas mientras lo mueves para soltar el coche (espacio pa reiniciar), si, ya se que no es muy intuitivo XD, pero solo era una prueba :P

Cuando empieza a fallar y a hacer cosas raras es cuando debería quedarse quieto en el suelo XD (a no ser que lo tires sin velocidad horizontal que suele funcionar ma o meno bien)

(Perdón por desviar el tema, por cierto)

Windgate · October 26, 2009, 09:07:00 PM

El truncado que hace Bennu automaticamente cuando asignas un float a un int como x e y es un problemilla para usar advance ( )...

El caso mas claro es el advance ( 1 ) :(

FreeYourMind · October 26, 2009, 10:36:06 PM

Ya nos peleamos con el advance :) Hay que usar resolution para angulos muy pequeños.

SplinterGU · October 26, 2009, 11:20:05 PM

caramba wind! te has olvidado del resolution... :)

MephistoII666 · October 27, 2009, 12:27:03 AM

Caramba carambita carambola, Conocía el resolution pero tampoco me convenció porque desconozco la cantidad de decimales que puede llegar a tener el valor de velocidad y para curarse en salud habría que poner un resolution tremendamente grande y como no quería complicarme lo acabé rápido repitiendo el advance() desde el punto de origen con la distancia recorrida total que de todos modos ya tenia que calcular a efectos de interfaz y punto...
Probablemente para cosas mas complejas por ejemplo si requiere cambios de dirección y cosas así sí sería más sencillo usar resolution.

bolos? sí tal vez :P
U otra idea jugable sería hacer a la bola recorrer un recorrido, estilo minigolf, pero mi idea original era simplemente hacer un módulo que permitiera arrastrar y depositar simplemente, principalmente orientado a interfaz y ventanas, a la windows (sí, windows, que fue el primero joder xD)

Un problema/duda es detectar la pulsación. ¿Hay alguna función que automáticamente devuelva la ID de proceso que está bajo el píxel exacto en que está el ratón? ¿O habría que hacer aparecer un gráfico de 1x1 y quitarlo antes del frame?

Drumpi · October 27, 2009, 01:41:02 AM

Sólo collision(type mouse), pero sólo funciona desde los procesos receptores, no con el ratón (podrías usar un proceso que siga al ratón, de tamaño de 1x1 pixel usando el viejo truco de alpha=0).
Pero ojo: dos procesos superpuestos pueden colisionar a la vez y ser ambos válidos.

MephistoII666 · October 27, 2009, 02:39:56 AM

Collision (type mouse) detectaría colisión con CUALQUIER parte del ratón, ¿no? Quiero decir, que si un proceso estuviera tocando el "rabo" del ratón pero no la punta (zona que se supone debiera ser la única que detectara) también se consideraría como pulsado. Eso además del problema que solo se podría usar modificando los procesos que se suponga que interactúan con él.

Lo del alpha = 0... funcionaría? pensaba que collision() solo detectaba colisión con píxels VISIBLES de los procesos, aparte de que me parece algo más limpio graph = "something"; y graph = 0; antes del FRAME; o que incluso el proceso encargado de eso sea temporal y no llegue al frame;...

Supongo que procederé con el módulo y dejaré en dique seco lo que hay por ahora del "dragball". alguien podría verle uso a algo así?

Windgate · October 27, 2009, 01:20:32 PM

El proceso que sigue al ratón con tamaño 1x1 en la punta del ratón me parece la solución más adecuada para que el drag funcione sólo con la punta del ratón. Eso del proceso siguiendo al mouse fue la base de mi antiguo Just Fantasy xD

En cuanto a resolution, muchas gracias, ciertamente nunca he probado esa variable, me pelearé con ella a ver qué tal va la cosa.

Por cierto mephisto, con alpha = 0 no sé decirte... Pero lo que es seguro es que collision tiene en cuenta la geometría del gráfico y "un gráfico en forma de donut no interpreta colisión con un proceso dentro de su orificio (anal...)".

Drumpi · October 27, 2009, 02:02:14 PM

A ver, MephistoII666, cuando el type es mouse no se actúa de forma normal, porque mouse no es un proceso: si haces colisión con el mouse sólo chocará el "hot spot" (punto caliente, es un único pixel), situado en el centro (punto de control 0) del gráfico que le asignes. Es más, no lo he probado pero juraría que también hace colisión con el ratón aunque este no tuviera gráfico.

Y collision choca con los pixels no transparentes, efectivamente, pero el alpha no modifica el contenido de los pixels de los mapas por lo que, aunque no se vea en pantalla, se sigue superponiendo y dando colisión. Es un "viejo truco" porque está más que demostrado que funciona.

MephistoII666 · October 27, 2009, 09:07:27 PM

Comprendido... collision (type mouse) vale para detectar solo lo que hay bajo el centro del ratón, pero sigue sin valerme 100% por tener que modificar los procesos que vayan a ser vulnerables a el. En lo que respecta a alpha=0; ya me imaginaba que iría así, solo necesitaba una confirmación.

De momento parece que habré de quedarme con el proceso que siga al ratón...