Portada
mis comunidades
otras secciones
#4:
El tema de la latencia en emuladores se ha resuelto bastante bien con runahead.
Básicamente es mostrarle al jugador frames por adelantado a la lógica actual del juego. La sensación es respuesta inmediata, incluso más rápida que el hardware real.
Enlazo un vídeo y un artículo sobre esta técnica:
https://m.youtube.com/watch?v=_qys9sdzJKI
https://near.sh/articles/input/run-ahead
Básicamente es mostrarle al jugador frames por adelantado a la lógica actual del juego. La sensación es respuesta inmediata, incluso más rápida que el hardware real.
Enlazo un vídeo y un artículo sobre esta técnica:
https://m.youtube.com/watch?v=_qys9sdzJKI
https://near.sh/articles/input/run-ahead
#1:
Un trabajo de análisis muy bueno, la verdad. Los resultados de software vs FPGA son más o menos los que cabría esperar, pero hay que felicitar este trabajo por lo extenso y meticuloso.
No lo esperaba tan detallado.
No lo esperaba tan detallado.
Comentarios
Un trabajo de análisis muy bueno, la verdad. Los resultados de software vs FPGA son más o menos los que cabría esperar, pero hay que felicitar este trabajo por lo extenso y meticuloso.
No lo esperaba tan detallado.
#1 A mi me han sorprendido gratamente los resultados del emulador que se ejecuta en navegador.
Me pregunto si usara WebAssembly para obtener ese rendimiento.
#3 todo es webassembly aunque sea JavaScript. Quiero decir, no se programa directamente en webassembly, se programa en lo que sea y se compila a webassembly (en caso de JavaScript, se compila sobre la marcha).
Igual está por ahí el código fuente de todas formas.
#6 en la documentacion del engine de chrome v8, no encuentro nada referente a lo que dices, y me interesa mucho.
Puedes indicarme de donde has sacado esa informacion
Gracias.
[añadido despues]
De hecho en la wikipedia acabo de ver otra cosa distinta
https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
V8 first generates an abstract syntax tree with its own parser.[12] Then, Ignition generates bytecode from this syntax tree using the internal V8 bytecode format.[13] TurboFan compiles this bytecode into machine code. In other words, V8 compiles ECMAScript directly to native machine code using just-in-time compilation before executing it.
El hecho de que webassembly sea mas rapido es porque eliminas la fase de tokenizacion y conversion a AST, pero eso no indica que despues uses webassembly como bytecode, aunque podrias, pero por lo que veo v8 por ejemplo tiene su propio bytecode.
#10 sí, tenía en mente que el bytecode resultante de Javascript era directamente webassembly, pero por lo menos en el caso del V8 no es así. No sé de donde saqué esa idea, sorry for la confusión.
#6 Conozco como funciona, lo he usado he varios proyectos.
Y debo decir que lo que comentas es impreciso.
WebAssembly es un nuevo lenguaje, el cual no esta pensado para ser usado directamente para programar.
A pesar de ello, podrias crear tus archivos .wat a mano, y luego compilarlos a .wasm
https://blog.scottlogic.com/2018/04/26/webassembly-by-hand.html
Sobre si JS y WebAssembly comparten pipeline...
"V8’s approach to compiling WebAssembly has relied on TurboFan, the optimizing compiler we designed for JavaScript and asm.js"
https://v8.dev/blog/liftoff
Pero no tiene por que ser asi en todos los motores.
CC: #10
El tema de la latencia en emuladores se ha resuelto bastante bien con runahead.
Básicamente es mostrarle al jugador frames por adelantado a la lógica actual del juego. La sensación es respuesta inmediata, incluso más rápida que el hardware real.
Enlazo un vídeo y un artículo sobre esta técnica:
https://near.sh/articles/input/run-ahead
#4 Usar Linux y algo que soporte KMS/DRM también ayuda.
#4 Buen enlace, gracias
Hay una cosa que me chirría y son esos 0 ms en el Spectrum real y me explico.
Si la memoria no me falla el Spectrum tiraba de una interrupción no enmascarable (NMI) 50 veces por segundo para refrescar la memoria de vídeo y tramitar cosas como la entrada de teclado, devolviendo luego el control al programa. Encima estaba hecho para verse por RF y las TV de aquella época no tenían precisamente 60 Hz como cualquier chisme baratico de ahora (los caros creo que ya anda por los 320 Hz) creo que andaban por los 25 Hz (la mitad de la frecuencia de la red eléctrica) y el cine era a 24 imágenes por segundo. Y todo eso lo gestionaba la ULA (Uncommitted Logic Array) si no me equivoco (me estoy remontando casi 40 años atrás así que disculpad si se me van conceptos) Y todo ello gestionado por un reloj que mandaba pulsos a 3,5 Mhz (el chisme en que escribo esto llega a los 4,8 GHz y no es de los últimos precisamente)
Con ese sistema me chocan mucho esos 0 fps de pérdida entre la pulsación y el cambio en la pantalla, sobre todo porque son fps de una cámara externa que filma, no fps del spectrum (yo creo que de aquella el concepto ni existía)
#8 #7 Exceleten articulo, pero estoy de acuerdo que le falla esos 20 ms. No incluye el error de la medida. Si tu medida minima es de 20 ms tienes un error de 20 msec En el mismo frame seria desde 0 ms a 20 ms
Por lo demas excelente. El resto de lso componentes (con la excepccion de cambiar de pantalla) son los mismos en todas las pruebas con lo que no sor variables.
#9
No tengo ninguna queja de la prueba, ni de la metodología. La explica al principio, hace todas las pruebas intentando mantener los elementos sin cambio, ....
Pero conociendo el chisme como lo conozco (aunque hace muchos años que no toco uno) me ha llamado la atención esa respuesta tan "inmediata" y me pareció raro que en ninguna de las 10 pruebas que hizo haya perdido un solo frame. Date cuenta que el escaneo del teclado se hacía con una interrupción no enmascarable (NMI) y el programa corre en otro plano.
Lo único que se me ocurre es que no esté usando las NMI para comprobar el teclado y lo esté escaneado directamente con el programa, sin usar el firmware. Y eso hace que la respuesta de su programa sea mucho más rápida que incluso el funcionamiento normal del spectrum.
Aunque parezca que hace trampa, muchos juegos modificaban esto para conseguir mejor rendimiento sin depender de las rutinas de la ROM, así que entra dentro del comportamiento normal del chisme.
#13
por otra parte si haces estas cosas estarás usando código máquina y lo más seguro es que ya estés leyendo el teclado a pelo (lo que podrías hacer en cualquier momento del frame).
Lo comento en el otro comentario (#11), para conseguir ese rendimiento tiene que estar pasando de las rutinas del firmware.
#8 Tienes unos cuantos conceptos bastante liados. Lo que se genera cada a 50 Hz es una interrupción normal (y, por tanto, perfectamente enmascarable) y, como dices, esta interrupción marca el inicio de la generación de la pantalla. La única manera de generar una NMI en el Spectrum es de manera externa (el botón NMI de muchos interfaces).
El comportamiento habitual (al encender el ordenador) es que se aproveche esa interrupción para leer el teclado (en los 128, además, se hacen cosas con la paginación y en los +3 alguna cosilla con el disco). Esto lo hacen ciertas rutinas de la ROM del Spectrum. Si deshabilitas las interrupciones o las redireccionas, pierdes esta automatización; por otra parte si haces estas cosas estarás usando código máquina y lo más seguro es que ya estés leyendo el teclado a pelo (lo que podrías hacer en cualquier momento del frame).
La generación de pantalla (traducir el contenido de la RAM a píxeles y enviarlos al televisor) es cosa de la ULA y sí va a 50 Hz (de hecho, creo que es la ULA la que genera la interrupción). La historia es que el sistema PAL (el de las TV analógicas en este país) define 25 imágenes por segundo entrelazadas: primero se envían las líneas impares y luego las pares. Esto se hace así por la persistencia del fósforo de las televisiones antiguas: si mandabas todas las líneas de golpe para cuando se empezaban a dibujar las líneas de abajo, las de arriba se empezaban a borrar y se notaba el parpadeo. Al mandarlas entrelazadas, para cuando empezaban a borrarse las líneas pares ya estabas dibujando las impares, y el ojo no lo notaba.
Los Hz de un chisme baratico de ahora no sirven de nada en TV: aunque tengas una pantalla de 144 Hz, vas a seguir recibiendo 25 imágenes por segundo (otra cosa es cómo repartes esas 25 imágenes para llenar los 144Hz).
Vaya articulo más bueno, ché.
Y como molan los FPGA.
La caga un poco al asignar 0ms cuando el resultado es en el mismo frame.
Está súper interesante, pero cambia varias veces de monitor entre CRT y LCD. No añade latencia extra los LCD?
#5 Al policia del retro le gusta tu pregunta.
No me parece demasiado objetivo un estudio de latencia en milisegundo donde interviene la pulsación de un dedo humano, sobre todo si los teclados y los monitores son distintos.