Lo que estás experimentando se llama "draw call overhead" y en este caso la culpa es de Irrlicht y de Direct3D a partes iguales.

La simplicidad de Irrlicht se paga, y es que la última vez que miré (hace ya tiempo), abusaba mucho de buffers intermedios para todo (no solo por los datos para DrawPrimitiveUP sino incluso para conversiones,listas de objetos visibles y demás).

Soluciones:
- Por la parte de Direct3D, no uses muchos objetos de poco tamaño, sino pocos buffers con mucha geometría, si es que te es viable. A ésto se le llama "batching".
- Por la parte de Irrlicht, supongo que será mejor mantener en tu grafo de escena solamente lo que sea visible e ir añadiendo y quitando nodos en cada frame en lugar de mantenerlo siempre todo dentro y ocultarlo/mostrarlo.

EDITO: Aunque visto lo visto, miedo me da pensar en como gestiona la lista de hijos de cada nodo del scenegraph.

No se la manera de hacerlo en CodeBlocks, pero alternativamente, si borras el fichero ejecutable/dll y le das a generar pues se limitará a linkar ya que todos los ficheros objeto están actualizados.

CodeBlocks soporta scripts asi que no creo que sea muy complicado hacer una y que te la muestre en el IDE.

Gracias por las respuestas.

No es para fines artísticos, es para cacharrear con las señales y su espectro.

¿ Hay algún programa gratuito o de prueba que permita manipular con herramientas de dibujo el espectrograma de una pista de audio y que lo reinterprete para reconstruir la señal correspondiente ?

Me vale también exportar un trozo de la señal a una imagen, manipularla en photoshop y poder reimportarla como espectro.

Audacity me permite ver el espectrograma pero no puede exportar/importar el espectro.

Hay un programa para Mac OS X que se llama Frequency pero no es de windows y parece desaparecido de la faz de la tierra.

Me veo programándolo yo y la verdad es que preferiría evitarlo.

Gracias.

Ya que a muchos solo les va a valer una regla que clasifique los juegos según están acostumbrados los comunes de los mortales, propongo profundizar en lo que ha dicho Mars Attacks.

El plantea como criterio clasificatorio que haya coincidencia entre la visualización y la jugabilidad (no la simulación), y si no son coherentes es un híbrido. Queda como cabo suelto el tema de la jugabilidad.

Expandiendo ese concepto, el siguiente paso lógico sería sustituir la jugabilidad por el esquema mental que se forma el jugador para resolver el juego.

Es decir, que el jugador tenga que pensar en 2D o en 3D para manejar el juego y que ésta representación coincida con la visualización. Si no coincide, es 2.5D, y si coincide pues lo dicho.

Si las dimensiones de la simulación (el mundo "lógico") son 2D el juego es 2D.

Hay muchos juegos 2D que usan APIs 3D:
Ghost & Goblins de PSP
Drácula Twins
Todos los juegos casuales que usan Direct3D para pintar los sprites.

A veces algunos módulos del programa usan más dmensiones de las necesarias por comodidad. Éstas dimensiones son linealmente dependientes de las reales, digamos que son ficticias. Te pongo un ejemplo:

Pongamos el caso del Drácula Twins de Nerlaska, por aquello de barrer para la piel de toro.
Los personajes se mueven a lo largo de un rail y las colisiones y la IA son perfectamente parametrizables en 2D.

Te mueves derecha a izquierda (a lo largo de una ruta predefinida en x,y) y arriba a abajo (Z). Las dimensiones de tu mundo son 2: el par ("parámetro", altura) donde parámetro es un índice dentro de la spline que define el rail.

Las coordenadas x,y son linealmente dependientes de la dimensión "parámetro". La altura es una dimensión en sí misma por ser ortogonal a la otra (no la puedes calcular en base al "parámetro").

Es un juego 2D en toda regla. La visualización sí es 3D.

¿ mande ?

Yo sí que te entendí pero precisamente en lo que he venido insistiendo es en que no es un problema ambiguo, dependiente de la experiencia, no es una opinión ni un punto de vista, sino que hay un criterio comprobable, medible y reproducible por terceros.

Otra cosa es que a nadie le importe o no se lo hayan planteado y optemos por el socorrido "yo siempre lo he llamado así" y todos contentos. Sabes que estás en esta situación cuando la tendencia general, y no digo que sea éste caso, es a dar ejemplos de lo que considera SI y ejemplos de lo que considera NO  en lugar de exponer una regla que pueda estar sujeta a escrutinio.

En el caso del parallax el problema es que el número del plano no es una característica del mundo sino de la visualización. Podrías haber añadido a tu estructura de datos un campo para ordenar por tamaño de sprite o textura y eso no lo convierte en propiedad del mundo (también llamado simulación), seguiría siendo de la visualización.

Si te preguntas como distinguir una propiedad del mundo de una de la visualización, preguntate si ésta es relevante para la IA de las entidades o para las físicas del juego. Si el plano parallax no es una dimensión espacial que se use en las ecuaciones de físicas ni, por ejemplo, afecte al pathfinding pues va a ser que es un truco visual.

Con eso último ya sabes que juegos parallax son 3D y cuales no, aunque la visualización sea siempre 2D por capas.

Pero vamos, que a la mayoría todas estas distinciones les dará exactamente igual. Que tenga vóxeles o poligonos y me pueda girar en cualquier ángulo. Donde esté la intuición del compañero o el interés del responsable de márketing que se quite la lógica  >:D

