Foro de elhacker.net

Hola me pueden ayudar necesito descargarme el pthread.h y ncurses.h ¿me pueden decir dónde? por favor decírmelo cuanto antes :D

En qué sistema operativo estás?

En Windows 7

Descargar loa archivos pthread.h y ncurses.h no es suficiente, se debe instalar tambien el codigo objeto.

¿Que compilador que estas utilizando?

Un saludo

Si estás en windows 7 (por qué lo imaginaba?) lo que necesitas no es descargar esos archivos, es usar la API de tu sistema, no POSIX o ncurses.

A vale pues si podeis poned el link de todos los archivos que sean necesarios (incluyendo ncurses.h y pthread.h XD) porque es un amigo que los necesita para hacer un juego y mañana es su cumple y se lo voy a regalar  :D si podeis pasarmelo gracias

como puedo musar la api de mi sistema?¿

Si tu sistema es windows puedes usar obviamente la API de windows, aqui te dejo un enlace de como trabajar con la API de windows en tus proyectos de C/C++:

http://winapi.conclase.net/curso/index.php (http://winapi.conclase.net/curso/index.php)

Es muy raro que para un juego tengas que usar hilos...

si ya lo se  pero es que sino no podia hacer que sumara los puntos o que los restara

¿?

Puedes hacerlo en el hilo principal sin problemas.

¿En un juego de terminal? Puede ser ... ¿juegos en el sentido más amplio de la palabra? hacer programación multihilo es lo más normal y esperable si querés tener un juego que trabaje relativamente bien en las CPUs de hoy en día.
Casi todos los juegos que conozco usan progrmación multihilo desde cosas básicas como para gestionar sus tareas, hasta incluso cosas más "sofisticadas" como streaming de recursos (te atrevés a dibujar un sólo cuadro y bloquear para hacer I/O para preparar los recursos de la habitación que hay en frente del personaje y después dibujar otro cuadro y así? )

Saludos.

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.

Hola, Olvidarse de esas ridiculas librerias (pthread.h, etc) si es para entorno NT usar la Win API.
en cuanto a usar multihilo o no, Es de la necesidad que se requiera, no depende si es comercial o no, si de cuantas CPUs/nucleos, etc.
Mirar esos ridiculos "juegos" de consola de hace años no hay necesidad de agrega multihilo.

Me puedes explicar porqué son ridículas? Supongo que jamás las has usado no?

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

http://gnuwin32.sourceforge.net/packages/ncurses.htm

ncurses es facil pero pthreats es algo muy linuxero en eso te recomiendo buscar alternativas que las hay por montones incluyendo la api de windows o alguna libreria que maneje threats para hacerlo mas simple tambien puedes usar el antiguo

process.h que era para msdos pero aun se usa este te da la ventaja de ser muy simple y no tener que instalar nada  pero con pocas opciones

como opinion personal me parece que seria mas practico usar sdl que esta especialmente diseñado para hacer juegos pero bue no se que tengas en mente

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.

bueno tanto como secuencial no  es. es programacion dirigida por eventos pero de todas formas de doy la razon en lode los multihilos

Yo soy el primero que le he dicho que use la API de su sistema en vez de pthread y ncurses, pero de ahí a que sean ridículas hay un buen trecho.

Saludos.

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.



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.


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.

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.

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


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).

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 (http://pdcurses.sourceforge.net/) 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 (http://www.boost.org/doc/libs/1_53_0/doc/html/thread.html) de todas formas estas última requieren conocimientos más avanzados.

Juegos AAA, ok.


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
 

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.

Tomo nota del término.

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)

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:


Cosas como la física por ejemplo.