Threads Y Vb

[[EX3]]

 Wenas, hace poco me ha dado la vena por trastear con los Threads en Vb (VB6, no VB.NET ojo) desde ke hace poco lei por ahi ke era posible. Encontre un ejemplo muy sencillito ke usa Threads en Vb y funciona a la perfeccion, pero ahora estoy intentandolo por mi cuenta y no tira ni para atras y eso ke lo estoy haciendo mas sencillo ke el ejemplo en si:

Ejemplo #1:

Código [Seleccionar] Expand

Option Explicit

Public Declare Function CreateThread Lib "kernel32" (lpThreadAttributes As Long, ByVal dwStackSize As Long, lpStartAddress As Long, lpParameter As Any, ByVal dwCreationFlags As Long, lpThreadId As Long) As Long

Public Handle As Long, Val As Long, Id As Long

Sub Main()
Handle = CreateThread(0, 0, AddressOf Proceso, vbNullString, 0, 0)

MsgBox Val
End Sub

Public Sub Proceso()
   Val = Val + 1
End Sub
Ejemplo #2:

Código [Seleccionar] Expand

Option Explicit

...

Sub Main()
Handle = CreateThread(0, 0, AddressOf Proceso, Val, 0, 0)

MsgBox Val
End Sub

Public Sub Proceso(Ret As Long)
   Ret = Ret + 1
End Sub
El primer ejemplo mediante la propiedad Err.LastDllError ke es equivalente a GetLastError() en VB segun la MSDN (GetLastError() no tira en VB) me devuelve el error 998: Invalid access to memory location y el segundo 1305: The revision level is unknown (este ultimo no lo entiendo). No veo ke hay en el codigo ke haga ke falle. Tan complejo es la creacion de Threads? Alguien ha programado alguna vez Threads en vb y ha salido vivo en el intento???
Dioss, kiero enrredar de "hilos" mis programas, por favor!!! (uoh)

Salu2...

P.D.: Lo ultimo ha sido locura transitoria por falta de sueño, no hacer mucho caso  :P  

[averbell]

 Para que sirven exactamente?

[[EX3]]

 Los Threads o "Hilos" son formas de poder ejecutar varios procesos "simultaneamente", justo al contrario de como lo hacemos tu y yo por ejemplo en VB, ke seria ejecucion unica y secuencial, vamos, ke hasta ke no acaba el primer proceso no se ejecuta el segundo. Con los threads puedes ejecutar los dos procesos a la vez y eso en juegos es algo muy util.

Salu2...

[NeLo]

"] Con los threads puedes ejecutar los dos procesos a la vez y eso en juegos es algo muy util.

No sé yo si realmente son útiles en juegos...

[[EX3]]

 

No sé yo si realmente son útiles en juegos...

Imaginate por ejemplo que kieres hacer una animacion fluida para la carga de un mapa en tu juego, no una barra de progreso si no algo moviendose por la pantalla o incluso varios sprites haciendo chorradas para entretener al jugador. Por un lado mandas el proceso de carga por un hilo y por otro ejecutas el proceso de la animacion, sin molestarse el uno al otro. Luego controlas todo mediante alguna variable boleana por ejemplo. No se, pero yo si le veo utilidad en un juego.

Salu2...

[NeLo]

"]

No sé yo si realmente son útiles en juegos...

Imaginate por ejemplo que kieres hacer una animacion fluida para la carga de un mapa en tu juego, no una barra de progreso si no algo moviendose por la pantalla o incluso varios sprites haciendo chorradas para entretener al jugador. Por un lado mandas el proceso de carga por un hilo y por otro ejecutas el proceso de la animacion, sin molestarse el uno al otro. Luego controlas todo mediante alguna variable boleana por ejemplo. No se, pero yo si le veo utilidad en un juego.

Salu2...

Prefiero bucles en los juegos, sin duda.

[[EX3]]

 Usar theads no implica abandonar los bucles, solo poder ejecutar mas codigo en menos tiempo  :P

Salu2...

[Warchief]

 La programación concurrente (multihilo) es tan útil para todo como difícil. Para mí, cualquier aplicación que tenga una interfaz visual debería llevar al menos dos hilos: Uno para seguir los eventos de interfaz y otro para la operación "costosa" en sí misma. (El ejemplo más sencillo es el contador del buscaminas).

(No en vano me he comprado un piv con HT  :P)

[NeLo]

 En programas de gestión les veo muchas más aplicaciones que en juegos.

A mi no me convencen para juegos.

Saludos.

[Warchief]

En programas de gestión les veo muchas más aplicaciones que en juegos.
A mi no me convencen para juegos.
Saludos.

