Mensajes

Aprende inglés. En programación, los mejores tutoriales y la mejor documentación va a estar disponible únicamente en inglés.

No soy experto en CUDA. Sobre este tema únicamente tengo algunas nociones básicas.

Si se que para sincronizar elementos tienes que utilizar mecanismos de exclusión mutua (si toqueteas variables comunes), pero poco más al respecto.

Quizás deberías buscar algún manual de CUDA en Internet.

Siento no ser de más ayuda.

Un saludo.

Tu problema se debe a un mal diseño.

La respuesta simple es que lees del teclado en funciones diferentes, por lo que si decides mover la nave pero la pulsación de la tecla la recibe la función que lanza las balas... pues ni lanzas bala ni te mueves.

La respuesta técnica es que estás asignando demasiadas responsabilidades a las clases:

* La clase nave debería encargarse de almacenar la información de la nave. No debería saber pintarse ni tampoco interpretar las teclas para moverse. Lo mismo es aplicable para bala y asteroide

* Para pintar el escenario lo ideal sería tener una clase nueva, por ejemplo class Escena, a la que le facilitas la nave, los asteroides y las balas y ella se encarga de representar todo

* El control del teclado debe estar centralizado en un único punto y, en función de la tecla que se pulse, realizar una acción u otra.

Tu piensa que una clase no debe ser algo mastodóntico. Es mucho mejor crear clases sencillas con responsabilidades bien definidas. Si, por ejemplo, cargas a la clase "Nave" con la responsabilidad de saber pintarse y después resulta que tienes que hacer que el juego funcione tanto en consola como con opengl, vas a llenar la clase de código que no necesita... eso es mejor dejárselo a otra clase diferente.

Un saludo.

Para usar CUDA tienes que cargar una extensión en el compilador. Esta extensión añade ciertas características que no están presentes en una compilación típica y es lo que permite que se puedan ejecutar ciertas sentencias de forma paralela usando la tarjeta gráfica para ello.

Por cierto, ten en cuenta que no se puede depurar el código que se ejecute en la tarjeta gráfica, así como tampoco su memoria, así que suele ser una buena práctica probar la mayor parte del código en una compilación sin CUDA.

Un saludo.

¿C, C++, C++11?

Si lo quieres hacer a mano, siempre puedes coger, en cada iteración del for, un hilo de un pool (si no hay disponibles, esperas) y al hilo asignarle la tarea correspondiente. Una vez finalizada la tarea devuelves el hilo al pool y continúas con la ejecución.

[run()]

Y ahora estoy a tope con C++.

Si pretendes dominar C++, más vale que le dediques varios añitos... no es algo que se pueda controlar al 100% con un par de añitos de experiencia

Una funcion run() llama a Act(), Paint() y run() (si se llama a sí misma). Esta ultima pasados 0.017s.

Eso se llama recursividad... si intentas hacer eso en un juego programado en código nativo, el juego va a morir en un par de segundos porque te has quedado sin pila. Lo más normal es que la función "run" tenga un bucle que ejecute "Act()", "Paint()", y añada una pausa del tiempo que sea necesario... sin recursividad.

Busco hacer juegos a base de puro codigo. Nada de usar motores externos que despues dan errores que no tienen nada que ver con mi codigo. (Eso mismo me paso con Blender y por eso lo dejé de lado.)

Para diseñar ese juego vas a hacer uso de la librería estándar... que aunque funciona estupendamente no está exenta de algún que otro bug.

Además también te vas a tener que apoyar en el sistema operativo... que también suelen ser famosos por tener bugs.

Moraleja: No tengas tanto miedo a usar librerías externas. Una cosa es que quieras aprender y por eso decides reinventar la rueda, pero a la hora de la verdad hay que ser práctico.

Lo que quiero saber es: ¿Hay algo como el run() que acabo de explicar? ¿Se puede hacer en C++ que una funcion se llame a sí misma al cabo de X segundos o milisegundos sin que en ningún momento el programa quede como "no responde"? ¿Como lo hago exactamente? (se coger las teclas pulsadas y el ratón con OpenGL [mas o menos...])

* En C++ no hay nada expecífico como el run() que acabas de comentar
* En C++ se puede programar la recursividad sin ningún problema... eso si, si no le pones límite, tu programa no saldrá bien parado
* Ejemplo de recursividad:

Código (cpp) [Seleccionar] Expandir

void func( )
{
 printf( "1" );
 func( ); // Se llama a sí misma
}

int main( )
{
 func( );
}

(lo ideal como respuesta es: sentencia(parametros), forma de uso de la sentencia, librería necesaria para usarla y tipos de los parametros [int, double, char, string, boolean, matriz, tupla].)

Esta información podría ser útil si utilizases una librería externa para el motor gráfico, como no es así te lo tienes que currar todo tu.

- Utilizo Codeblocks 13.12.

El IDE que uses no es relevante. Eso únicamente te afecta a tí, asi que lo mejor es elegir uno con el que te sientas cómodo.

- Estoy enfocado a usar OpenGL. (Por cabezonería. No pienso en hacer juegos DirectX.)

Pues fíjate que DirectX obtiene mejores rendimientos y es más portable (dentro de las diferentes versiones de Windows y de tarjetas gráficas) que OpenGL, aun así tienes tus motivos y es una opción perfectamente válida.

PD.: no me apetece iniciar un debate sobre qué es mejor OpenGL o DirectX.

En Resumen. En C++ puedes hacer lo que te propongas, pero al ser un lenguaje de más bajo nivel que javascript, vas a tener que estar más atento a lo que haces... aquí no hay barreras y es muy fácil salirse del camino... eso sí, la satisfacción de hacer un programa completo compensa

Un saludo.

1. No se hacen tareas
2. No escribas en mayúsculas
3. No escribas como si el foro fuese un móvil

Quizás deberías hacer una espera basada en señales.

Revisa el siguiente enlace.

Un saludo.

Creo que o no te has explicado bien o no he sido capaz de entender el problema.

En cualquier caso. En el código que has puesto:

Código (c) [Seleccionar] Expandir


do {
fseek(f_read,SEEK_SEY,0);//colocamos alprincipio del fichero
in read =fread(bufr,ftell(f_read),10, f_read);
delayMidrodeconds(50);
}while(bufr!=2)


cambiando fread por una lectura bloqueante del socket ya no tienes problemas con el procesador... e incluso puedes quitar el do-while, el delay y, por supuesto, el fseek que sobra en cualquier caso.

Imagino que el socket será TCP. El caso es que el socket deberías leerlo con "read", no con "fread". Además, hacer "fseek" sobre el socket no parece demasiado recomendable, ya que cuando tu lees datos de un socket el sistema borra el contenido ya leído para hacer hueco.

No he programado aún una Raspberry, pero ese es el funcionamiento esperado en PCs.

PD.: La lectura "read" es bloqueante salvo que en el socket se indique lo contrario... y esa espera no debería consumir CPU.

Un saludo.