Martin Thomas, que es como se llama el desarrollador, ha creado por su cuenta un driver Vulkan capaz de ejecutar el mítico Quake III con una resolución de 1280 x 720 píxeles y 100 fps en una Raspberry Pi 3B+. Thomas asegura que el juego es capaz de correr a 80 fps a resolución 1080p. Aunque se trate de un título que tiene 20 años, sin duda es un gran logro, ya que técnicamente Quake III es muy exigente, y aquí está funcionando en una micro PC que apenas cuesta 35 euros.
|
etiquetas: quake , vulkan , nvidia , raspberry pi
Pero recordemos que hicieron correr Doom en un puto osciloscopio con pantalla de fósforo.
Y en un termostato.
EDIT: Encontré el video, creo que era este
www.youtube.com/watch?v=aMli33ornEU
La gracia es que ese software quizás puede permitir hacer lo mismo en otros juegos.
Edit:
m.youtube.com/watch?v=GTApvwqZ_TM
Pues un ingeniero de Nvidia ha creado unos específicamente para un ordenador de 35Eur que coge en el bolsillo para un juego mítico
Je je
#16 creo que desde Cataclismo dejó de ser compatible con las máquinas que movían el Vanilla (si no recuerdo mal)
#17 486 mínimo, recuerdo cómo si fuera ayer el mensaje (yo tenía un 386 con una 3d nisu y el mensaje era ese, minimo 486)
Quake I fue otro salto, cambiaron el motor creo que fue Romero de id Software. ya el II imposible. Así que Quake 3 en una Raspberry Pi 3 es una pasada de micro.
de 35 eurosde 5€ (el driver funciona con la Raspberry Pi Zero, que vale 5€, la raspberry pi 3 está desfasada y sin duda vale menos que los 35€ de la RP4)www.jfedor.org/aaquake2/
100 a 720p. 80 a 1080p. Lo dice bien claro la entradilla.
www.game-debate.com/games/index.php?g_id=2438&game=Quake III Arena
No quiero quitar mérito. Conseguir 100fps no creo que sea sencillo.
Lo que será verdaderamente revolucionario es el driver Vulkan para la Pi4, que avanza leeeentamente.
La RPi4 es capaz de emular PSP y Dreamcast bastante bien y un driver Vulkan optimizado podría ser la ayuda que necesita para emular GC al 100% de velocidad (los juegos ligeros, al menos)
Al menos los drivers oficiales OpenGLES siguen mejorando poco a poco... recientemente expusieron OpenGLES3.1
Aquí hay un vídeo de esta semana que lo explica: youtu.be/-BA0BJwuGK4
Básicamente el hardware era complejo e incluso Nintendo tuvo que hacer ñapas para emular cada uno de los juegos de N64 que publicaron en la wii.
Y eso que tienen el código fuente de los juegos y todos los datos de la arquitectura de la N64.
Ponerlo a 640x480 era como ponerse un PowerPoint. Pero qué pedazo de juego y de banda sonora.
Lanzando órdenes al juego en un folio mientras el boli reconocía la puta escritura.
El DooM no puede ser en una pantalla de fosforo, si no en un osciloscopio ya que es renderizado 2D sin poligonos. Como dice #6, era el quake.
De hecho para emular la PSP minimamente a 1366x768 con 1 o 2 cuadros omitidos, necesitas un Celeron de doble nucleo y una Intel Mobile 4 Series.
#7 Para la PSP minimo Rpi3.
Como el cafelito noseque delate pero sin osito.
Lo gracioso es que en su día el Quake2 tiraba sin X usando SVGALib con ratón y todo. Para qué perder el tiempo con AALIB?
Como digo en modo texto las aventuras conversacionales y los roguelikes son mucho mejores.
IDKFA
IDDQD
Los chips ARM estan muy por debajo de X86, excepto Apple. Yo con un bicho de 800MHZ en ARM sudaba para emular la PSX, no iba al 100% muy poco. Con 800MHZ en PC y cualquier aceleradora tirabas los juegos a 640x480 que daba gusto.
Hoy el software detecta las capacidades al vuelo si lo has programado para ello. Si no porque te crees que existe AVX? Esas son instrucciones que se meaban a las de 16 bits e incluso optimizando.
Haz la prueba: el retroport del codigo abierto del Quake2 para DOS sigue siendo mas lento que el mismo para Windows con DirectX.
El que me perdí fue el Quake 2, que jugué bastantes años después en Xbox 360 junto al Quake 4.
De toda la serie, mi favorito sigue siendo el 1 y sigo echando alguna partida de vez en cuando usando el motor DarkPlaces con packs de texturas, que mejoran los fráficos bastante.
www.youtube.com/watch?v=WEHpTk75pEc&
Sobre Darkplaces, consiguete la conversion Malice, es una puta pasada.
No digo que llegue al nivel del Doom3, pero a 1024x768 con una GF3 tendrías 30 FPS y con mucha suerte.
Haced la prueba con Open Arena en un PIII con una Geforce3 y me comentáis. No es que el Q3 original esté más optimizado ojo.
www.moddb.com/mods/malice-for-quake-patched-with-bug-fixes-and-soundtr
Creo que he ganado .
Aunque bueno, esto sigue siendo superior:
www.youtube.com/watch?v=Bf0XAf8_mLI
Y encima los compiladores de hoy optimizan mejor que cualquier programador (o casi cualquiera que no sea de Europa del Este).
Hoy el problema está en basuras hechas con Electron, no tanto lo de explotar micros hasta el extremo. Un Core Duo hoy con una grafica normalita tira para todo menos para juegos modernos. Para 4k, con una CPU Haswell te sobra.
Como ejemplo, mira lo que ocupa QUAKE en Amiga y Quake en MSDOS. Verás que en Amiga es una décima parte.
Y qué me digas que AMIGA se quedó coja frente a 386 o 486, no tiene sentido, porque estás comparando procesadores y generaciones que no tienen nada que ver una de la otra. Te recuerdo que el Motorola 6800 es de 1988 y el 486 es de 1992. Es como si me dijeras que el Pentium I se quedó cojo comparado con el Pentium III. Y tampoco tiene nada que ver con lo que estoy comentando. Los compiladores de hoy optimizan una mierda.
Sobre Quake en Amiga, mira para qué arquitectura existe únicamente y luego haz cuentas.
>Los compiladores de hoy optimizan una mierda.
Cuñao supremo. Los compiladores HOY compilan mejor que tu hace 20 años. Te suenan cosas como predicción de ramas? Tus conocimientos antaño en compiladores si que son una mierda, lo siento.
Mira, y ya ha llovido:
asm.sourceforge.net/howto/howtonot.html
GCC ya en el 2003 compilaba mejor C que lo que tu pudieras hacer con ASM "inline".
Recuerdo que en Bochs muchas veces por las manías de CPU actuales lo que había que hacer era NO optimizar a mano y dejar que el compilador hiciera lo suyo. Así de marciano era.
Lo digo porque el acortar los bucles y optimizar el acceso a datos a veces se paga con más uso de RAM, cosa que no te han contado... y la inversa es verdad.
Ahorras espacio pero luego tiene que calcular cosas al vuelo y acceder al doble de X veces a una función. Total, qué ganas, si pierdes tiempo?
Por eso en Unix podías tirar con una CPU cutrera e invertir perfectamente en RAM que era lo que más te iba a cundir de largo. En su día era mejor un PII con 128MB de RAM que un PIII con 64.
Total, todo el uso de CPU que ibas a ahorrar lo podías hacer perfectamente con FVWM como gestor y luego IceWM cuando se puso de moda.