Guau...
No resulta adecuado hacer afirmaciones sobre cosas que uno no tiene ni idea. Hubiera sido más adecuado si te limitaras a hacer las preguntas que te parezcan y ya.
proceduralismo
Esa palabra no existe, se dice procedimental.
Los diseños procedurales ahorran el procesamiento continuado, ¿no?, sino que cargan en memoria rom lo que procesan en un principio, lo memorizan recurriendo a un espacio rom mínimo (lo que ocuparía un archivo de partida guardada) que interpreta una base de datos de estructuras y luego ya no hay carga ninguna...
No. Ahorran memoria, no procesamiento.
Tener una única copia de x procedimiento, permite simplemente separar los datos de la funciónalidad. Los datos serán tantas copias como instancias cuasi-simultáneas precisen esa funcionalidad mientras esté cargada en memoria.
Tampoco es radicalmente así, a veces se opta por hacer funciones que se denomina 'inline', es decir funciones muy reducidas es más rápido procesarlas con su propia función y destruída al terminar... a fin de cuentas cualquier funcionalidad que deba tratar con distintos punteros de acceso a datos, precisa ser convenientemente canalizado, lo que consume algo de tiempo que para pequeños procedimientos, resulta más rentable el tiempo que la memoria usada.
Creo que esto se podría aprovechar por ejemplo para juegos de un solo jugador y para ahorrar recursos de procesamiento, por ejemplo, dando forma a todos los objetos estáticos (árboles, edificios y tal, que son la mayoría) y poniéndoles una textura procedural también que se memorizaría en un archivo de partida que dependería más de la velocidad de lectura del ''disco duro'' que de procesador y gráfica.
Esto es relativo (al momento crítico de la Historia en que se aplique).
Hoy día los procesadores gráficos son tan eficaces, que se puede calcular algo 20.000 veces antes que cargar eso que tu dices una sola vez de disco.
En el pasado aunque los procesadores eran más lentos, la memoria en disco tampoco iba sobrada e iba más lento, por lo que por lo general es el propio programador el que evalúa al momento del diseño (y pruebas de rendimiento), qué caso se aplica mejor, indistintamente de que a futuro la cosa cambie... se diseña para 'ahora'.
No hay una solución universal... como tu pretendes, depende del caso y el hardware con que se cuenta.
Mucho más complicado sería explicar creo como movían los 33 mhz de la Play1 el Diablo 1 hace 20 años
No temrino de entender...
Básicamente cuando el sistema es crítico, o se baja resolución o se optimiza el código... si no basta en última instancia pueden diseñarse en ensamblador ciertas partes críticas. Tampoco ocnfundas el procesador (CPU), con el procesador gráfico (GPU).
Además da igual la velocidad de proceso, incluso aunque funcionara a 1Mhz, si luego hay 200 unidades de paralaje, pués se procesan 200 unidades al mismo tiempo.
En las GPU, hay largos conjuntos de instrucciones que s eprocesan en paralelo, porque son funciones muy frecuentes y harto conocidas, además están especializadas precisamente para las funciones gráficas.
...mi opinión es que será todo lo enrrevesado que quiera lo que planteo, pero de algún modo pienso que si un Petium 4 puede mover un vídeo a 1080 sin problemas..., es que no lo se, porque como actualizamos los equipos, pero tengo un netbook de 10" con oprocesador Atom a 1'6 ghz, del 2010, que con Xubuntu 21.10 mueve el 720p casi bien, y por supuesto sobra resolución ahí para esa pantalla por un tubo. Pues creo que a una resolución menor se podrían casi equiparar los frames que es capaz de mover de forma que una película sea fotorrealista, a que un videojuego lo hiciese porque la carga en directo del procesador se reduciría a sólo un poquillo más que con el vídeo puro y duro...
No se debe hablar tan a la igera con suposiciones... las suposiciones van bien cuando no hay forma de saber algo a ciencia cierta o cuando algo carece de importancia técnica la exactitud.
Cuando se habla de resolución hay que hacer los cálculos para saber lo que se está indicando: ancho en pixeles * alto en pixeles * bits por píxel * frames por sg. así puedes comparar cuan distintas son dos resoluciones entre sí...
El vídeo sin embargo, es algo grabado, tan solo comprimido... un juego debe calcular las escenas, desde posiciones, tamaños, texturas, luces, etc... no es una comparativa 'honesta', de hecho es como comparar peras con sombreros.
Todo se basa en un ejemplo que le puse a un antiguo amigo que un día dejó de publicar en Facebook y no volví a saber de él. Le dije que hiciera (yo no se programar) un cuadrado que creciese por todos los lados al pulsar la flecha de arriba, y él lo hizo en no llegaría a un minuto de tiempo, y le dije: ahí tienes el 3d.
La ignorancia no es mala por sí misma, peor cuando se saca a pasear con orgullo...
...a ver si he entendido tu haces aumentar un cuadrado por los 4 lados y los que tienes es un cuadrado más grande cada vez, además hay que comprensar su posición, y desde luego yo no veo ahí ningún 3d, como tu lo llamas.
La perspectiva (que es lo mas parecido que puedo concluir) de la cordenada z (distancia), también debe ser calculada... todos esos cálculos 3d, Rotación, posición, tamaño, perspectiva se hacen con multiplicación de matrices, luego es algo bastante simple por sí mismo. Es la cantidad de detalles, la enorme cantidad... lo que puede ralentizar el cálculo.
Bueno, decidme de momento si le veis utilidad/razón al menos a lo primero que he dicho, a ver si puedo pensar en esto del 3d..., no, no voy a poder. Creo que todo lo que podría haber dicho ya lo he dicho.
Lo siento, nada de lo que has dicho tiene utilidad.
Todas las matemáticas de la geometría del 3d, ya se conocía incluso en el siglo XIX... un libro muy reutilizado por aquellos tiempos fue el mítico: "Elementos de geometría analítica" de Sonnet y Frontera, publicado en 1854 (en francés), y traducido a quien sabe cuantos idiomas, yo tengo la versión de 1863 que no sé si es la primera o segunda edición en español.
Para tí te recomiendo un libro pequeñito pero no por ello menos interesante: "Teach Yourself Computer Graphics" de John Lansdown, de unas 230 páginas publicado en 1987. Perfecto para ser el primer libro de cualquiera que pretenda adentrarse en el 2d y 3d, sea para programar, o al menos hablar con propiedad.
puede que todo esté explicado con que de algún modo en mi memoria personal asocie el gozo de la salud a esos juegos antiguos, mientras que con los nuevos me sea imposible asimilarla...
No hay diferencia entre los antiguos y los de ahora más que la potencia de cálculo. También nuevos algoritmos en cuanto a la implementación de la luz, pero si ya en aquellos tiempos costaba mover algo simple, y no podían ponerse determinada cantidad de colores, mucho meos hacer cálculos de luz, Aún así se hacían pero solo para imágenes estáticas, no para juegos que debían funcionar en tiempo real.
En la medida que la potencia de cálculo ha aumentado, se pueden hacer más cosas sin sacrificar la 'jugabilidad'... incluso así, algunos creadores 'se pasan' exigiendo siemre más potencia que los equipos que sus potenciales clientes tienen.. obligándoles constantemente a adquirir nuevo equipo con cada nuevo estreno de un videojuego.
Por ello, en aquellos tiempos que los gráficos que añoras, tenían la enorme virtud de tener que mantener la 'esencia' del gráfico dada la limitación de recursos para que el jugador pudiera sentir que ese gráfico era lo que sus autores habían pretendido que fuera. ...y siempre había quien se quejaba de todo...
Decidme una cosa, es una tontería, pero ¿cualquier juego de mundo abierto de los de ahora, está procesando todos los objetos del mundo en tiempo real?.
No. Ni antes tampoco.
Los juegos solamente procesan los objetos que están a la vista, incluso de estos, solo aquellas partes que son visibles.
Hay algoritmos para calcular que objetos están fuera de escena (sea fuera de posición o tapados por otros), esos no se procesan. Una esfera por ejemplo, solo precisa ser calculado el plano 2d que tu ves, es decir un círculo... que viene a ser media esfera, aunque en el perímetro los detalles se acumulan y pueden obivarse muchos de ellos que por su posición no cubren el equivalente de 1 píxel.
Además cuando hay movimiento, los detalles no necesitan ser tan precisos, como cuando está inmóvil, e incluso cuando está en movmineto, se calcula si un área dado, necesita ser recalculado o sigue siendo vigente el área previa.
Lo pienso y es curioso: aprovechar la capacidad de almacenamiento y la velocidad de lectura del disco para mover un personaje 3d con animaciones por un pre-renderizado en 3d (proceduralismo) generado mediante el cálculo de todas las imágenes posibles fuese cual fuese la posición en pantalla según fuésemos a mover al personaje, memorizadas y movidas.
No se puede calcular todas las 'posibilidades', el espacio necesario para su alamcenamiento sería inexorable.
Hay una técnica llamada 'sprite' que consiste en establecer x imágenes de transición para un objeto, que son repetitivas, por ejemplo un personaje al andar... 30 años atrás hubiera tenido entre 4 y 8 imágenes de transición, además habría diferentes si se ve de frente, perfil o pordetrás... ahora esoso sprites parten de un esqueleto que ´facilmente se posiciona en 3d... siguen siendo sprites, pero bastante más complejos.
Toda la dinamica de diseño se apoya en lo que se llama un 'motor de juego (3d al caso)'.
se podría elaborar el método para calcularlo en, por ejemplo, un escenario de 4x4 metros, y creo que por metro que se añadiese, el crecimiento sería algo distinto a exponencial, sino que tendría su propia fórmula. No es difícil, ¿no?. Luego sólo sería multiplicar por el peso de una foto de 3 megapíxeles cualquiera
Hay algoritmos de renderizado de texturas incluso aleatorias... seguro que si tienes cierta edad habrás jugado o visto jugar al Flight Simulator, las nubes, el terreno, el mar, se renderiza de forma aleatoria partiendo de un plano sencillo 2d, o bien recurriendo a fractales. Esto último es lo más adecuado cuando se duiseña algo desconocido, un plano es preciso cuando debe ceñirse a la fidelidad de algo existente. Aunque a día de hoy ambas tecnologías conviven.
Podíamos empezar averiguar cuantos frames son posibles en un giro de 360 grados..., todo sería una dimensión sólo que viendo los diferentes detalles de la textura
Como te he indicado eso lo controlan los sprites, si alguien determina que quiere un sprite por cada 15 grados de angulo, pués calculando tienes 24 sprites.
Si alguien quiere que funciones por cada minuto de arco, pues requerirá 360*60, ahora ya no serán sprites, serán recalculados en tiempo real.
El sprite es adecuado para ahorrar cálculos, pero si la potencia de cálculo es enorme puede prescindirse y recalcularse en tiempo real. Al menos los obtetos principales, los objetos 'muertos' (casas, calles árboles) y todo lo que no esté en primer plano (personajes en la lejanía), por no requerir tanto detalle, pueden seguir tirando para ellos de sprites, así se consigue cierto realismos de primer plano, sin pecar de jugabilidad... un 'truco sucio' es situar las escena en cierta penumbra, así ciertos detalles no necesitan tanta precisión (todos los gatos son pardos de noche).
¿Se sabe cuantos círculos caben dentro de una esfera si los círculos tienen que rozar sus paredes si o si?, ¿alguien sabe si esto tiene nombre?, y si no lo tiene, ¿alguien se imagina como podría calcularse?.
Estos son matemáticas... Puede interesarte la "conjetura de Kepler" (es el nombre que buscas), Busca por Gauss y Thomas Hales.
por eso establecer una velocidad en lo virtual ayuda a comprender donde estamos, y en lo real...vete tu a saber.
Para tu información la técnica está a años luz de tu imaginación... lee, infórmate, en vez de teorizar por debajo del estado actual del arte, hay infinidad de libros sobre la temática de gráficos por ordenador...