Si las coordenadas que maneja el motor para representar posiciones en el mundo son de 3 componentes espaciales, un motor es 3D. Fijáos que he dicho posiciones y no he incluido las orientaciones.

Como eso incluye llamar motor 3D a un juego isométrico que cumpla lo anterior, y eso le rechinará a muchos, pues apliquemos éste baremo solo a la posición y orientación de la cámara, y sobre todo, digámoslo con ámplias y cálidas sonrisas de vendedor de crecepelo.

Visualización vs Representación. Que hay que quedar bien con todos  >:D

Se le suele llamar 2.5D pero es un motor poligonal 3D en toda regla. Lo que no tenía eran 6 grados de libertad para la cámara.

No era raycasting. Simplemente se limitaban las características de la geometría poligonal para ahorrar cálculos al rasterizar y transformar los vértices. Vamos, que casi todas las componentes de cada vértice estaban implícitas.

Toda la  geometría del escenario se almacenaba en un árbol BSP, como en los motores de Quake, solo que la mayoría de los datos estaban de manera implícita y solo se almacenaba tal cual la proyección vertical del polígono (una línea 2D) y referencias a los suelos techos a cada lado de la línea (para los escalones, suelos y techos).

Usar billboards para los objetos en lugar de mallas no cambia la naturaleza del entorno.
.
La única concesión que se le puede hacer respecto a llamarlo raycasting es que las coordendas de textura no se interpolaban desde los vértices sino que se calculaban vectores para cada scanline del polígono usando la orientación de la cámara y el ángulo del polígono. Eso es mucho estirar la definición de raycasting. No había ni celdas ni matrices de nada para las paredes excepto para el motor de colisiones, pero no para el renderer.

Me podría tirar horas hablando del algoritmo del DOOM, pero no es lo que han preguntado. Es un motor 3D en mi opinión, aunque aceptamos barco (2.5D) ya que intuitivamente la mayoría de la gente entiende por 3D lo que ya han comentado por aquí.

Quítale las comillas a los números 1,2,3,4 en los case. Cuando les pones las comillas estás usando el código que representa al caracter 1 en lugar de usar el número 1. Concretamente, '1' equivale al número 49.

Si pruebas el programa tal como lo tienes y escribes por teclado 49 te ejecutará el case '1'.

Lo dicho, quita las comillas en los case.

Lo normal es que al final acaben llevándose agradecimientos o puntuaciones positivas los que se limitan a poner chorradas en hilos offtopic y hacer demagogias en hilos de flames. Y es que te llevas más puntos de un bando por soltar "verdades como puños" (noténse las irónicas comillas) en hilos cargados emocionalmente que por resolver una duda sobre un algoritmo compllicado.

Además, ¿a quién le importa la reputación en un foro? Que pesen los argumentos, no los puntos.

PD: Entonces, ¿pintamos la bici de azul, no?

[< > # [ ] { } ' | \]

Mírate los Thinkpad de Lenovo. La serie X (ultrailgeros) se te sale del presupuesto (1200$ para arriba) pero lo mismo la serie T (más grandes) tiene algo de tu interés.

Compres el portatil que compres que sea con disco duro convencional, nada de discos flash (SSD). Compilar proyectos es un caso degenerado de rendimiento para los SSD (escrituras fecuentes de archivos pequeños) dado que las operaciones de remapeado (write leveling) en los SSD actuales tienen una granulariad de MBs no de KBs.

El cuello de botella a la hora de compilar estará en el acceso contínuo al disco duro (son de 2.5" y leeentos), así que no me preocuparía por el micro o la memoria.

Asegurate de que la pantalla es mate, no reflectante.
Comprueba que el teclado no te obliga a hacer malabares para sacar los símbolos
< > #  [ ] { } ' | \
como programador perjudica bastante que para pulsar alt gráfico o sacar un ">" tengas que tener pulsada la tecla de función alternativa.

En definitiva: examina el modelo de portátil físicamente en alguna tienda aunque luego lo compres por intenet.

Elige un punto del personaje como un punto de anclaje del arma y una orientación respecto a ese punto. Las coordenadas de ese punto son relativas al modelo del personaje. Convierte esa traslación y rotación en una matriz. Llamémosla matriz relativa.

Ahora piensa: ¿ que ocurre si para pintar el arma usas exactamente las mismas matrices que para el personaje ? Pues que te sale el arma en la barriga del personaje o entre los pies, según donde tenga el personaje su punto (0,0,0).
¿ Pero a que el arma se gira a la vez que el personaje ?

Pues limitate a premultiplicar la matriz relativa por la del personaje y ya tienes la matriz a usar.

El arma siempre tiene que girar los mismos grados que el personaje, solo que sus puntos no han de estar centrados en (0,0,0) sino que has de aplicarle antes la posición relativa de la mano como traslación y el ángulo del brazo antes de aplicar la rotación.

Ese desplazamiento y rotación es el que tenga el personaje en ese fotograma de animación por lo que lo suyo es que lo cojas de un hueso tras haber animado.

Para desarrolladores nVidia sin duda alguna!

Y para players... nose nose, en nVidia tienen mucho pixel shader que es lo que hoy en dia se necesita con tanto filtro.

¿ Porqué nvidia para desarrolladores? ¿Por CUDA?

En cuanto a shaders precisamente es ATI la que va más sobrada, mirate las hojas de especificaciones. Hablo del número de unidades de shader.

De todas formas estoy con matriax en lo de comprar tarjeta ahora. Por eso proponía usar una placa base con gráfica integrada y esperar unos meses.