ncurses.h y pthread.h ¿donde lo puedo descargar?

[Luz Violeta]

Pero no hablamos de un juego comercial. Para juegos normales no es normal usar multihilo, puesto que la carga gráfica es irrelevante y todo es secuencial.

Comercial o no comercial es algo que nunca mencioné o valoré ... y con decir "Para juegos normales no es normal usar multihilo, puesto que la carga gráfica es irrelevante y todo es secuencial" demostrás una enorme ignorancia en la programación de motores de videojuegos.

No se trata de si el juego se vá a vender o no.
No se trata de si estresás mucho la GPU o no.
No se trata de "normalidad" (evitemos esa palabra tan imprecisa)

Usar varios hilos tiene poco y nada que ver con eso (salvo últimas movidas donde se usa multihilo en APIs gráficas, que ahí se entra a hilar más fino en varias otras cuestiones) ... sino de cómo organizar todo lo otro que sucede en un juego y evitar todo el bloqueo que sea posible (que según la complejidad del juego, puede ser más o menos difícil ... y evitar los bloqueos más o menos estándar o más o menos engorroso que ir directamente por una programación multihilo)

Input
Física
Scripting (Si compete)
Gestión de recursos
Networking (Si compete)
AI
Multimedia (Audio/Video, blah)
Sistema
Resto de tareas del motor (Que pueden interactuar con las otras partes, como la GUI con el sistema gráfico o la gestión de recursos con sistema o multimedia con gestión de recursos)

Y ahí después de TODO ESO, podemos hablar de gráficos ... a veces hacemos un gran tema de los gráficos en los juegos, pero si hablamos en líneas código lo más complejo suele ser coordinar con todo lo otro.

Hola, Olvidarse de esas ridiculas librerias (pthread.h, etc) si es para entorno NT usar la Win API.
[...]
Mirar esos ridiculos "juegos" de consola de hace años no hay necesidad de agrega multihilo.

Si, por que en definitiva si usás un pthread para Windows (¿hay? alguien confirme, por que creería que sería más fácil portear herramientas de mingw/msys/blah creando wrappers que dándole con preprocesador y abriendo más focos de bugs y complejidad en el código) ... esa librería por lo bajo usaría la API de Windows.

Y para hacer juegos por consola si bien no necesitás multihilo, tenés que manejar el input de manera no bloqueante (por que sí, las operaciones de I/O son bloqueantes) ... y eso puede ser más horrendo que abrir un hilo y gestionar el asunto por aparte.

Personalmente, se me ocurren pocas razones para ello puesto que en un juego casi todo es secuencial.

Las únicas situaciones que se me ocurren es para aliviar carga gráfica, como dicen antes.

Si no sabés o sabés a medias, no te pares a enseñar ... la gente como vos me dá bronca.
Si seguís en esa postura, quiero YA mismo una argumentación formal de cómo la programación multihilo "alivia carga gráfica" (¿qué onda? por que aparezca un hilo la gráfica se vuelve mágicamente más copada con la geometría que le mandes? se siente más tranquila y por eso se "alivia"? no empecemos con la pavada)

Saludos.

[amchacon]

Comercial o no comercial es algo que nunca mencioné o valoré ... y con decir "Para juegos normales no es normal usar multihilo, puesto que la carga gráfica es irrelevante y todo es secuencial" demostrás una enorme ignorancia en la programación de motores de videojuegos.

No se trata de si el juego se vá a vender o no.
No se trata de si estresás mucho la GPU o no.
No se trata de "normalidad" (evitemos esa palabra tan imprecisa)

Aver, cuando me refiero a comercial me refiero a grandes desarrollos (Call Of Duty, Far Cry, Need For Speed...). Los juegos Indie también podrían entrar a partir de un cierto nivel.

Input
Física
Scripting (Si compete)
Gestión de recursos
Networking (Si compete)
AI
Multimedia (Audio/Video, blah)
Sistema
Resto de tareas del motor (Que pueden interactuar con las otras partes, como la GUI con el sistema gráfico o la gestión de recursos con sistema o multimedia con gestión de recursos)

Volvemos a lo mismo, no hablo de grandes producciones.

Y no se programa a tan bajo nivel. Generalmente se ayuda de librerías gráficas que te resuelven ese tinglado (si se ayuda de hilos ni me va ni me viene). Realice un juego de la serpiente, pensé en aumentar su rendimiento con multihilo pero no veía donde optimizar. Su algoritmo era:

- Comprobar colisiones-pared.
- Comprobar colisiones-comida.
- Mover la serpiente.
- Detectar cambios de dirreciones (por teclado).
- Dormir el proceso durante 15 segundos.

No puedo comprobar las colisiones hasta que no haya movido, y su movimiento depende de la respuesta del usuario. Este ejemplo se puede extrapolar a un mata marcianos que hice y a otro juego de puzzles que realicé:
https://dl.dropboxusercontent.com/u/69551225/Snake%20-%20Amchacon.rar
https://dl.dropboxusercontent.com/u/69551225/MataMarcianos%20-%20Amchacon.rar
https://dl.dropboxusercontent.com/u/69551225/Puzzle%20-%20Amchacon.rar

