pequeño fallo del lib en dx_Input_class: Mouse_Hit

[RobiHm]

bueno pués parece ser que la función dx_Input_class: Mouse_Hit(boton) solo devuelve si se ha pulsado una única vez por ciclo... y eso no tiene mucho sentido aún leyendo la documentación

Resultado
Boolean -  Devuelve Verdadero en cuanto se presiona el botón. Si el botón sigue presionado se devuelve falso.
Comentarios
A diferencia del objeto Mouse, Mouse_Hit solo detecta la acción de pulsar el botón pero no devuelve de continuo el estado de dicho botón.


¿qué sentido tiene que la primera vez que le preguntes si te responda y la segunda no? si el resto de funciones del mismo tipo funcionasen así ya nos podríamos dar por jodidos

creo que es un fallito bastante gordo, al principio no le dí importancia pero ahora que he metido un montón de interfaces es un gran problema


un saludo

[[EX3]]

¿qué sentido tiene que la primera vez que le preguntes si te responda y la segunda no? si el resto de funciones del mismo tipo funcionasen así ya nos podríamos dar por jodidos

creo que es un fallito bastante gordo, al principio no le dí importancia pero ahora que he metido un montón de interfaces es un gran problema

No entiendo. Esta funcion lo unico que hace es detectar una pulsacion, no te indica si la tecla sigue presionada ya que para eso esta la variable estado de cada boton en el objeto Mouse.

Suponte que tienes una pantalla de creditos (por ejemplo) que cada vez que haces click con el boton esta pasa a otra pantalla asi hasta un maximo de 3 cada vez que pulses el raton. Si lo haces mediante la variable de estado del objeto Mouse las 3 pantallas pasarian al instante en cuanto pulsaras el boton ya que solo evaluas si la tecla esta presionada y no si la has presionado dando por valida las 3 condiciones en cada ciclo que pasara, mientras que si evaluas mediante MOUSE_Hit() pasara a la siguiente pantalla y no reaccionara hasta que sueltes el boton del raton y vuelvas a presionarlo. Seria similar al evento Click() de Visual Basic que solo reacciona a cada pulsacion que hagas a un boton del raton, mientras que la variable de estado del objeto Mouse seria igual al evento MouseDown() que es continuo mientras tengas un boton presionado. No se si ves el uso practico pero si tienes que diseñar una interfaz de usuario o alguna accion concreta como detectar la pulsacion de un boton y no que lo mantengas presionado (un boton de comando por ejemplo) te daras cuenta de ello, y es mas, funciones como estas las traen lenguajes de juegos como Blitz3D y similares.

A parte de invitarte a mirarte el tutorial 4 de dx_Input te dejo un ejemplo para que lo compruebes. Abre Visual Basic y agrega un proyecto nuevo con un formulario y un Timer a 1 milisegundo de intervalo. Agrega la referencia a dx_lib32 y añade el siguiente codigo al cuerpo del formulario:

Código [Seleccionar] Expand

Option Explicit

Dim GameInput As New dx_Input_Class
Dim Stage As Long

Private Sub Form_Load()
   Call GameInput.Init(Me.hWnd)
End Sub

Private Sub Timer1_Timer()
   ' Incrementa la variable Stage en 1 por cada click que se detecte en el boton izquierdo:
   If (GameInput.Mouse_Hit(Left_Button)) Then Stage = Stage + 1
   
   ' Cambiamos el color del formulario segun el valor de la variable Stage:
   Select Case (Stage)
       Case 1
           Me.BackColor = vbRed
       Case 2
           Me.BackColor = vbGreen
       Case 3
           Me.BackColor = vbBlue
       Case 4
           Call GameInput.Terminate
           Set GameInput = Nothing
           End
   End Select
End Sub
Ahora prueba a cambiar la condicion por:

Código [Seleccionar] Expand

If (GameInput.Mouse.Left_Button) Then
A que la reaccion no es la misma? ;) Si es que vemos errores en cualquier lado xD

Salu2...

P.D.: Con Key_Hit() sucede lo mismo, suponte un juego de lucha, que facil seria jugar dejando continuamente presionada la tecla de patada si programaras la condicion de lanzar la patada con Key() :P

[RobiHm]

