Cita:
Iniciado por vangodp 
Si... Si es en un mapa de minecraft si. ¿Pero no se carga todos esos un millón de cubos?
En memoria te entra ese millón de cubos y varios millones más. Y no es algo que tenga que ralentizar el equipo. Es lo que te comenté... una cosa es la información lógica de los objetos que componen el escenario del juego y otra diferente es la geometría que llevas a la escena.
Para que el juego funcione de la forma más eficiente posible tienes que intentar que la geometría que llevas a la escena sea la mínima. Si puedes evitar la carga en escena de un objeto porque está tapado por otro, le evitas a la tarjeta gráfica la realización de bastantes cálculos... pero claro, eso es algo a implementar si ves que el juego se traba.
Cita:
Iniciado por vangodp No me desanimes con lo de los "equipos normalitos" que toy yo solo y me hace mucha ilusion. jajajaj
¿Desanimarte? ¿Por decirte que puedes ocupar 20 MB de RAM en 2 millones de cubos de minecraft sin problemas de rendimiento? No creo que te desanimes por eso :)
Cita:
Iniciado por kutcher Un vector no almacena sus datos en posiciones de memoria continua. Los punteros al principio y al final del vector se almacena en una ubicación diferente a la de los propios datos.
Tu puedes declarar un vector tal que:
Código C++:
Ver originalstd::vector< int* > vectorDePunteros;
En cuyo caso, efectivamente, los punteros estarán alineados y luego la ubicación física de los int puede estar en cualquier sitio... pero tambien puedes hacer
En cuyo caso los enteros están en posiciones de memoria consecutiva.
Es más, en cualquiera de los dos casos, el overhead con respecto a usar un arreglo tipo C es mínimo, de hecho en una de las respuestas puse el código de la implementación que trae mingw... lo dicho, el overhead tiende a cero compilando en modo release.
Cita:
Iniciado por kutcher - Un vector siempre asigna memoria para sus datos en el montón. La asignación en el montón es más lento de la asignación en la pila.
Es más lento... depende. Si guardas tipos básicos si, ahora, si tienes que estar metiendo en la pila objetos más pesados que además tienes que andar pasando como parámetros o funciones a otras funciones la situación se empieza a difuminar.
Se puede decir que la carga y descarga de datos desde la pila es más rápida... ahora en cuanto al acceso indirecto debido a punteros y referencias... teniendo en cuenta que los equipos actuales cachean la memoria por las condiciones de localidad y demás...
Que sí, que será más rápido... pero a veces esa rapidez es irrelevante y le solemos dar con frecuencia más importancia de la necesaria.
Cita:
Iniciado por kutcher Estos son algunos puntos por los cuales considero que en determinados casos un array de C seria mas rapido respecto a un std::vector, pero como ya dije esto depende del momento en que decidamos utilizar uno u otro
Yo aun no he requerido una potencia de cálculo tal que me haya visto obligado a usar un array de C en vez de un contenedor. Entiendo que habrá alguna situación en la que se de el caso... pero vamos, de momento no he visto el caso ni programando CADs ni máquinas de inspección por ultrasonidos en tiempo real.
Un Saludo