Iniciado por
masteries
Empiezo por Doom; hasta Doom 2016 sé que está escrito en C+OpenGL y C+Vulkan;
el motor gráfico y de modelos (que tienen esqueleto claro) se escribió desde 0
todavía participó Carmack en este desarrollo, supongo que haciendo las funciones de
director de orquesta, e implementando aquellas partes en las que hacía falta una experiencia
en motores gráficos como la que tiene este señor.
También transmitió el mensaje de que la librería Vulkan te permite hacer cosas con el hardware
que tanto OpenGL como DirectX no te dejan, como crear nuevas fuentes de interrupción a nivel
interno en la tarjeta gráfica... bueno no hace falta decir mucho sobre lo bien que funciona
el motor de Doom 2016 bajo Vulkan; con un i5 de tercera generación y una RX 480 de 4GB;
a 1080p con todo en Ultra el juego se mantiene en más de 160 fps, abrasándose la RX 480
(siempre puedes activar el sincronismo vertical y quedarte con los fps que marque el
refresco vertical de tu monitor).
Así mismo se quejó de que con OpenGL no lograba sacarle el rendimiento que esperaba
al hardware de vídeo puntero en ese momento, pues no le dejaba plantear el funcionamiento
del dibujado en pantalla con las propiedades que Vulkan le estaba ofreciendo.
------------------------------
Ahora vamos a esto:
"Como todo lo hago en C, y a veces hay algo de ensamblador por debajo...
y estructuro el código para que todo funcione como Fénix/Bennu,
que para hacer juegos (y otros programas en Tiempo-Real)
es una manera comodísima de programar y organizar las cosas."
Te cuento de forma muy resumida:
Dado que le estamos dando duro a las máquinas antiguas; encuentras
funciones de vídeo para ellas; pero no dejan de ser algo relativamente básico,
te permiten dibujar sprites en pantalla y se encargan de gestionar los accesos
al cartucho cuando el frame del sprite cambia...
y ya está, no hay más; ni gestión de mapeados, ni durezas del mapa, ni colisiones entre sprites,
ni gestión del orden de dibujado, ni un mecanismo ni siquiera básico para que organices las funciones
que proporcionan funcionalidad a los sprites...
Todo eso te lo tienes que hacer a mano; así que después de mucho currar durante meses
en un motor 2D multiplataforma, pues tengo un repertorio de funciones como:
Identificador = EntitySpawn(tipo de entidad, posición x en el mapa, posición y en el mapa);
Identificador funciona como en Fénix/Bennu; te proporciona acceso a las variables internas
del proceso, que puede ser un sprite o no: Identificador.xworld , Identificador.yworld, Idenficador.layer,
identificador.health... y así
EntityRemove(Identificador);
Para eliminar un proceso de la lista de funciones tick a ejecutar.
Luego hay una lista de tick functions que se ejecutan al final,
dado que cada tipo de entidad declarada tiene asignada su función,
lo que viene a ser el process() de Fénix/Bennu
Y ya al final de todo, la lista de dibujado; ahora mismo dispongo de 6 capas
de dibujado; cada proceso tiene asignada una capa (layer) distinta.
En esa lista de dibujado también están los tiles de los planos de scroll;
en Atari STE y Megadrive, los planos de scroll son persistentes,
en el STE es un frame buffer del que debes limpiar los sprites, o parte
de los sprites si corresponde.
En MD la información sobre la posición de los tiles es persistente,
y o bien la actualizas (escribiendo y borrando valores de la tabla,
y si es necesario también escribes nuevos tiles encima de tiles
que ya no se muestren en pantalla).
En N64 tanto el mapeado como los sprites funciona todo igual,
todo son sprites o texturas colocadas sobre superficies definidas
por cuatro vértices; así que en cada pasada redibujas todo.
Con lo potente que es su adaptador de vídeo y CPU para dibujado 2D,
pierdes más tiempo en limpiar sprites del frame buffer,
que en redibujarlo todo.
El concepto de tablas con información de tiles para el mapeado
e información de los sprites es muy del mundo arcade de 16 bits;
y de MD y SNES; las máquinas de años posteriores perderían esas
capacidades hardware, pues son potentes, pero te limitan bastante
en lo que puedes llegar a hacer, pues están orientadas sólo a juegos 2D
y encajan mal con otros planteamientos de juego.
Citar
).
Marcadores