el tema esta en que en el resto de lenguajes son eventos y aqui es una función...

si yo tengo que comprobar si se ha pulsado el ratón en diferentes circunstancias de un mismo ciclo, solo lo comprobará en la primera y en la segunda siempre será false... en visual basic al hacerlo internamente el evento se dispara sin que tu tengas que comprobar nada... en blizz supongo que será asi

entender su funcionalidad y tal la entiendo, pero cuando en cambio se quiere comprobar en diferentes partes hay que tener por ahí una variable para ver si inicialmente se había clicado ... de ahi digo k es un error... ya que falta otra función que hiciese lo mismo (y lo del objeto mouse no me vale ya que detecta que se ha clicado si aun sigue pulsado)


más que un fallo es una reacción inesperada xD


un saludo

[[EX3]]

el tema esta en que en el resto de lenguajes son eventos y aqui es una función...

En Blitz3D es una funcion, en este lenguaje no existen eventos y no se ha muerto nadie que yo recuerde xD

A ver, que los eventos seria lo suyo pero es que dx_lib32 no se diseño para trabajar con eventos pero piensa tambien que un evento no deja de ser un simple y mero metodo como otro cualquiera. La diferencia radica en que Visual Basic por debajo levanta un gestor de eventos. Si tu diseñas el codigo del juego en base a ejecutar la logica por un lado y por otro los graficos (como el ejemplo del matamarcianos) tu estas ejecutando una especie de gestor de eventos ya que tu codigo de logica se basa en evaluar condiciones y ejecutar codigo si se cumplen dichas condiciones (lo que hace Visual Basic es hacer un Raise Event por debajo), por lo tanto tu puedes definir un metodo sub con el codigo que deberia ser el evento Click de tu boton personal y sencillamente realizar la condicion en el metodo de actualizacion de logica del juego o en la ubicacion donde se encuentre (un modulo clase por ejemplo), no se si me explico:

Código [Seleccionar] Expand

Clase Principal
   ...
   Funcion Actualizar()
       ...
       ...
       Dialogo.Actualizar()
       ...
   Fin Funcion
   ...
   Funcion Dibujar()
       ...
       ...
       Dialogo.Dibujar()
       ...
   Fin Funcion
Fin Clase
------------------------------------------------------------------
Clase Dialogo
   ...
   ...
   Funcion Actualizar()
       ...
       EventoBoton()
       ...
   Fin Funcion
   ...
   Funcion EventoBoton()
       Si (BotonIzquierdo ha sido pulsado) Entonces
           Codigo del "evento"
       Fin Si
   Fin Funcion
   ...
Fin Clase

entender su funcionalidad y tal la entiendo, pero cuando en cambio se quiere comprobar en diferentes partes hay que tener por ahí una variable para ver si inicialmente se había clicado ... de ahi digo k es un error...

Eso lo tendrias que hacer con el objeto Mouse. Mouse_Hit precisamente te evita tener que implementar dicha comprobacion de si se ha pulsado o no, de eso ya se encarga un evento interno de la dx_lib32.

Salu2...

[RobiHm]

en el caso en el que tengas más de una clase (en mi caso 10+) es imposible tener 10 comprobaciones ya que en cuanto haga la primera el valor se vuelve false sea cual sea... de ahi el problema, si utilizas el mouse el click pueda que siga pulsado y por lo tanto se tenga que hacer otro tipo de acción, de ahi que no pueda usarlo y de ahi que vea una carencia... si la función funciona... pero solamente una vez... de ahi que tenga que guardarla en una variable

ejemplo...

Código [Seleccionar] Expand

lógica de interfaz informativa ajena al bucle central
*si se ha pulsado el botón izquierdo compruebo las zonas de impacto posibles y ejecuto acciones
...
...
acciones generales
*estado de usuario
*lógica acciones de interfaz directas al desarrollo del juego
si se ha pulsado el botón izquierdo...
 blbaalblablablbalablba
...
...
dibujo... etc etc      

al mirar en la primera parte genérica al juego dependiendo de su estado (ver información que no desencadena acciones), el valor pasa a ser false y ya no puedo comprobar la lógica del usuario

a eso me refería...


un saludo

[[EX3]]