Si no sabés o sabés a medias, no te pares a enseñar ... la gente como vos me dá bronca.
Si seguís en esa postura, quiero YA mismo una argumentación formal de cómo la programación multihilo "alivia carga gráfica" (¿qué onda? por que aparezca un hilo la gráfica se vuelve mágicamente más copada con la geometría que le mandes? se siente más tranquila y por eso se "alivia"? no empecemos con la pavada)

Leáse mi mensaje (Personalmente). No era una enseñanza sino una opinión personal. Una hipótesis.

Y la hipotesis se basa en trabajar distintas partes simultáneamente. Evidentemente, para ello necesitas un procesador de varios núcleos.

De hecho, incluso están saliendo gráficas con dos hilos de procesamiento (La AMD 7990 por ejemplo).

[RyogiShiki]

No empezaremos un Linux VS Windows Cierto?
Es obvio que si es para entorno Windows librerias que mencione no dan lugar aquí.

nadie va a inicia un flame. Eso de lanzar afirmaciones al aire sin ver donde caen, no es la mejor manera de responder. En todo caso es posible usar la librería ncurses en sistemas NT gracias a la implementación PDCurses y bueno para multithreading (sin entrar a debatir si es necesario o no) pues para garantizar la portabilidad entre plataformas bien se puede usar las librerías boost de todas formas estas última requieren conocimientos más avanzados.

[Luz Violeta]

Aver, cuando me refiero a comercial me refiero a grandes desarrollos (Call Of Duty, Far Cry, Need For Speed...). Los juegos Indie también podrían entrar a partir de un cierto nivel.

Juegos AAA, ok.

Y no se programa a tan bajo nivel. Generalmente se ayuda de librerías gráficas que te resuelven ese tinglado (si se ayuda de hilos ni me va ni me viene). Realice un juego de la serpiente, pensé en aumentar su rendimiento con multihilo pero no veía donde optimizar. Su algoritmo era:

No siempre se trata de rendimientos y te lo señalé en mi anterior post.
No es una locura empezar a usar hilos (o *incluso* procesos) una vez dada una base muy fina laburando sobre secuencial, incluso para desarrollos chicos ... muchos algoritmos muy comunes en el área de videojuegos son moneda común de usar en entornos multihilo (o incluso están diseñados para); y también a la hora de entender el diseño de varios game engines.

Y para dar diseño de motores, antes tenés que conceptos básicos de programación y de sistemas (entre los que están la programación paralela y concurrente) ... sino you're doin it wrong

Y la hipotesis se basa en trabajar distintas partes simultáneamente. Evidentemente, para ello necesitas un procesador de varios núcleos.

De hecho, incluso están saliendo gráficas con dos hilos de procesamiento (La AMD 7990 por ejemplo).

Que haya dos GPUs no modifica para nada lo que programás (salvo casos en particular), ya que antes hay un driver y éste es el que hace scheduling de tareas ... se vino haciendo siempre para que juegos que no están pensados para setups como dos GPUs enganchadas por SLI/Crossfire puedan correr sin el más mínimo drama repartiendo la carga entre ambas GPUs usando un algoritmo u otro de scheduling;  que ahora esté integrado en un paquetón no significa nada a esta altura del partido.

Me parece que estás confundiendo conceptos.

Saludos.

[amchacon]

Juegos AAA, ok.

Tomo nota del término.

Que haya dos GPUs no modifica para nada lo que programás (salvo casos en particular), ya que antes hay un driver y éste es el que hace scheduling de tareas ... se vino haciendo siempre para que juegos que no están pensados para setups como dos GPUs enganchadas por SLI/Crossfire puedan correr sin el más mínimo drama repartiendo la carga entre ambas GPUs usando un algoritmo u otro de scheduling;  que ahora esté integrado en un paquetón no significa nada a esta altura del partido.

Me parece que estás confundiendo conceptos.

Saludos.

No, te has confudido con mi ejemplo.

Lo que quería decir que el desarrollo multihilo puede acelerar la carga gráfica (por parte de la CPU). La prueba esque las gráficas de gama alta están apostando por ello en sus GPU.

[Luz Violeta]

No, te has confudido con mi ejemplo.

Lo que quería decir que el desarrollo multihilo puede acelerar la carga gráfica (por parte de la CPU). La prueba esque las gráficas de gama alta están apostando por ello en sus GPU.

Las gráficas siempre laburaron de manera paralela ... te estás enredando y me estás tirando el tema para otro lado, sé sincero y decí "bueno, no entendía bien del tema y mandé cualquiera" (hace bien)

[amchacon]

Las gráficas siempre laburaron de manera paralela ... te estás enredando y me estás tirando el tema para otro lado, sé sincero y decí "bueno, no entendía bien del tema y mandé cualquiera" (hace bien)

Sigo diciendo que no has entendido lo que quería decir.

Cuando decía que el multihilo podría servir para aligerar carga gráfica estoy seguro de que tengo razón:

La hipotesis se basa en trabajar distintas partes simultáneamente. Evidentemente, para ello necesitas un procesador de varios núcleos.

Cosas como la física por ejemplo.