Hombre, habría que encontrar alguna situación concreta, sí.
Quizá algo de IA adicional, no sé.
Operaciones con ficheros (autoguardado en estrategia por turnos), pero no suelen requerir grandes cantidades de cómputo.

[Zaelsius]

 Como estamos de off-topic y no creo(ojalá) que EX3 encuentre la solución a su problema gracias a nosotros... me voy a rayar un poco:

La programación multi-hilo en juegos de PC(hasta donde creo saber) se ha utilizado más poco.

Casos comunes pueden ser:

-Las rutinas de red: el hilo despierta al recibir un mensaje y responde tan rápido como es posible, reduciendo así los retrasos en máquinas lentas(si el juego fuese a 30fps, esperar a la siguiente iteración del bucle principal estaría añadiendo un considerable retraso de 33ms).

-Cargas en segundo plano: Praetorians según leí en un mensaje de Jare cargaba los sonidos una vez iniciada la partida en segundo plano. Si todos los FPS hiciesen lo mismo no nos dariamos cuenta de que tenemos un monstruo a la vuelta de la esquina al notar como se para el juego medio segundo XD.

-El ejemplo que comentaba EX3 de las animaciones mientras carga el juego: Pocos juegos de PC usan este sistema pero siempre es agradable.

En consolas (creo) el 2º caso es muy común en juegos como GTA3, Crazy Taxi, Driver, etc.. todos aquellos que van cargando continuamente datos desde el DVD mientras el jugador se desplaza por la ciudad. En PC por mucho que se optimice, el acceso al disco duro siempre penaliza notablemente(que se nota, no que sea crítico) el rendimiento general del sistema, de ahí que tengamos que tirar de montañas de RAM.

Aun así, la mayoria de los sistemas dedicados a juegos han sido hasta ahora monoprocesador, con lo cual el argumento de ejecutar más código en menos tiempo no es válido(salvo para los P4 HT). Pero ahora parece que la industria tiende a sistemas multiprocesadores(rumores sobre la XBox2, PS3, y realidades como los G5 , NDS, y los próximos micros "multi-core" de AMD e Intel para escritorio).

Aprovechar estos sistemas ya es más difícil, y aunque a corto plazo no creo que aparezcan juegos que hagan un buen trabajo en este sentido, creo que con el tiempo veremos resultados. Tal vez sean IA's acojonantes, o simplemente la posibilidad de dejar aplicaciones en 2º plano mientras jugamos sin más penalizaciones que la de memoria consumida.

:rolleyes:


Pos eso.

[[EX3]]

 En resumen, ke en la actualidad "aun" no tendria mucho sentido utilizar Threads en un juego, no? Yo era mas ke otra cosa por darle un poco de empujon al lento y perezoso VB, pero vamos, ke al paso ke voy me va a dar igual, el no pone de su parte  :D

Salu2...

[Warchief]

 

Aun así, la mayoria de los sistemas dedicados a juegos han sido hasta ahora monoprocesador, con lo cual el argumento de ejecutar más código en menos tiempo no es válido(salvo para los P4 HT). Pero ahora parece que la industria tiende a sistemas multiprocesadores(rumores sobre la XBox2, PS3, y realidades como los G5 , NDS, y los próximos micros "multi-core" de AMD e Intel para escritorio).

Aprovechar estos sistemas ya es más difícil, y aunque a corto plazo no creo que aparezcan juegos que hagan un buen trabajo en este sentido, creo que con el tiempo veremos resultados. Tal vez sean IA's acojonantes, o simplemente la posibilidad de dejar aplicaciones en 2º plano mientras jugamos sin más penalizaciones que la de memoria consumida.

Buen post. Una pequeñísima anotación:

Un monoprocesador también debería poder beneficiarse de una aplicación/juego multihilo. Un hilo puede quedar bloqueado esperando un recurso compartido (con otro proceso) y dar paso a otro hilo del mismo proceso, con lo que no hay cambio de contexto del proceso y se gana un poco. Aunque reconozco que el coste de implementación frente a la ganancia....


De todas formas, sigo pensando en el ejemplo del contador del buscaminas. Cualquier juego con un contador de tiempo podría llevar ya dos hilos (carreras de coches, desactivar explosivos...) , aunque entramos en el terreno de compensar el paso de tiempo real con el paso de tiempo en el juego; tema que no me gusta naaada  (nooo)  

[Grugnorr]

 Programación asíncrona para seguir con la ejecución de algo mientras se accede a un recurso tal como un fichero grande o una conexión de red larga.

PD: Os he dicho que .NET implementa lecturas asíncronas de streams(ficheros, conexiones red, llamadas a WebServices...) además de mucha funcionalidad "nativa", palabra reservada lock para hacer uso de un Monitor de forma sencilla y elegante...