en el caso en el que tengas más de una clase (en mi caso 10+) es imposible tener 10 comprobaciones ya que en cuanto haga la primera el valor se vuelve false sea cual sea... de ahi el problema

Vale, acabo de notar ese "detallito" que mencionas :? Por el momento lo puedes solucionar haciendo una variable global que guarde el estado del boton justo al principio del metodo global de actualizacion de tu juego y luego realizar las comprobaciones en base al resultado de esa variable, por ejemplo:

Código [Seleccionar] Expand

Option Explicit

Dim GameInput As New dx_Input_Class

Private Sub Form_Load()
   Call GameInput.Init(Me.hWnd)
End Sub

Private Sub Timer1_Timer()
   Dim estado As Boolean
   estado = GameInput.Mouse_Hit(Left_Button)
   If (GameInput.Mouse.X < 100 And GameInput.Mouse.Y < 100) And estado Then
       Me.BackColor = vbRed
   ElseIf (GameInput.Mouse.X > 100 And GameInput.Mouse.Y < 100) And estado Then
       Me.BackColor = vbGreen
   ElseIf (GameInput.Mouse.X < 100 And GameInput.Mouse.Y > 100) And estado Then
       Me.BackColor = vbBlue
   ElseIf (GameInput.Mouse.X > 100 And GameInput.Mouse.Y > 100) And estado Then
       Me.BackColor = vbYellow
   End If
   Me.Caption = GameInput.Mouse.X & ", " & GameInput.Mouse.Y
End Sub
Esta tarde con calma le echo un ojo al codigo y arreglo este detalle para no andar haciendo variables globales, que si no me equivoco tambien lo sufriran Key_Hit() y Joy_Hit() dado que usan el mismo sistema para recibir los datos.

Pues gracias por la informacion, otro bug que localizo para solucionar en la proxima release :)

Salu2...

P.D.: Acabo de localizar otro bug en la funcion Joy_Hit(). Esta se dispara como verdadera si no hay un gamepad conectado a la maquina (fijate en el tutorial 4 sin tener conectado un gamepad)

[Hechelion]

El tema no deja de ser y no se si llamarlo BUG. Ya que como vas a diferenciar el llamado de la función desde partes distintas del código y que no sea precisamente la repetición de la misma función y se produsca dobles accesos. O sea, como saber si lo llamas desde 2 clases y no 2 veces desde la misma clase.

Como dice Robihm, lo ideal sería tener un evento desde el cual se dispara una cascada, pero esto, estando dentro de VB no es nada del otro mundo arreglarlo. Basta hacer una sola referencia al HIT y de ahí disparar un procedimiento que sería el equivalente al evento Mouse_Hit. Más facil, y no vas a tener que darte 10.000 vueltas para corregir algo que yo no definiria como Bug (en especial al leer la ayuda).

Código [Seleccionar] Expand

'Rutina unica encargada de lectura de entrada del mouse por HIT dentro de un timer o como deseen hacerlo.
if input.Mouse_Hit(Left_Button) then Evento_MouseHit(0)
f input.Mouse_Hit(Middle_Button) then Evento_MouseHit(1)
f input.Mouse_Hit(Right_Button) then Evento_MouseHit(2)

'pseudo evento
Public   sub Evento_MouseHit(Key as integer)

end sub

A mi juicio no veo nada del otro mundo simular un evento desde VB. Ahora si la libreria lo logra hacer sola, genial, si no, para que ahogarse en un vaso de agua.

[RobiHm]

si lo del evento es fácil de hacer... pero no es el problema... todo surge cuando quieres guardar un orden de programación, no tiene sentido programar todos los clicks en un solo bucle... ya que resulta muy engorroso y no tiene mucha lógica... cada clase debe/puede tener como dice [EX3] su draw y su update/interacción y se debe programar en ese modo para evitar cientos de problemas que aparecen al no realizar una  seudo-"POO"

yo directamente hago esto en el inicio del bucle principal y me ahorro bastantes disgustos xD

Código [Seleccionar] Expand


       raton = m_Input.Mouse
       juego.m.mleft = m_Input.Mouse_Hit(Left_Button)
       juego.m.mright = m_Input.Mouse_Hit(Right_Button)
un saludo